Subject: Re: draft-ietf-dnsext-nsid issues to be reviewed

From: Rob Austein <[email-masked]>
Date: Thu, 01 Jun 2006 20:14:27 -0400

At Tue, 23 May 2006 10:50:48 +0200, Olaf M Kolkman wrote:
> 
> NEW:
>
> 3.1.  The NSID Payload
> 
>     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 and the server administrator
>     is able to match the NSID to server instances. This
>     section describe some of the kinds of data that server administrators
>     might choose to provide as the content of the NSID option, and
>     explains the reasoning behind choosing a simple opaque byte string.

I do not see the need for content to be unique.  All that matters is
that the name server which provides the NSID payload be able to
understand it; the rest is nobody else's business.

> Is there consensus to add such a "MUST implement a specific automated  
> method"?

I do not see the need for a "MUST implement" method.

--
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/>

---

From: Dean Anderson <[email-masked]>
Date: Fri, 2 Jun 2006 18:50:53 -0400 (EDT)

> understand it; the rest is nobody else's business.

It should be unique so that remote users can determine if there a problem with
an anycast instance, that is, two anycast instances returning different data, 
or verify that different anycast instances return the same data. etc.

I think it has to be unique anyway, even if opaque.  If it is exactly the same
across all instances, then it is entirely useless. So, the question that needs
to be addressed (and I think this is what Olaf was driving to) is whether the
(opaque) response remains the same for the same anycast instance across multiple
requests which reach the same instance, or is changed for each packet in some
way that only the server operator can decode.  I think it should be the former.

By contrast, it seems to me that Mr. Austein has in mind a means of keeping 
secret the number of anycast instances.  I see no good reason for that, and many 
good reasons for being able to identify specific instances over a series of 
requests.  One would need to be able to do this in order to perform any sort of 
testing on Anycasted responses.

Given the current state of discredited research on stateful DNS anycast, and the
difficulty of getting data from DNS operators, it is an important facility to be
able to uniquely identify that different Anycast servers respond, and with what
responses.

I think its perfectly fine to hide sensitive information about OS and DNS
vendor/version, even about static unicast address, but I think it is not OK to
withhold data which indicates that Anycast is in use, and which can indicate how
many anycast instances there are, or at least that different anycast instances
responded over a series of queries.

I suggest the following wording:

 3.1.  The NSID Payload

     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 such that it
     can be decoded by the server adminstrator to provide more information.  
     This section describe some of the kinds of data that server administrators
     might choose to provide as the content of the NSID option, and
     explains the reasoning behind choosing a simple opaque byte string.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000