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

From: Jari Arkko <[email-masked]>
Date: Thu, 5 Mar 2015 04:56:49 +0200

>> 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,
> 
> 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.

For what it is worth, I agree with Andrew that this document is
not a protocol specification, and these other things belong
elsewhere. And it seems you have a draft already, so…

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 5 Mar 2015 04:57:19 +0200

Hi Paul,

and thanks for your review.

> 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”.

I think this seems reasonable. Marc?

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

I would not like to specify protocol in this document. It would be best if one of the referenced documents already said this, and we could simply add a reference. Do they?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 5 Mar 2015 05:43:49 +0200

I wanted to come back to the status of the discussions.

We have an ongoing discussion of the changes Marc made on the -02. My read of the feedback is that the update has done the right things, but:

1) Paul Hoffman’s clarifications & editorial changes seem useful, but I would like to hear what others think. Marc, you should respond to those as well.

2) Mark Andrews’ suggestion of further requirements regarding reserved bits was discussed, but should proceed separately.

3) Mark Andrews' suggestion of further requirements regarding EDNS0 has not been discussed, but I would note that at this stage we should not add major requirements without substantial community portion indicating that this is needed. I’m not hearing it.

4) I’ve also received feedback from IESG members that the text about moving 2870 to Historic in Section 1.1 could be problematic. While I’m not sure that is necessarily the case, I think this draft merely replaces 2870, so I am not sure we need to say anything more. I have confirmed with the IAB that it does not believe the part about moving 2870 to Historic is necessary. Does anyone object to this change?

With regards to the earlier discussions in the last call in the summer, Marc’s message discussed some of the things where an agreement was clearly found. I don’t think I need to report further on that. However, I wanted to highlight a few other items:

I believe there is rough consensus to publish an updated BCP (subject to some detailed clarifications, still ongoing). There was some discussion about whether it is appropriate for the IETF to do this, but my read of the discussion is that the topic was explored and that a reasonable division of work between the RSSAC and IETF exists, even with some roughness of the opinions within the group. The IETF role in this case is to provide high-level requirements for the service. Specifically for this service, even if some broader statements have been made about all nodes previously. But is not our role to enforce anything or deal with the operational issues.

There was some discussion of the meaning of the requirements currently in the document, and whether clarifying text was needed to specify whether they apply to individual nodes or the service. Michael Richardsson (among others) has supported the current text as it really is about the service. This is another topic where there is some roughness in the group, but I believe the initial question has been adequately answered and has at least some support in the group.

A big problem last summer was that we did not yet have a document from the RSSAC. With the stable RSSAC document now available, it is possible to proceed.

From my read of the commentary, the following items may deserve further thought. Marc, can you deal with these?

* Joe Abley’s comment about qualifying the requirement to answer queries from any valid IP address with respect to operational events (such as attacks). While I believe the operational issues are indeed in the RSSAC scope, I think we should qualify our requirement to be subject to operational issues.

* Klaas Wieranga’s Secdir review made a suggestion about privacy related to root queries, and how caching mitigates some of the concerns. Text could be added about this, although it is of course somewhat obvious state of affairs. I’ll leave it to the editor’s discretion what to do here.

Jari

---

From: Mark Andrews <[email-masked]>
Date: Thu, 05 Mar 2015 15:25:19 +1100

In message <[email-masked]>, Jari Arkko writes:
> elsewhere. And it seems you have a draft already, so...

There is follow the existing RFC and clean up ambiguities.  The
error code selection is cleanup.  The non reflecting of reserved
bit and correct EDNS behaviour are existing behaviour.  Expecting
root servers to follow the defined parts of the protocol should be
a no brainer.

The draft-andrews-dns-no-response-issue isn't formally changing
anything.  It is pointing out a real problem and it is requesting
that parent zone operators, in particular TLD and public SLD
operators, regularly audit the servers that they are delegating
namespace to for compliance and to report non-compliance even if
that has to go through a intermeditory.  It's also providing something
that the delegated zone operators / nameserver vendors can check
their servers with.

I'm not sure that it would be the best document to update RFC
103[45].  It would be scope creep to do so.  I think something more
like RFC 2181 would be more appopriate for that.  I don't mind
working on such a document.

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

---

From: Pete Resnick <[email-masked]>
Date: Wed, 4 Mar 2015 22:36:59 -0600

On 3/4/15 9:43 PM, Jari Arkko wrote:
> 1) Paul Hoffman’s clarifications&  editorial changes seem useful, but I would like to hear what others think.
>    

I think Paul's suggested change to the first paragraph in section 1 is 
spot on. Now that RSSAC has completed RSSAC001, perhaps something like:

OLD
The operational requirements are defined in [RSSAC-001]. This
document defines the protocol requirements and some deployment
requirements.
NEW
This document only defines the protocol requirements and some
deployment requirements; the operational requirements that were
defined in RFC 2870 are removed. Operational requirements are
now defined by the Root Server System Advisory Committee of ICANN
and are documented in [RSSAC-001].

And then remove the second paragraph of 1.1, which becomes unnecessary.

> 4) I’ve also received feedback from IESG members that the text about moving 2870 to Historic in Section 1.1 could be problematic. While I’m not sure that is necessarily the case, I think this draft merely replaces 2870, so I am not sure we need to say anything more.

Yeah, I'm one of the folks who thinks "Historic" is unnecessary (and 
potentially a pain). The fact that this is obsoleting 2870 is 
sufficient, and all it really needs to do is replace 2870 in the BCP 
series by adding "BCP: 40 (if approved)" to the top. I'd just make that 
change and strike section 1.1 entirely.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Mark Andrews <[email-masked]>
Date: Thu, 05 Mar 2015 15:41:21 +1100

In message <[email-masked]>, Jari Arkko writes:
> We have an ongoing discussion of the changes Marc made on the -02. My
> read of the feedback is that the update has done the right things, but:
>
> 1) Paul Hoffman's clarifications & editorial changes seem useful, but I
> would like to hear what others think. Marc, you should respond to those
> as well.
>
> 2) Mark Andrews' suggestion of further requirements regarding reserved
> bits was discussed, but should proceed separately.
>
> 3) Mark Andrews' suggestion of further requirements regarding EDNS0 has
> not been discussed, but I would note that at this stage we should not add
> major requirements without substantial community portion indicating that
> this is needed. I'm not hearing it.

I suspect this is because the root servers actually correctly
implement EDNS.  If a server was changed to a implementation that
failed to correctly implement EDNS that would change.  There are a
number of drafts before dnsop at the moment that require EDNS to
be properly implement.  I'm a co-author of one of them.

> 4) I've also received feedback from IESG members that the text about
> moving 2870 to Historic in Section 1.1 could be problematic. While I'm
> not sure that is necessarily the case, I think this draft merely replaces
> 2870, so I am not sure we need to say anything more. I have confirmed
> with the IAB that it does not believe the part about moving 2870 to
> Historic is necessary. Does anyone object to this change?
>
> With regards to the earlier discussions in the last call in the summer,
> Marc's message discussed some of the things where an agreement was
> clearly found. I don't think I need to report further on that. However, I
> wanted to highlight a few other items:
>
> I believe there is rough consensus to publish an updated BCP (subject to
> some detailed clarifications, still ongoing). There was some discussion
> about whether it is appropriate for the IETF to do this, but my read of
> the discussion is that the topic was explored and that a reasonable
> division of work between the RSSAC and IETF exists, even with some
> roughness of the opinions within the group. The IETF role in this case is
> to provide high-level requirements for the service. Specifically for this
> service, even if some broader statements have been made about all nodes
> previously. But is not our role to enforce anything or deal with the
> operational issues.
>
> There was some discussion of the meaning of the requirements currently in
> the document, and whether clarifying text was needed to specify whether
> they apply to individual nodes or the service. Michael Richardsson (among
> others) has supported the current text as it really is about the service.
> This is another topic where there is some roughness in the group, but I
> believe the initial question has been adequately answered and has at
> least some support in the group.
>
> A big problem last summer was that we did not yet have a document from
> the RSSAC. With the stable RSSAC document now available, it is possible
> to proceed.
>
> * Joe Abley's comment about qualifying the requirement to answer queries
> from any valid IP address with respect to operational events (such as
> attacks). While I believe the operational issues are indeed in the RSSAC
> scope, I think we should qualify our requirement to be subject to
> operational issues.
>
> * Klaas Wieranga's Secdir review made a suggestion about privacy related
> to root queries, and how caching mitigates some of the concerns. Text
> could be added about this, although it is of course somewhat obvious
> state of affairs. I'll leave it to the editor's discretion what to do
> here.
>
> Jari

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Mar 2015 20:42:54 -0800

> I would not like to specify protocol in this document. It would be best if one of the referenced documents already said this, and we could simply add a reference. Do they?

Oddly, that doesn't appear in any of the DNS-related RFC I know of. It is not in the "base" DNS RFCs of 1034 & 1035 & 2181, nor is it in 5966 (DNS use of TCP). Of the ~100 DNS-related RFCs that Standcore has reviewed in the DNS conformance testbed, RFC 1912 has the same wording about verifying UDP checksums without saying what to do if there is a verification failure, and 1995 has advice of what to do if the checksum is 0. Other than that, 2870 is the only other RFC that mentions UDP checksums.

Maybe there is a UDP-specific RFC that says what to do when you get a failed checksum.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Thu, 05 Mar 2015 15:55:34 +1100

In message <[email-masked]>, Paul Hoffman writes
:
> >> 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? This sentence *might*
> incorporate the following clarification, but I'm not sure if it actually
> matches the intent.
> > I would not like to specify protocol in this document. It would be best
> if one of the referenced documents already said this, and we could simply
> add a reference. Do they?
>
> Oddly, that doesn't appear in any of the DNS-related RFC I know of. It is
> not in the "base" DNS RFCs of 1034 & 1035 & 2181, nor is it in 5966 (DNS
> use of TCP). Of the ~100 DNS-related RFCs that Standcore has reviewed in
> the DNS conformance testbed, RFC 1912 has the same wording about
> verifying UDP checksums without saying what to do if there is a
> verification failure, and 1995 has advice of what to do if the checksum
> is 0. Other than that, 2870 is the only other RFC that mentions UDP
> checksums.
>

You drop it possibly incrementing a error counter.  There really
isn't anything else sane to do.  If the checksum doesn't match you
have no idea what part of the UDP packet is wrong or if it even is
a UDP packet.

Mark

---

From: Jari Arkko <[email-masked]>
Date: Thu, 5 Mar 2015 10:47:39 +0200

> failed to correctly implement EDNS that would change.

Perhaps. What do others think?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 5 Mar 2015 14:56:35 +0200

I wanted to add one thing that I said yesterday - while we can make changes
if there is a good reason and significant community support to do so, I think
we also want to be careful to not to cause RSSAC to rerun discussions,
as the two documents are proceeding in some sense together.

So lets make the changes we need to, but not more than that.

Jari

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Mar 2015 08:41:50 -0800

> Perhaps. What do others think?

Mark's proposed addition of EDNS0 is a very nice thing to have. If all the root servers always responding to queries that have EDNS0 with EDNS0 in their responses, the DNS would be operationally more stable, particularly as response sizes increase over time.

However, it seems inappropriate for the IETF to say "and here is the exact list of protocol bits that we require for the root service" when we are sure that servers using few of those bits will work adequately. Also, it is important to note that RSSAC-001 says:

[E.3.2 - A] Individual Root Servers will adopt or continue to implement the current DNS protocol and associated best practices through appropriate software and infrastructure choices.

EDNS0 very clearly falls under "best practices": no one can deny that. So, to some extent, the expectation is already on the root server operators to use EDNS0. It's not clear if the IETF saying "here's a thing we insist on" will help the cause.

Further note: just saying "EDNS0" is not sufficient: we would have to say which features, options, and extensions would be needed. This is "obvious" to many folks, and not at all clear to others.

--Paul Hoffman

---

From: Jari Arkko <[email-masked]>
Date: Thu, 5 Mar 2015 18:43:39 +0200

> EDNS0 very clearly falls under "best practices": no one can deny that. So, to some extent, the expectation is already on the root server operators to use EDNS0. It's not clear if the IETF saying "h…

Seems reasonable. Thanks.

Jari

---

From: manning bill <[email-masked]>
Date: Thu, 5 Mar 2015 09:00:04 -0800

EDNS is essential for the implementation of DNS Security Extensions.   All roots support DNSSEC.
Calling out EDNS0 at this time is moot.

(I’ll say that 2870bis is on thin ice, since the IETF/IAB have no leverage on root server operators.  This community can pontificate at length, but the actual operations will
dictate, not some wish list from an “arms-length” standards body…  Just sayin’)

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Mar 2015 09:37:14 -0800

> Calling out EDNS0 at this time is moot.

Bill's exactly right here. From Section 3 of RFC 4035:

   A security-aware name server MUST support the EDNS0 ([RFC2671])
   message size extension, MUST support a message size of at least 1220
   octets, and SHOULD support a message size of 4000 octets.

So EDNS0 support for the part we care about most, message size, is already in draft-iab-2870bis as a side-effect of the last bullet of Section 2 of draft-iab-2870bis.

--Paul Hoffman

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Mar 2015 12:39:48 -0500

--On Thursday, March 05, 2015 09:00 -0800 manning bill
<[email-masked]> wrote:

>...
> (I'll say that 2870bis is on thin ice, since the IETF/IAB
> have no leverage on root server operators.  This community can
> pontificate at length, but the actual operations will dictate,
> not some wish list from an "arms-length" standards body…
> Just sayin')

Bill,

Addressing this one issue only:

(1) Yes.

(2) On the other hand, RSSAC and/or "the root server operators"
have never been what I think are called "multistakeholder
consensus bodies".  Arguably, neither is the IETF but there is
definitely a difference in terms of conditions for entry into
the group and openness of participation and the consensus
process.   So, especially in the middle of controversies about
IANA transition and accountability of various parts of the
system, to say, effectively, "the root server operators will do
whatever they feel like and no one has any leverage on them" is
an invitation to demands for policy oversight of RSSAC and the
root server operations process by folks who represent a broader
stakeholder base.

Perhaps the "Caucus" is intended to serve that multistakeholder
role, but it isn't clear that it can do anything other than
advise and its membership is appointed by the RSSAC, not the
broader community.

If you and/or the root server operations community don't want to
risk ending up in a multistakeholder situation that it can't
control, some explicit respect for guidance from the IAB and/or
IETF might serve that community's interests in the long term.
Indeed, if I were part of that community and wanted to see more
or less the status quo preserved, I'd be looking to replaced or
supplement 2870bis with an explicit MOU or other agreement about
IETF and/or IAB review or supervision.   However obnoxious that
might be, I'm certain it would be preferable to effective
oversight by some body dominated by ICANN politics.

best,
     john

---

From: manning bill <[email-masked]>
Date: Thu, 5 Mar 2015 09:46:25 -0800

John, the remark was to temper what might become unrealistic expectations on the reach of the IAB/IETF
into -ANY- organizational operational practice.

That said, I do not wish to derail this document, just ensure that the caveat is in place before it is enshrined
as holy writ.

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Mar 2015 08:48:27 +1100

In message <[email-masked]>, Paul Hoffman writes
:
> Mark's proposed addition of EDNS0 is a very nice thing to have. If all
> the root servers always responding to queries that have EDNS0 with EDNS0
> in their responses, the DNS would be operationally more stable,
> particularly as response sizes increase over time.
>
> However, it seems inappropriate for the IETF to say "and here is the
> exact list of protocol bits that we require for the root service" when we
> are sure that servers using few of those bits will work adequately. Also,
> it is important to note that RSSAC-001 says:
>
> [E.3.2 - A] Individual Root Servers will adopt or continue to implement
> the current DNS protocol and associated best practices through
> appropriate software and infrastructure choices.
>
> EDNS0 very clearly falls under "best practices": no one can deny that.
> So, to some extent, the expectation is already on the root server
> operators to use EDNS0. It's not clear if the IETF saying "here's a thing
> we insist on" will help the cause.
>
> Further note: just saying "EDNS0" is not sufficient: we would have to say
> which features, options, and extensions would be needed. This is
> "obvious" to many folks, and not at all clear to others.

You comment makes no sense.  Please go read RFC 6891 (it fixed the
handling of unknown EDNS options, RFC 2671 failed to state the
behaviour).

EDNS version 0 is a frame work.  There are almost no extensions
there.  There are no EDNS options defined.  There are no EDNS
flags (DO is listed as existing but that is defined in RFC3225).
There are is just the initial version of 0.  And the ability to
offer a larger EDNS UDP size.  It tells you the expected behaviour
when you get a unknown EDNS option (ignore), a unknown EDNS flag
(ignore), a unknown EDNS version (return BADVERS w/ highest version
you support).

RFC3225 adds the DO flag which should be supported as DNSSEC is
required.  Yes, there are servers that do DNSSEC but don't correctly
handle DO (it is not echoed in the response).  The current root
servers are do not exibit this mis-behaviour.  This however comes
from requiring DNSSEC support not EDNS support.  The reports only
flag DO when RRSIGs are returned indicating that DNSSEC is supported
by the server.

It is the well defined behaviour when presented with unknown
extensions that is needed.  That is what I test conformance to in
http://users.isc.org/~marka/tld-report.html.  Failure to follow the
well defined behaviour when presented with unknown extensions is
what causes interoperability problems and cause resolvers to do
trial and error.

If you want to see how bad other server implementations can be see:

http://users.isc.org/~marka/gov-report.html
http://users.isc.org/~marka/au-report.html
http://users.isc.org/~marka/bottom-report.html
http://users.isc.org/~marka/alexa-report.html

We really don't want the errors that show up in these reports
appearing on root servers.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Mar 2015 09:03:27 +1100

> Calling out EDNS0 at this time is moot.

Actually there are implementations that do DNSSEC fine but botch
EDNS.  We have drafts coming through the IETF that expect full EDNS
version 0 compliance to work without having to do gross hacks like
dealing with incorrectly returned FORMERR, BADVERS and queries being
dropped because they happen to try to use a extension.

The current root servers get this right.  This is about preventing
things going wrong in the future.  It is also about TLDs and others
that use the root server requirements as a basis for their requirements.

Mark

> (I'll say that 2870bis is on thin ice, since the IETF/IAB have no
> leverage on root server operators.  This community can pontificate at
> length, but the actual operations will
> dictate, not some wish list from an "arms-length" standards body...
>   Just sayin')
>
> /bill
> PO Box 12317
> Marina del Rey, CA 90295
> 310.322.8102

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Mar 2015 18:28:07 -0500

On Fri, Mar 06, 2015 at 08:48:27AM +1100, Mark Andrews wrote:
> from requiring DNSSEC support not EDNS support.

I would like to understand exactly what you mean by, "Do DNSSEC but
don't correctly handle DO."  That sounds to me like the kind of do
DNSSEC, not that they do it properly.  DNSSEC requires EDNS0, full
stop; therefore any additional text on the matter is unnecessary.

Moreover, see upthread the exchange between Bill Manning and John
Klensin.  I think if we have a root server operator that starts
running some dodgy implementation of some name server code, the root
server operators are going to have a worse day of it than the IETF.  I
think we should specify exactly what we need and no more.  Since
DNSSEC entails EDNS0 support, we're done.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Mar 2015 10:57:42 +1100

> stop; therefore any additional text on the matter is unnecessary.

To get the DNSSEC records added the the responses the server needs
to be able to see the DO=1 bit.  It does not need to properly handle
unknown EDNS options.  It does not need to properly handle unknown
flags.  It does not need to properly handle EDNS version != 0.  It
does not need fully handle DO by adding DO=1 to the response.

I'm sure all the TLD operators listed in tld-report.html [1] with
broken implementations think they are doing EDNS correctly.

[1] http://users.isc.org/~marka/tld-report.html

When only 65% of the world gets EDNS support right I don't think it
unreasonable to make fully compliant EDNS support a requirement.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Mar 2015 20:51:31 -0500

On Fri, Mar 06, 2015 at 10:57:42AM +1100, Mark Andrews wrote:
> to be able to see the DO=1 bit.

Last I checked, the draft was a requirements document, not an
enforcement checklist for the heretofore missing Protocol Police
Force.  If you could point to a piece of the relevant RFCs that make
partial EDNS support or something like that acceptable to make DNSSEC
work, then I think you'd have an argument.  So far, you have not
offered such an argument.

> broken implementations think they are doing EDNS correctly.

The draft before us has absolutely nothing to do with TLD operations.
As you've pointed out repeatedly, you have written some drafts on the
topic of not being foolish when operating DNS servers.  I'm sure the
IETF will, in due course, give those drafts the attention they
deserve.  In the interim, however, I don't see how all those other
levels of the DNS are entirely relevant to the present discussion, and
I think we ought to stick to this topic.  You have not made an
argument that is specifically relevant to the root and that addresses
the formal dependence of DNSSEC on EDNS.  Therefore, I believe your
suggested changes should not be incorporated.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Mar 2015 15:07:42 +1100

In message <[email-masked]>, manning bill writes:
> wait...
>  is RFC 2870bis for TLDS or the roots?  (I'll note that conflation of
> roots and tlds was part of the problem with RFC 2870...
> )

EDNS, when done, needs to be properly done by both.

---

From: Lars-Johan Liman <[email-masked]>
Date: Fri, 06 Mar 2015 13:01:38 +0100

>> 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”.

> I think this seems reasonable. Marc?

(Stepping in as "the other author".)

I agree it makes sense. I'm working on text for -03.

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

> I would not like to specify protocol in this document. It would be
> best if one of the referenced documents already said this, and we
> could simply add a reference. Do they?

I agree to keep protocol spec out of this document. The document should
only refer to other documents and say "these (parts of) documuments
SHOULD/MUST be followed".

If there are docs that specify what a host should do with such
"malchecksummed" packets, I'm happy to put a pointer in there. If not,
I'd rather avoid discussing it in this draft.

				Cheers,
				  /Liman
#----------------------------------------------------------------------
# Lars-Johan Liman, M.Sc.               !  E-mail: [email-masked]
# Senior Systems Specialist             !  Tel: +46 8 - 562 860 12
# Netnod Internet Exchange, Stockholm   !  http://www.netnod.se/
#----------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Fri, 6 Mar 2015 14:21:47 +0200

> I'd rather avoid discussing it in this draft.

That may be the best approach. That is, not start specifying protocol in this document, unless it is just a reference.

FWIW, I re-read 1035 and 2181 and 768 quickly, and did not see such a statement. But I could have missed it. Or it may have been considered to be obvious :-)

Jari

---

From: Lars-Johan Liman <[email-masked]>
Date: Fri, 06 Mar 2015 13:27:10 +0100

> dropped because they happen to try to use a extension.

Man, you must see a lot of bad sh*t in your professional life. :-) I
cannot even wrap my head around the concept of doing DNSSEC fine while
botching EDNS, but I know you well enough to take your word for it. :-)

> that use the root server requirements as a basis for their

I do note that the current draft specifies "MUST do DNSSEC", which to me
sounds like "and therefore needs to do EDNS". I wouldn't really mind
adding EDNS to the draft, except, as noted earlier, it's just a
framework, and specifying which parts of it must be implemented isn't a
friendly slope to slide along. It also begs for other stuff to be
listed, and we (again) risk ending up with legalese like "... including,
but not limited to ..." - which I don't favour.

And there's the text in RSSAC-001.

I think I agree with Jari (if this is what you meant, Jari? ;-), that
the current wording in _these_ documents (draft + RSSAC-001) is
sufficient, and that work should be put into firming up the DNS specs in
general, so that the "rubber wheel" clauses in RSSAC-001 get some "real
tarmac" to work with and get good traction.

So my current inclination wrt. this, is to leave the relevant text parts
unchanged for -03 (which we seem to have to produce ...).

				Cheers,
				  /Liman

---

From: Lars-Johan Liman <[email-masked]>
Date: Fri, 06 Mar 2015 14:01:10 +0100

[email-masked]:
>> not some wish list from an "arms-length" standards body...
>> Just sayin')

> advise and its membership is appointed by the RSSAC, not the

RSSAC is not your (their) target.

Just to make it clear (and this is something I have to do repeatedly in
many situations):

RSSAC is an advisory body that advices

1) The ICANN Board of Directors,

2) The DNS and Internet communities in general,

on matters that relate to the DNS root zone administration and the root
server system.

It is _NOT_ a vehicle to impose restrictions and regulation on the root
server operators.

You correctly note "... and the root server process ...", but I think
your fears should be limited to that, because RSSAC is not the
appropriate target for said folks.

> IETF might serve that community's interests in the long term.

This draft is intended to be one step in that direction.

> oversight by some body dominated by ICANN politics.

Hmm.

				Cheers,
				  /Liman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Mar 2015 07:43:28 -0800

> FWIW, I re-read 1035 and 2181 and 768 quickly, and did not see such a statement. But I could have missed it. Or it may have been considered to be obvious :-)

It is clear that the latter is the case. As Mark points out, if you get a UDP packet with a malformed checksum, you don't even know if it was actually a UDP packet.

Given that, I withdraw my request that this document actually specify what to do when one cannot verify a UDP packet, unless there is a statement about that in some (probably early) UDP document.

--Paul Hoffman

---

From: manning bill <[email-masked]>
Date: Thu, 5 Mar 2015 16:03:48 -0800

wait… is RFC 2870bis for TLDS or the roots?  (I’ll note that conflation of roots and tlds was part of the problem with RFC 2870…)

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: manning bill <[email-masked]>
Date: Thu, 5 Mar 2015 23:00:56 -0800

soooo this is an edns0 document and not really RFC 2870bis.

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Mar 2015 12:46:56 -0400

> 4) I’ve also received feedback from IESG members that the text about moving 2870 to Historic in Section 1.1 could be problematic. While I’m not sure that is necessarily the case, I think this draft…

Somewhat belatedly, what struck me about this is that we are obsoleting a BCP document and replacing it with an ICANN document the PDF for which has the word DRAFT emblazoned in large friendly letters on every page.   What gives here?   If we are replacing a BCP with some document, hadn't that document ought to be a finished document?   I don't object to the change in principle, but it seems a bit weird to make the change when part of what is obsoleting 2870 is a document that's not been published yet.

I guess it's easier to do it in one step than two, but if what we are really doing is ceding authority to ICANN for specifying how root servers are operated, shouldn't we say that rather than referencing an ICANN work-in-progress document?   I think that is what we are effectively doing whether we say so explicitly or not.

I apologize if all this has already been discussed, but I can't find a discussion of this specific issue in the mailing list archives.

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 11 Mar 2015 12:55:21 -0400

> Somewhat belatedly, what struck me about this is that we are obsoleting a BCP document and replacing it with an ICANN document the PDF for which has the word DRAFT emblazoned in large friendly lett…
the ICANN RSSAC01 document has been approved. it is written DRAFT 
because it is pending our own document so they will update it to change 
the reference to our RFC number. This sync process has been carefully 
designed for this purpose.

Marc.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Mar 2015 12:56:10 -0400

On Mar 11, 2015, at 12:55 PM, Marc Blanchet <[email-masked]> wrote:
> the ICANN RSSAC01 document has been approved. it is written DRAFT because it is pending our own document so they will update it to change the reference to our RFC number. This sync process has been carefully designed for this purpose.

Ah, excellent.   Thanks for the quick answer--now I can finish my ballot... :)