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


To: dnsop@cafax.se
From: Paul Vixie <vixie@vix.com>
Date: 27 Apr 2003 23:25:09 +0000
In-Reply-To: <20030427201649.89A5518E6@thrintun.hactrn.net>
Sender: owner-dnsop@cafax.se
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Subject: Re: draft-ietf-dnsop-serverid-01.txt

> ...
> While I understand and respect the author's intentions in attempting
> to remove the BIND-specific aspects of an existing hack, this opens up
> a nasty can of worms:
> 
> 1) The draft asks IANA to allocate a new TLD, and a class-specific TLD
>    at that;
> 
> 2) The draft specifies behavior for the (conceptual) zone
>    corresponding to that new class-specific TLD which is totally
>    inconsistant with the usual DNS data coherence model.
> 
> Furthermore, even ignoring the above issues, this looks like a
> protocol document than an ops document.

i agree on all three points.  the problem we solved with VERSION.BIND
back in bind8 and now with the recent addition of HOSTNAME.BIND caused
some other problems.  it's unquestionably bad that we pirate a TLD in
the CHAOS namespace for our version/hostname data.  it's questionably
bad that we do it by default, requiring people who want version/hostname
privacy to have to make a config change to get it.  however, not doing
these things would have been worse, and trying to get IETF and IANA to
allocate us some kind of QNAME/QCLASS/QTYPE for it would have been much
much far worser even.

> I can see two ways forward, depending on what the author and the WG
> want to do:
> 
> a) Strip this back down to an Informational doc describing an existing
>    BIND hack; or
> 
> b) Change focus to trying to draft some useful behavior for the STATUS
>    opcode, and move the work over to DNSEXT.
> 
> Comments?

while i agree with your complaints about the draft, i think that your
proposed alternatives are worse.  STATUS will run into untold middlebox
problems and will also take several years to finish the main part of the
argument about.  having an rfc number, even if only informational or
experimental, that would seem to sanction TLD piracy of this form would
be the biggest can of worms mentioned so far on this topic.

therefore i support drc's draft as written, since it's the least of all
known evils.  right now a number of non-BIND implementations answer for
VERSION.BIND and sometimes also HOSTNAME.BIND in the CHAOS class, just
for feature-level competition.  i regret choosing .BIND as the pirate TLD
in the CHAOS class for this; it should have been .NAMESERVER or something
else, and there should have been at least a technote describing it, and
i should have sought an experimental rfc for it.
-- 
Paul Vixie
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.

Home | Date list | Subject list