Subject: [dnsop] draft-ietf-dnsop-serverid-05.txt comments

From: Daniel Senie <[email-masked]>
Date: Thu, 15 Dec 2005 19:47:12 -0500

I read Brad's comments on this draft with interest. I've had some 
concerns about the mechanism recommended by this draft for some time, 
and would urge a bit of expansion in one area. I would like to see at 
least an optional, but standardized way to include an identifier in 
all response packets sent by the server, provided there's room in the 
packets. This could be accomplished by placing the information in the 
additionals section after ensuring the addition would not cause an overflow.

The thinking is simple: if the DNS server is able to tag all outbound 
packets with some uniqueness information, then there is no ambiguity 
concerning tracking down which server responded. Any mechanism that 
relies on a subsequent query will provide a less than perfect 
indication of the server involved, as load balancing or similar could 
in fact shift focus to a new server. When I've raised this issue 
previously, the response has been that the result of the subsequent 
query will be "good enough."

The introduction section of the document indicates folks are already 
using the mechanism offered by BIND (which requires an additional 
query) and that a rationale for this document is to codify practice. 
The introduction also goes on to talk about there being shortcomings. 
A requirements document must look forward and lay out the goals for a 
sufficient solution. It is understood that the existing practice has 
drawbacks, and so at this time I can't support having a requirements 
document that settles for solutions that are not sufficient to solve 
the problem. That this document does not explore more possible 
solutions says to me this is NOT a requirements document as written.

If this document is reworked, it could indeed be a useful document. A 
separate document could and should explore the present practice as 
one possible solution to a set of requirements, just as other 
possible solutions could and should be documented. The merits of the 
approaches could then be compared to the requirements, and weighed. 
It may well be that more than one mechanism could or should be 
considered together to provide the best possible solution given 
constraints that exist.

Dan
-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

   "George Orwell was only off by 20 years. Had he titled his book
    2004 instead of 1984, he'd have been hailed as prescient.
    War is Peace. Freedom is Slavery. Ignorance is Strength." -dts

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 16 Dec 2005 08:42:35 +0100

Dan,

it seems to me that you're advocating splitting the document into two:

- Section 1-2, discussing the present mechanism
- Section 3, discussing requirements for a "permanent solution"

In the "section 3" document, you would also like to discuss the option of 
tagging all outgoing DNS responses with the server ID.
Is that what you are proposing?

(BTW, I don't, off the bat, support such a split. It's "just too many 
documents" - I'd prefer to get this one out the door.)

                   Harald

--On torsdag, desember 15, 2005 19:47:12 -0500 Daniel Senie <[email-masked]> 
wrote:

> concerns about the mechanism recommended by this draft for some time, and
> would urge a bit of expansion in one area. I would like to see at least
> an optional, but standardized way to include an identifier in all
> response packets sent by the server, provided there's room in the
> relies on a subsequent query will provide a less than perfect indication
> of the server involved, as load balancing or similar could in fact shift
> focus to a new server. When I've raised this issue previously, the
> response has been that the result of the subsequent query will be "good
> enough."
>
> using the mechanism offered by BIND (which requires an additional query)
> and that a rationale for this document is to codify practice. The
> introduction also goes on to talk about there being shortcomings. A
> requirements document must look forward and lay out the goals for a
> document that settles for solutions that are not sufficient to solve the
> problem. That this document does not explore more possible solutions says
> to me this is NOT a requirements document as written.
>
> separate document could and should explore the present practice as one
> possible solution to a set of requirements, just as other possible
> solutions could and should be documented. The merits of the approaches
> could then be compared to the requirements, and weighed. It may well be
> that more than one mechanism could or should be considered together to
> provide the best possible solution given constraints that exist.
>
> Dan
> --

.

---

From: Daniel Senie <[email-masked]>
Date: Fri, 16 Dec 2005 09:36:19 -0500

At 02:42 AM 12/16/2005, Harald Tveit Alvestrand wrote:
>In the "section 3" document, you would also like to discuss the 
>option of tagging all outgoing DNS responses with the server ID.

I'm proposing either that the document be split, OR that the 
discussion of the present mechanism be removed or reduced to a 
representation of one of the possible methods that could be 
considered AFTER discussing the actual requirements. The document 
does not read like a requirements document, but rather a "here's a 
solution, how do we make it a bit more generic" with no consideration 
for whether the solution meets a set of requirements.

Another option would be to rename and retarget the document as a 
documentation of a current practice, and publish it as informational. 
This would be similar to some of the NAT WG documents where we were 
explaining an existing mechanism and attempting to provide a common 
terminology for it rather than specifying a new protocol.

>(BTW, I don't, off the bat, support such a split. It's "just too 
>many documents" - I'd prefer to get this one out the door.)

While I understand the desire to get documents out the door, and not 
increase the document count, I think it would be a mistake to publish 
this document as written, because it gives the impression that the 
historical solution is in fact sufficient without providing for a 
more thorough analysis of other techiques. While I too would like to 
see the backlog of drafts in this WG cleared, it seems to me that 
focusing discussion provides a way to improve the documents and 
generate debate that may not have taken place and which may be warranted.

>                   Harald
>
>--On torsdag, desember 15, 2005 19:47:12 -0500 Daniel Senie 
><[email-masked]> wrote:
>

.

---

From: David Blacka <[email-masked]>
Date: Fri, 16 Dec 2005 09:51:56 -0500

On Dec 15, 2005, at 7:47 PM, Daniel Senie wrote:

> The thinking is simple: if the DNS server is able to tag all  
> outbound packets with some uniqueness information, then there is no  
> ambiguity concerning tracking down which server responded. Any  
> mechanism that relies on a subsequent query will provide a less  
> than perfect indication of the server involved, as load balancing  
> or similar could in fact shift focus to a new server. When I've  
> raised this issue previously, the response has been that the result  
> of the subsequent query will be "good enough."

Daniel,

Are you aware of draft-ietf-dnsext-nsid-00.txt?

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

.

---

From: Daniel Senie <[email-masked]>
Date: Fri, 16 Dec 2005 10:23:59 -0500

>Are you aware of draft-ietf-dnsext-nsid-00.txt?

I wasn't. Just reviewed it. Basically is what I personally believe is 
the correct and sufficient solution. That it's in the queue of 
another WG does, I think, strengthen my argument that the draft under 
discussion in DNSOP is in fact not a good requirements document.

.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 16 Dec 2005 16:52:55 +0100

Hello Dan,

On Dec 16, 2005, at 01:47 , Daniel Senie wrote:

> concerns about the mechanism recommended by this draft for some  
> time, and would urge a bit of expansion in one area. I would like  
> to see at least an optional, but standardized way to include an  
> identifier in all response packets sent by the server, provided  
> there's room in the packets. This could be accomplished by placing  
> the information in the additionals section after ensuring the  
> addition would not cause an overflow.

How can you be sure that that "extra information" does not break  
existing clients or makes middle boxes drop
the packet on the floor? I think that including an identifier in  
_all_ response packets sent by a server _only_ provided there is room  
in the packets is a _bad_ idea.

The request to have the identifier in "all" response packets is  
already in section 3:
       That is, it needs to allow the query for the server's identifying
        information to be part of a normal, operational query.

The detail here is that the client  needs to request for the  
additional information, thereby indicating it can deal with that  
extra information returned. It could be argued that failsafe behavior  
in the presence of broken middle-boxes is a requirement that should  
be made explicit. I am agnostic about the need for such argument.

Note that the propose implementation of this mechanism (draft-ietf- 
dnsext-nsid-00.txt, which, except for one minor issue,  has finished  
last call in DNSEXT) uses EDNS which has the appropriate failure  
mechanism.

BTW. I committed to review this document. Which I just did.

I agree with the content, I support this being published. But I find  
the first sentence of requirement 2 in section 3
almost incomprehensible:

  2.  The new mechanism SHOULD not require dedicated namespaces or
        other reserved values outside of the existing protocol  
mechanisms
        for these, i.e. the OPT pseudo-RR.

I suggest a rewrite.

  2-a. The new mechanism SHOULD not require dedicated namespaces.

  2-b. The new mechanism SHOULD not require reserved values outside
           of the existing protocol mechanisms such as EDNS0.

I think that means the same :-)

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 16 Dec 2005 16:03:25 +0000

> discussion in DNSOP is in fact not a good requirements document.

Actually, NSID was written from the same inputs as the current
serverid: the discussion in DNSOP and elsewhere on the need to
document the existing mechanism, its limitations, and proposed
parameters for what a better one would look like.

In other words, the serverid document has in fact already served the
specific purpose of documenting requirements. A protocol document was
then written around a mechanism for meeting the requirements, in a
group that does protocol work (DNSEXT).

Documenting where NSID came from is IMHO still worthwhile, although
the original intent was to have serverid published by now. However,
arguing that serverid is useless because NSID exists gets chronology
and causality both exactly backwards.

.

---

From: Daniel Senie <[email-masked]>
Date: Fri, 16 Dec 2005 11:06:35 -0500

At 10:52 AM 12/16/2005, Olaf M. Kolkman wrote:

>*** PGP SIGNATURE VERIFICATION ***
>*** Status:   Unknown Signature
>*** Signer:   Unknown Key (0x76092287)
>*** Signed:   12/16/2005 10:53:00 AM
>*** Verified: 12/16/2005 11:01:07 AM
>*** BEGIN PGP VERIFIED MESSAGE ***
>
>
>Hello Dan,
>

Good, some debate. Today, the server can send information in the 
additionals section. It's not clear to me whether or not additional 
information there would or would not affect resolver libraries. I 
suspect that any such approach would need to be worked on and debated 
by DNSEXT. My concern is that if this is a requirements document, 
then requiring some means of identification in the packets is one of 
the possible solutions that should be discussed.

>last call in DNSEXT) uses EDNS which has the appropriate failure

Good. Especially good if that document is close to publication, as it 
could be referenced by this one. (Indeed there are NO references in 
this draft to anything else, something that probably could be improved upon).

>*** END PGP VERIFIED MESSAGE ***

.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 16 Dec 2005 17:43:52 +0100

>  My concern is that if this is a requirements document, then  
> requiring some means of identification in the packets is one of the  
> possible solutions that should be discussed.

I tried to argue that the text that is currently in section 3 is  
sufficient.

> Good. Especially good if that document is close to publication, as  
> it could be referenced by this one. (Indeed there are NO references  
> in this draft to anything else, something that probably could be  
> improved upon).

That document describes an implementation of _these_ requirements :-)

--Olaf

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 17 Dec 2005 10:41:22 -0500

> discussion in DNSOP is in fact not a good requirements document.

I have reviewed draft-ietf-dnsop-serverid-05.txt, and I actually had
an opposite reaction to that outlined above: it seemed to me that it
_was_ a good requirements doc, because it first set out what the
current support is, and then outlined (in section 3) why that is
inadequate for the purposes.  In particular, it points out that a
subsequent request from the same resolver will not necessarily
provide good information about the service queried by some previous
resolver request.  That seems to me to motivate the requirement in
3.1, which is that there must be some mechanism to allow for the
identifying information to be part of a normal query.  (This also
strikes the right balance in not requiring that the information
_always_ comes back, since such information might break existing
resolvers.)

I do have an editorial nit about this doc, BTW, which is that the
references don't seem to be in it (or at least, not the copy I read,
which is at <http://www.ietf.org/internet-drafts/draft-ietf-dnsop-serverid-05.txt>).  
There's a reference to [RFC3258] on p2, a reference to [BIND] on p3,
and a reference to [RFC1034] on p4.  Other than that, I support this
document going forward.

A
-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

.