Subject: Re: [IAB] Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice

From: Marc Blanchet <[email-masked]>
Date: Tue, 17 Feb 2015 17:42:39 -0500

Hello,
 Many LC comments were about the stale reference to RSSAC001. This RSSAC001 has been posted in december, which shall solve many issues raised.  Moreover, a new version of the draft (-02) http://datatracker.ietf.org/doc/draft-iab-2870bis/  has been posted based on the comments. Below is a summary of LC comments and actions taken.

Regards, Marc.

http://www.ietf.org/id/draft-iab-2870bis-02.txt <http://www.ietf.org/id/draft-iab-2870bis-02.txt>

Marc.

=====
Summary of IETF LC comments on draft-iab-2870bis

A) mainly 2 individuals do not agree with the document approach, such as:
- IETF should not specify what root servers do
- should not be a BCP
- should not be split into 2 documents
- should only put historic to 2870bis
However, 6 individuals responded to those comments with supporting the document and its approach.
We still believe that this document is the right approach and have achieve rough concensus.

B) Comment: RFC2119 language is not appropriate for a BCP.  We believe that, while not a protocol specification, it provides recommendations to an implementation of the root service therefore we think it is appropriate to use this language.

C) Comment: Add text on fragmentation and MTU. We believe that this is more of operational nature and therefore should not be part of this document.

D)  Some noted that some root servers are not supporting IPv6 at the moment. We note that we are not talking about specific root servers but the root service. Some followup comments have replied to that effect. Therefore, we think this is ok as it is.

E) Comment: .arpa is not really part of the root zone. Moreover, the MAY does not do anything. We agree and removed that requirement.

F) some (non-substantive) text fixes were suggested that we agreed and implemented in the new version of the document.

G) a suggestion to add that  "IANA has a responsibility to publish [ROOTZONE], update the root hints, and ensure the root zone trust anchor is published ». We agree on the idea, but believe this is more on IANA role than root service and therefore enlarge the intended scope of the document, therefore we did not change the document, unless the AD thinks we should.

H) a suggestion to state that a root service may not answer queries in the presence of operational events such as DDOS or else.  We agree on the idea, however, we believe this is an example of operational issues that should not be discussed in this document, since it would require all kind of operational qualifications and text..

I) Many comments were reflecting the absence of RSSAC001 publication at the time of the IETF LC. The RSSAC01 document has now been published by RSSAC and it has a stable reference. The reference has been updated accordingly in the document. This should solve those many comments.

> Le 2014-05-20 à 16:42, The IESG <[email-masked]> a écrit :
> 
> 
> The IESG has received a request from the Internet Architecture Board 
> (iab) to consider the following document:
> 
> - 'DNS Root Name Service Protocol and Deployment Requirements'
>  <draft-iab-2870bis-01.txt> as Best Current Practice
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2014-06-20. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
>   The DNS Root Name service is a critical part of the Internet
>   architecture.  The protocol and deployment requirements expected to
>   be implemented for the DNS root name service are defined in this
>   document.  Operational requirements are out of scope.
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-iab-2870bis/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-iab-2870bis/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 17 Feb 2015 18:16:24 -0500

> Le 2015-02-17 à 18:07, Sam Hartman <[email-masked]> a écrit :
> 
> Hi.
> 
> 
> The message below sounds like it perports to be a judgment of consensus

I’m sorry. I probably need to revise the wording I used in the summary. I guess you are probably referring to the first item (A) in my summary.  Obviously, I did not want to claim any concensus, it is the AD and IESG to declare it.  And this is what is planned (IESG/AD to judge concensus).

Really sorry, I should have been careful about how I wrote it.  

Marc.

> and a summary of last call comments ffor a draft being published as IETF
> stream as a standards action.
> This document is authored by the IAB.
> 
> Mark Blanchet, the author of this message is an IAB member.
> 
> I have a huge process concern with this.  I'd expect that the person
> judging consensus for an IETF last call on a standards action would be a
> member of the IESG, and especially not one of the authors of the draft,
> which for an IAB document should include the entire IAB.
> 
>> From time to time the IESG might delegate that role to a document
> shepherd who is not a member of the IESG.  I'd expect that the IESG
> member would still ultimately judge consensus, but I can see a shepherd
> writing up an initial message.  I think such a delegation to an IAB
> member for an IAB document is entirely inappropriate.
> 
> I'm very uncomfortable with the apparent process here and believe that
> that to avoid doubt a member of the IESG needs to step in and make their
> own independent assessment of the last call comments.
> If my understanding is correct and we've already misstepped here, I
> think delegation would be inappropriate in this instance.
> 
> --Sam

---

From: Barry Leiba <[email-masked]>
Date: Tue, 17 Feb 2015 18:58:35 -0500

Sam, the document is in the IETF stream (NOT the IAB stream), and Jari
is the responsible AD.  Jari will, of course, do the usual job of the
responsible AD and will be the one responsible for evaluating
consensus, with the oversight of the IESG as a whole.

I don't see this as being any different to any individual submission,
which is what this looks like from a procedural point of view.

Barry

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 17 Feb 2015 19:14:23 -0500

> Le 2015-02-17 à 18:58, Barry Leiba <[email-masked]> a écrit :
> 

yes.

I think Sam was referring to my unappropriate use of the word concensus in first item of the summary, which caused confusion.

My bad.

Marc.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Feb 2015 18:07:22 -0500

Hi.

--Sam

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Feb 2015 15:37:21 +0200

Sam:

The document is on the IETF stream (it is going to BCP).

I have asked Marc in author role to provide a summary of where he believes we are and actions from his perspective. I think he is saying reasonable things, but it his summary. The responsible AD - me in this case - is watching this space and will eventually have to make a call to see if we are done.

Up-leveling a bit, the document is coming back to an active phase after being on hold since last summer. Now we are closer to being done than before, we have a matching document from RSSAC and a new version of the IETF draft, but we still need to be happy with that version in the IETF. Marc has posted the new version and a per-issue summary. It would be helpful to receive feedback on whether those are as they should be.

Jari

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Feb 2015 19:40:59 -0800

Greetings again. These are comments on the recently-issued -02 draft. Overall, it looks good, but there are still some issues to be addressed before publication.

The requirements in Section 2 should be clearly stated as being appropriate only for the authoritative name service. The last bullet says this, but the first bullet says "MUST implement core DNS [RFC1035] and clarifications to the DNS [RFC2181]." That could be interpreted as saying that the root name service must follow all the rules of RFC 1035, not just those that apply to authoritative name servers, and there are a bunch that should not be required. Consider changing that sentence fragment to "MUST implement core DNS [RFC1035] and clarifications to the DNS [RFC2181], as an authoritative name service".

Another bullet in Section 2 may be problematic:
      MUST generate checksums when sending UDP datagrams and MUST verify
      checksums when receiving UDP datagrams containing a non-zero
      checksum.
What happens if a root name server receives a UDP datagram with a bad checksum? It fails verification, but then what? This sentence *might* incorporate the following clarification, but I'm not sure if it actually matches the intent.
      MUST generate checksums when sending UDP datagrams, and MUST
      ignore a received UDP datagram containing a non-zero checksum
      when that checksum does not verify.
If that's not the intent, I'm not sure what "verify" means without a follow-on action.

Editorial:

- There are many places where spaces are missing, such as "domain name system(DNS)" and "IPv4[RFC0791]" (there are many others).

- The first sentence of the Introduction should be changed to reflect the fact that, when published, this document obsoletes RFC 2870. Instead of "[RFC2870] discusses", it should say "[RFC2870] discussed".

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Sun, 22 Feb 2015 07:51:18 +1100

In message <[email-masked]>, Paul Hoffman writes
:
> Greetings again. These are comments on the recently-issued -02 draft.
> Overall, it looks good, but there are still some issues to be addressed
> before publication.
>
> The requirements in Section 2 should be clearly stated as being
> appropriate only for the authoritative name service. The last bullet says
> this, but the first bullet says "MUST implement core DNS [RFC1035] and
> clarifications to the DNS [RFC2181]." That could be interpreted as saying
> that the root name service must follow all the rules of RFC 1035, not
> just those that apply to authoritative name servers, and there are a
> bunch that should not be required. Consider changing that sentence
> fragment to "MUST implement core DNS [RFC1035] and clarifications to the
> DNS [RFC2181], as an authoritative name service".
>
> What happens if a root name server receives a UDP datagram with a bad
> checksum? It fails verification, but then what?

The datagram gets dropped as bad.

> This sentence *might*
> incorporate the following clarification, but I'm not sure if it actually
> matches the intent.
> - There are many places where spaces are missing, such as "domain name
> system(DNS)" and "IPv4[RFC0791]" (there are many others).
>
> - The first sentence of the Introduction should be changed to reflect the
> fact that, when published, this document obsoletes RFC 2870. Instead of
> "[RFC2870] discusses", it should say "[RFC2870] discussed".
>
> --Paul Hoffman

What also needs to be there is a formal requirement to implement all
of EDNS (RFC6891).  There are lots of TLDs that fail to do this and
this causes problems for people trying to use the extension.  If TLD
operators do this today there is a chance that a root server operator
will also do this.
	
	See http://users.isc.org/~marka/tld-report.html

Also unknown record types RFC3597 must be supported.  While the
intent of RFC 1034 is that queries for unknown records get a
NOERROR/NXDOMAIN response we see a implementations returning REFUSED
and NOTIMP.  Note meta query types in the reserved meta range
(RFC5395) may still get NOTIMP.

We have operational problems deploying TLSA records as some nameservers
return NOTIMP or even drop TLSA queries (scrubbing services do this
today).

The last reserved bit in the DNS header should also be ignored if
present in a query and not be present in the response.   This is
implied by RFC 1034 but not formally stated.  There are nameserver
implementions that will drop such queries.  There are nameserver
implementions that will return FORMERR to such queries.  There are
nameserver implementions that will return NOTIMP to such queries

Root nameservers should be a future proof as possible in their handling
of queries.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Sun, 22 Feb 2015 08:32:27 -0500

--On Sunday, February 22, 2015 07:51 +1100 Mark Andrews
<[email-masked]> wrote:

>...

I'm not going to comment on the rest of this except to observe
that the Protocol Police (and associated judges and jails) have
been notably less available in the DNS area -- where many of the
TLD operator on whom you want to impose requirements not only
have a history of ignoring mandates but of being quite
articulate about their right to do so -- than in a variety of
others.

However...

> The last reserved bit in the DNS header should also be ignored
> if present in a query and not be present in the response.
> This is implied by RFC 1034 but not formally stated.  There
> are nameserver implementions that will drop such queries.
> There are nameserver implementions that will return FORMERR to
> such queries.  There are nameserver implementions that will
> return NOTIMP to such queries
> 
> Root nameservers should be a future proof as possible in their
> handling of queries.

If you want future-proofing, it is unwise to ignore any bit,
including reserved ones, unless you know in advance whatever its
implications are.  The requirement stated above changes the
status of that bit from "reserved, can be used for something in
the future if needed" to "reserved, can be used in the future
only for things that are safely ignored".  That is actually a
rather significant change.

     john

---

From: Mark Andrews <[email-masked]>
Date: Mon, 23 Feb 2015 11:40:32 +1100

> articulate about their right to do so -- than in a variety of

And as a result we have lookups that fail and lots of hacks being
deployed to try and work around the broken servers out there.

> rather significant change.

Not having well defined behaviour for reserved bits actually makes
them harder to use in the future.  RFC 103[45] doesn't say what to
do when the last reserved bit is used.  Today we have queries
dropped, FORMERR'd, REFUSED'd, NOTIMP'd, and ignored.  I really
don't care if the response is FORMERR, NOTIMP or ignored but we
should choose one and stomp out the others so that when we decide
to use the bit we don't have the mess [1] we had with the other
bits.  REFUSED seems to be a bit of a odd ball choice and dropping
the query is just not on.  DNS is after all a query-response protocol.

The last reserved flag bit should never appear in the reply of any
current nameserver as there is no reply construction path that sets
it in any RFC but there are implementations that incorrectly copy
the bit.  There isn't any text that says "copy reserved bits to the
reply".  The "id" field should be enough to identify the reply.
This includes FORMERR, REFUSED and NOTIMP replies.

Perhaps this should be reduced to "MUST NOT copy the reserved bit
to the reply if presented in a query".

BIND 9.11's dig (source.isc.org master branch) has a +zflag which
can be used to test server behaviour.

For comparison EDNS formally ignores unspecified/reserved EDNS flag
bits and also states do not return them in the reply if they are
set in the request (this was in the initial specification).  Similarly
unknown EDNS options are defined as to be ignored (the updated
specification added this).

[1] queries with ad=1 set get dropped by some servers.  ad=1 gets
blindly copied to the response without validition occuring and the
result being secure.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 25 Feb 2015 10:45:20 -0500

On Mon, Feb 23, 2015 at 11:40:32AM +1100, Mark Andrews wrote:

> bits.

If that is something you want, this document is certainly not the
place to do it.  That's a protocol specification change, and this
document is not altering the DNS protocol in any way.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 Feb 2015 11:26:49 +1100

> document is not altering the DNS protocol in any way.

Well reflecting back the bit isn't permitted and requiring that
such queries get answered are parts of the existing specification
which are not being followed.  Requiring just these parts be correctly
followed will make future deployment easier.

As for the other see draft-andrews-no-response-issue.