Subject: version -01 of draft-ietf-dnsext-dns-protocol-profile sent

From: George Michaelson <[email-masked]>
Date: Sun, 20 Jan 2008 17:14:18 +1000

I have just submitted a 01 revision of draft-ietf-dnsext-dns-protocol- 
profile, incorporating many of the comments from the namedroppers list.

Comments from Mark Andrews, Florien Weimer and Stephane Bortzmeyer  
weren't incorporated at this time, because
I couldn't see convergence on a clear, non-normative text change in  
the discussion. My instructions from Olafur are to
leave it to the WG to determine normative text, and only change when  
clear.

  A lot of non-normative changes such as spelling and syntactic fixes  
from Joe Abley and Wouter Wijngaards were incorporated wholesale,  
including getting rid of a specious reference to RFC1997 (BGP...) and  
updating several other RFC references. There are still many places in  
the document with text, lacking normative references entirely.

A couple of minor normative language changes from both Joe and Wouter  
were incorporated. I believe these did not alter the sense of the  
normative language, only its syntax.

A few new non-normative language references were introduced. For  
example the reference to NSID. Since this did not seem contentious,  
and is non-binding, I did it in the short term but if on reflection  
NSID is a problem area for people as couched, I can remove it again. I  
added slightly different references in for Authoritative Servers and  
Recursive Resolvers
since the RFC observes the transitive issue slightly differently in  
each case.

Some more deep, structural proposals from Wouter were not incorporated  
at this time. I believe I need to discuss these with
Olafur, since they imply a different approach to the document. I would  
say in the meantime that I think they made perfect sense in the main,  
and would simplify reading the document.

An ID issues tracker is obviously needed. I have sent some mail  
requesting assistance from one of the existing well known
ID tracker sites.

Paul Vixie's comments about XML are also valid, and I fully intend re- 
structuring the back-end XML into <include> form to
permit better editorial control of the text as it emerges, if the WG  
proceeds with this document.

Sam Weiler suggested that Olafur's instructions to the WG in respect  
of process might disagree with the statements in the -00
draft. I have not altered the document in that area, pending  
clarification of how people wish to proceed.

-George

----
12.  Changes since the -00 draft

Spelling, improved language and other editorial changes (which did not  
alter the substance of normative language) from the namedroppers list  
were incorporated wholesale. (jabley)

incorrect normative reference to 1997 removed. (jabley).

text from 3597 on Transparancy for unknown RRtypes included (jabley).

Better normative language for 4.1.1 (TCP Connection Management)  
adopted (jabley).

Better normative language for 4.2.2 (TCP) adopted (jabley).

Better normative language for 4.3 (UDP DNS Message Processing) adopted  
(jabley).

References for OPT processing clarified (jabley).

A section addressing [RFC 5001] in respect of NSID was added to the  
Server section and the Recursive Resolver section. (jabley)  
incorporated.

Editorial from ml adopted for key approach section (wijngaards)

incorrect normative reference to 1997 corrected to 2671 (wijngaards)

added normative reference to 4343 (wijngaards)

added normative reference to RRset TTL (wijngaards)

editoral text in respect of NOTIFY/UPDATE (wijngaards)

normative editorial text in respect of FORMERR TC bit (wijngaards)

--
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: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 24 Jan 2008 16:01:48 +0100

On Sun, Jan 20, 2008 at 05:14:18PM +1000,
 George Michaelson <[email-masked]> wrote 
 a message of 94 lines which said:

> weren't incorporated at this time, because I couldn't see
> convergence on a clear, non-normative text change in the discussion.

My comments about TCP? For the record, my opinion is that a name
server MUST offer (EDNS0 *or* TCP) access (or be declared broken
because it cannot handle large data which will become more and more
common). 

> An ID issues tracker is obviously needed.

+1 

I will record this issue as soon as we have tracker.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 24 Jan 2008 16:10:44 +0100

On Sun, Jan 20, 2008 at 05:14:18PM +1000,
 George Michaelson <[email-masked]> wrote 
 a message of 94 lines which said:

> I have just submitted a 01 revision of
> draft-ietf-dnsext-dns-protocol- profile,

It seems we still have a meta-issue. Is the document mostly for
implementors or mostly for operations people? 

From the fact that it is on this WG, or from notes like in section 1
("In particular, normative directions on features..."), one could say
that it is mostly for implementors.

But it also has a normative reference to RFCs 1033 (a very old purely
"operations" RFC), 1912, 2010...

And the text on TCP, section 4.2.2, says:

> The server MAY accept TCP connections.

which is very different from the section on EDNS0 (which says that
implementation MUST support it for name servers MAY disable it). Why
not a MUST here? Every name server software I know supports TCP, even
djbdns (http://cr.yp.to/djbdns/tcp.html). If we make a document for
implementors, a MUST here seems reasonable.

PS: an editorial comment: it's the first time I see this document
repository in IETF references:

   [NLNet-1]  Wijngaards, W., "NSD Requirements and Specifications",
              July 2006, </dev/null>.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 24 Jan 2008 16:26:36 +0100

Remarks on the content:

>   {non normative} The zone file format as specified in [RFC 1035
>   (5.1)] is optional.  It is used as a common presentation format
>   only.

I suggest:

The zone file format as partially specified in [RFC 1035 (5.1)] is
optional.  It is used as a common presentation format only.

Rationale:
http://www.psg.com/lists/namedroppers/namedroppers.2006/msg01025.html

> If delegations are present and glue information is required [...]
> [RFC 2181 (Section 5.2 para 2)]

"Required" is not well defined (think of loops between two TLD, for
instance, as in
http://www.ops.ietf.org/lists/namedroppers/namedroppers.199x/msg03693.html). (And
the reference to RFC 2181 is not clear for me, it does not talk about
glues at this place.)

>      *  OPCODE 1 (IQUERY) MUST result in RCODE=4 NOTIMPL [RFC 3425].
>         {has this actually been deprecated?}

It seems so. The RFC 3425 says "Therefore IQUERY is now obsolete, and
name servers SHOULD return a "Not Implemented" error when an IQUERY
request is received." Is is acceptable to change the SHOULD in a MUST?
The RFC is five years old so anyone should have upgraded since :-)

>      *  QDCOUNT!=1 SHOULD result in RCODE=1 FORMERR

A reference to
http://www3.tools.ietf.org/html/draft-ietf-dnsext-edns1 ?

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 24 Jan 2008 20:17:55 +0200

I have some comments on draft-ietf-dnsext-dns-protocol-profile-01:

> 4.2.2.  TCP
> 
>   {new normative language, maybe.. } The server MAY accept TCP
>   connections. {? what is the correct wording and reference?}

I would like to keep the current requirement from RFC1123 section
6.1.3.2 that servers SHOULD support TCP.  Two reasons for this are
1) to support answers that are too large to fit even in an EDNS0-extended
UDP packet, and 2) to support the use of fallback to TCP as part of
mechanisms to defend against query ID guessing attacks.

> 4.3.  DNS Message processing
[...]
>   *  The TC bit answer FORMERR MUST not have the TC bit set.
>   *  RCODES SHOULD ignored.

I have trouble parsing the two above bullet points.

> 4.6.  Label compression in RDATA
> 
>    [RFC 1035 (section 3.3. and 4.4.1)] ("Pointers can only be used for
>    occurrences of a domain name where the format is not class
>    specific.")
> 
>    Do label compression for labels in rdata for which this is
>    specifically mentioned in the RFC defining the RR.
>    o  NS, SOA, CNAME, and PTR [RFC 1035 (3.3)].
>    o  Others defined in [RFC 1035 (3.3)]are not compressed.
>    o  MB, MG, MR, MINFO, MX also have compressed dnames.  These RRs and
>       their compression are described in [RFC 1035].

I find it confusing that the list of RR types from RFC1035 subject to
compression is split into two bullet points separated by an unrelated
bullet point.

>    o  AFSDB, RP, RT [RFC 1183, (Section 1,2 & 3.3.3)].

This seems to imply that a server may compress names in AFSDB, RP, and
RT when sending them.  That is incorrect; [RFC 3597] says names in
these record types MUST NOT be compressed, but SHOULD be decompressed
if received in a compressed form.

>    o  You MUST follow the rules in [RFC 3597].

Perhaps this should be at the beginning of the section rather than at
the end, since RFC3597 is the the current specification of the
compression rules and the rest of the section is basically reiterating
those rules.

> 4.7.  Truncation handling
> 
>    Truncation handling is as specified in [RFC 2181 (9)].
> 
>    {TBD normative text for this section.  RFC references required.} If
>    inclusion of a RR set that is REQUIRED in either the answer or
>    authority section leads to message truncation.  The section is left
>    empty and the truncation (TC) bit is set.  If the DO bit is set RRSIG
>    RRs are required in the answer and authority section.
>
>    If inclusion of an RRset in the Additional section is not possible
>    RRs are omitted one by one.  This may lead to incomplete RRsets.
>    Omission of RRs from the Additional section because of message size
>    constraints will NOT lead to setting of the TC bit.  [RFC 2181 (9)].

According to RFC2181, incomplete RRsets are allowed when TC is set
but not when it is clear.  The above text says the opposite.
-- 
Andreas Gustafsson, [email-masked]

---

From: Ralf Weber <[email-masked]>
Date: Thu, 24 Jan 2008 22:13:38 +0100

Moin!

> implementors, a MUST here seems reasonable.
AFAIR (it's been some time since I used it) djbdns only does zone
transfers over DNS (and even these are strange sometimes), it does not
answer normal DNS request via TCP.

But anyway I would say a modern server either has to support EDNS or
TCP, and I would put a MUST here, at least I support Andreas that we
shouldn't fall behind the original SHOULD for TCP.

So long
-Ralf
---
Ralf Weber
Platform Infrastructure Manager
Colt Telecom GmbH
Herriotstrasse 4
60528 Frankfurt
Germany
DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780
Fax: +49 (0)69 56606 6280
Email: [email-masked]
http://www.colt.net/

Data | Voice | Managed Services

*****************************************
COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland *
Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 *
Geschäftsführer: Albertus Marinus Oosterom (Vors.), Rita Thies *
Amtsgericht Frankfurt/Main HRB 53898 * USt.-IdNr. DE 220 772 475

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 24 Jan 2008 22:30:52 +0100

On Thu, Jan 24, 2008 at 10:13:38PM +0100,
 Ralf Weber <[email-masked]> wrote 

> transfers over DNS (and even these are strange sometimes), it does
> not answer normal DNS request via TCP.

That's not true and the Web page I mentioned explains why and how.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 25 Jan 2008 09:27:46 +1100

> mechanisms to defend against query ID guessing attacks.

	I would make TCP a MUST for a recursive server.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Fri, 25 Jan 2008 13:50:56 +0100

> implementors or mostly for operations people? 

Good question.  It probably makes sense to target implementors because
it's easier to get consensus about protocol aspects.

> implementors, a MUST here seems reasonable.

A MUST would be new normative language, but clean and simple.  "SHOULD
support TCP connections, and it MUST support TCP connections for a
specific client if it has ever responded to that client with the TC
bit set" would be new language as well, but is closer to the minimum
requirement.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Kenji Rikitake <[email-masked]>
Date: Sun, 27 Jan 2008 22:42:03 +0900

In the message <[email-masked]>
dated Thu, Jan 24, 2008 at 10:13:15PM +0100,
> answer normal DNS request via TCP.

For the dns servers in djbdns-1.05:

tinydns, rbldns, walldns (all authoritative servers) 
DOES NOT respond to TCP queries.

dnscache DOES respond to TCP queries (as a cache).

axfrdns also DOES accept TCP queries.

// Kenji Rikitake

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 28 Jan 2008 10:29:42 +0100

On Sun, Jan 27, 2008 at 10:42:03PM +0900,
 Kenji Rikitake <[email-masked]> wrote 

> DOES NOT respond to TCP queries.

According to their documentation, it is not true:

http://cr.yp.to/djbdns/tcp.html

The implementation DOES reply to TCP queries. The DEFAULT setup turns
it off and, as a result, most running INSTANCES do not reply to TCP
queries.

That is a perfect illustration of the question I was asking (and on
which I do not see a consensus). If the "profile" document says "DNS
servers MUST reply to TCP", is djbdns illegal or not? Is a given
instance of djbdns illegal or not?

---

From: Kenji Rikitake <[email-masked]>
Date: Mon, 28 Jan 2008 22:40:16 +0900

In the message <[email-masked]>
dated Mon, Jan 28, 2008 at 10:29:19AM +0100,
> it off and, as a result, most running INSTANCES do not reply to TCP

If you want to run an authoritative server listening both on TCP and UDP
port 53 for djbdns, you need to run two programs listening to the same
IP address; tinydns for UDP, axfrdns for TCP.  

djbdns-1.05's tinydns does not listen to TCP 53 port. See Makefile and
server.c of djbdns-1.05 code.  

> instance of djbdns illegal or not?

So long as you can run djbdns to listen to both TCP and UDP for both
non-recursive or recursive server, I think a rational answer to the
question is that djbdns CAN be run to meet the condition that "DNS
servers MUST reply to TCP". 

I don't feel like continuing on this does-or-does-not topic for
djbdns is appropriate on the namedroppers list because this is an
implementation-specific issue.  

// Kenji Rikitake

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Jan 2008 17:17:51 +0000

> it off and, as a result, most running INSTANCES do not reply to TCP

i had no idea that axfrdns also answered normal (non-AXFR) queries.  thanks.

> instance of djbdns illegal or not?

there is no law on the internet and so the word "illegal" doesn't apply.
there's only "will it work" and "will it scale" and "will it cause people
to send me mail complaining" and "does it have rfc checkbox compatibility
for my purchasing department."  for all of those reasons, djbdns ought to
default all of its installations to answering tcp, even if it retains a
knob to allow some nameserver operators to turn it off due to local policy.

in http://cr.yp.to/djbdns/tcp.html#why (part of the link you sent), it
failed to mention "the other end might be temporarily or permanently
firewalled in a way that keeps udp/53 from working for them".  on the
internet, other people's networks govern many of our policies and actions.