Re: provisioning software, was DNS RRTYPEs, the difficulty with

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I've rarely read a message on this list that I agreed with more.

+1000 to everything said below.

				Ned

>> By the way, what's your opinion of draft-levine-dnsextlang-02?
>
> It isn't clear to me what problem you're trying to solve. For resolving
> name servers 3597 should be enough. For authoritative name servers your
> idea is sort of interesting, but generally upgrading the software to
> pick up support for new RRtypes is a good idea, since you'll also pick
> up new security fixes, etc.

Oh, wow.  Now I see the problem: people here are totally unaware of what
using DNS software is like if you're not a DNS weenie.

If you think that it's reasonable to require a new version of your DNS
software every time there's a new RR, you've conceded total defeat.  On
most servers I know, software upgrades are risky and infrequent.  It could
easily take a year for a new version of BIND to percolate out of the lab,
into the various distribution channels, and to be installed on people's
servers, by which time everyone has built their applications with TXT
records and it's too late.

Moreover, the servers aren't the hard part, it's the provisioning systems.
You and I may edit our zone files with emacs, but civilians use web based
things with pulldown menus and checkboxes.  If they can't enter an RR into
one of them it doesn't matter whether the name server supports it or not.
This latest round of teeth gnashing was provoked by discussions in the
spfbis WG, where we're wondering whether to deprecate the type 99 SPF
record.  Among the reasons it's unused in practice is that nobody's
provisioning system lets you create SPF records.

The point of my draft is that it's an extension language that both name
servers and provisioning systems can read on the fly.  Add a new stanza to
/etc/rrtypes and you're done, no software upgrades needed.  The risk is
much lower since the worst that will happen if the new stanza is broken is
that the provisioning software and name servers will ignore it, not
that the whole thing will crash.

Sure, there are some RRs with complex semantics that can't be done without
new code (DNSSEC being the major example), but most RRs are syntactically
and semantically trivial, just a bunch of fields that the server doesn't
even interpret once it's parsed the master records or their equivalent.

Until the DNS crowd admits that provisioning systems are a major
bottleneck, and telling people to hand-code more types into them isn't
going to happen, there's no chance of getting more RRs deployed.

Regards,
John Levine, johnl@xxxxxxxx, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]