Subject: A look at draft-...nsid-01.txt

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Jun 2006 11:04:37 -0400

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsid-01.txt
Comments in line:

Network Working Group                                         R. Austein
Internet-Draft                                                       ISC
Expires: July 15, 2006                                  January 11, 2006

                 DNS Name Server Identifier Option (NSID)
                        draft-ietf-dnsext-nsid-01

2.4.  Presentation Format

    User interfaces MUST read and write the content of the NSID option as
    a sequence of hexadecimal digits, two digits per payload octet.

=====

I don't see why this is a MUST.  First litmus test - in what way does 
this impact interoperability?

I do agree that a User Interface ought to be cautioned about 
displaying certain formats unchecked, i.e., displaying as HTML with 
embedded badness in it.

=====

3.  Discussion

    o  Using an arbitrary octet string gives name server operators yet
       another thing to configure, or mis-configure, or forget to
       configure.  Having all the nodes in an anycast name server
       constellation identify themselves as "My Name Server" would not be
       particularly useful.
=====

I can see usefulness in setting all of the servers to the same name - 
that is if I don't want anyone to differentiate amongst them, e.g., 
to prevent someone from knowing how many servers are there, behind a 
load balancer.  (As if that matters anymore.)

Keep in mind that many DNS constellations are already managed via a 
VPN, so in many cases, NOCs already would know of anomalies, or be 
able to identify which DNS server is misbehaving.

=====

3.3.  User Interface Issues
...
    be useful.  Thus, the presentation format must support arbitrary
    binary data.

=====

That's more reasonable than "MUST present as".  It's possible that an 
interface could try to interpret the bits and that's okay (so long as 
it doesn't launch an Javascript exploit, say.).

=====

After looking at 
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01347.html:

What I see missing is a limit on the length of the option.  Is there 
any reason to leave it unbounded?  An unbounded length opens the door 
to abuse.  (I.e., I agree with the first point.)

As far as the "open issue" -
>  On Tue, Jun 13, 2006 at 03:18:10PM +0200, Olaf M.Kolkman wrote:
>
>>       The syntax and semantics of the content of the NSID option is
>>       deliberately left outside the scope of this specification. It is
>>       the prerogative of the server administrator to choose the NSID
>>       content as long as the content is unique to each anycast instance
>>       so that a remote user is able to match the NSID to the server
>>       instance over a series of queries. The NSID can be opaque and encoded

I don't see that there is any reason to guarantee a remote user see a 
consistent reply from one process.  Remote users aren't supposed to 
be able to prod the DNS constellation to reverse engineer it.  Just 
like we see zone walking iN DNSSEC as undesirable or bad, providing a 
means to reverse a DNS constellation is undesirable.

Although, frankly, if I didn't want to "expose" individual servers, I 
would just give them all the same NSID name, contrary to the part of 
section 3 I commented on.

With the advent of dynamic update, I doubt we can ever require a 
server provide consistent answers over a series of queries.  DNS 
isn't real-time, but it's hardly static.

Bottom line, I don't see that there is a *responsibility* of a server 
operator to report to a remote user *anything* other than the data 
requested in the DNS. NSID is helpful to server operators, no doubt, 
but it is not for the benefit of the remote users.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>