Subject: WGLC: Name Server Identifier Option

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 5 Oct 2005 20:04:14 +0200

Dear colleagues,

In Paris we promised to process the NSID draft as soon as possible
after it appeared.  Its been around for a month, so we are late with
this working group last call for:

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

Abstract

    With the increased use of DNS anycast, load balancing, and other
    mechanisms allowing more than one DNS name server to share a single
    IP address, it is sometimes difficult to tell which of a pool of
    name servers has answered a particular query.  While existing
    ad-hoc mechanism allow an operator to send follow-up queries when
    it is necessary to debug such a configuration, the only completely
    reliable way to obtain the identity of the name server which
    responded is to have the name server include this information in
    the response itself.  This note defines a protocol extension to
    support this functionality.

Please review your draft and state your support. Technical content
should be addressed on the list editorial nits can be send to the
document editor with a CC to the chairs.

If there is little or no feedback the default action will be to
forward this document to the IESG to be published on the standards
track.

The last call terminates Saturday the 22nd of October.

- - --Olaf and Olafur
DNSEXT Chairs.

- -----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/
We have employment opportunities, see the website.

--
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: Peter Koch <[email-masked]>
Date: Fri, 07 Oct 2005 14:44:59 +0200

David Conrad wrote:

> OPTION-DATA field as opaque implicitly violates the assumption of  
> 2671 that OPTION-DATA be comprised of attribute/value pairs.  Might  
> make this explicit.

my reading of 2671 is that the (CODE/LEBGTH/DATA) container described in
section 4.4 already *is* the "attribute,value" pair. Otherwise there's
nothing said about the separator between attribute and value and the
charset issues. Maybe a clarification to 2671 is needed when it goes to Draft.

But as you mention the length: what is the responding server supposed to do
if putting in the requested information would exceed either 512 octets
or the maximum available payload size as "negotiated" between the
requestor and itself?

Will the EDNS version to be announced remain "0"?

-Peter

---

From: Peter Koch <[email-masked]>
Date: Mon, 10 Oct 2005 16:11:09 +0200

David Conrad wrote:

> Set the truncate bit?

so, if options take precedence over responses/referrals that should be
said somewhere, especially if we're discussing "long" NSID identifications.

-Peter

---

From: Paul Vixie <[email-masked]>
Date: 10 Oct 2005 23:35:39 +0000

> > > if putting in the requested information would exceed either 512
> > > octets or the maximum available payload size as "negotiated" between
> > > the requestor and itself?
> > 
> > Set the truncate bit?
> 

this highlights a general failing of RFC 2671, and is not specific to NSID.

i believe that the right behaviour is that if a requestor is considering
adding an OPT RR that won't fit in the previously negotiated buffer size for
the destination server, that a smaller OPT RR, or no OPT RR, be used; if
a responder is considering adding an OPT RR that won't fit in the advertised
buffer size of the requestor, that it should respond with RCODE=17, which
the IANA should allocate to mean "optional truncation".
-- 
Paul Vixie

---

From: Peter Koch <[email-masked]>
Date: Fri, 28 Oct 2005 18:17:19 +0200

Rob Austein <[email-masked]> wrote:

> >   balancer and there might be other reasons. The person debugging
> >   then can't even tell whether subsequent responses originate from
> >   the same server, but it could hand over the info received to the
> >   server admin for further inspection.
> 
> Thought I'd covered this:
> 
>    o  It could be some sort of dynamicly generated identifier so that
>       only the name server operator could tell whether or not any two
>       queries had been answered by the same server.

yes, indeed. Please accept my apology.

> If the WG would prefer that we just use an empty NSID option rather
> than the SI flag bit, that's a simple change.

Good.

> Absent a specification for what non-empty NSID payload from client to
> server would mean, I think it should be empty (name server MUST ignore
> NSID payload, client MUST NOT/SHOULD NOT send NSID payload).  If and

Agreed. "MUST ignore" is future safe (forward compatible) on the server side.

> My main concerns at this point are: (a) that this specification be
> complete rather than making forward references to specifications that
> might never be written, and (b) that we finish this promptly, per the
> discussion in Paris.

Same here. My suggestion was not meant as a preparation of client side ID.
Whether or not this option can be reused I don't care for now.

-Peter