On 03/02/2012 09:00, John R. Levine wrote:
>>> 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.
Assuming you're the only one with the True WisdomTM is almost always a
bad idea. I stated earlier in the thread that I've done the kinds of
provisioning systems you describe. And I'm not going to throw my resume
at you, but I'm also intimately familiar with DNS at the large
enterprise level.
> 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.
I understand what you're saying, and I've seen this kind of
institutional lethargy in action. My point is that just because this is
a very common situation doesn't make it correct, or even defensible.
We have a longstanding culture of DNS being a set-and-forget service. Us
"DNS weenies" have been the worst offenders in enabling this bad
behavior by trying to be backwards-backwards-backwards compatible with
every new change. Those days are over. And just because properly
updating your software can be difficult doesn't make it the wrong answer.
> 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.
Yes, I get that bit too.
> 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.
So it seems to me that what you're proposing would also cause the need
for changes to be made to the provisioning systems. Or are you
suggesting that the same users who cannot handle anything other than
point and click are suddenly going to be able to enter specially
formatted text strings that they don't understand? And/or that the
people who operate those provisioning systems are going to allow end
users to "Add a new stanza to /etc/rrtypes"?
> 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.
The rest of this discussion is almost certainly more suitable for dnsop,
but I'll say one more time that I disagree with you on this point.
Provisioning systems *are* a bottleneck, no one is disputing that. But
our experience with new TLDs, IPv6 and DNSSEC shows that when there is
user demand for these changes, they get made.
I'll also add one more point based on my experience with DNS
provisioning system UI design, most of what you are trying to accomplish
with your draft on the UI side can be handled with a simple text field
in an HTML form that allows the user to enter free-form stuff that is
then checked for syntax errors and loaded if the name server software
supports the record. I realize that we disagree on right solution for
the name server support side of the equation, but my point is that most
of what you claim to be trying to achieve is already easily accomplished.
Doug (emacs!?! vi or die, baby)
--
If you're never wrong, you're not trying hard enough
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf