Subject: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

From: tjw ietf <[email-masked]>
Date: Thu, 11 May 2017 06:57:51 -0400

There was a lot of consensus during our last meeting in Chicago that this
should move forward, so it's time that we do so.

This starts a Call for Adoption for:
draft-kristoff-dnsop-dns-tcp-requirements

The draft is available here:
https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: Midnight 25 May 2017

Thanks,
tim wicinski
DNSOP co-chair

---

From: 神明達哉 <[email-masked]>
Date: Thu, 11 May 2017 16:25:13 -0700

At Thu, 11 May 2017 06:57:51 -0400,

> DNSOP, and comments to the list, clearly stating your view.

I've read draft-kristoff-dnsop-dns-tcp-requirements-02.  I don't have
a strong opinion on whether dnsop should adopt it.  It's a
well-written, technically sound document, but I don't see something
substantially new in it.  I think RFC7766 already pretty clearly
states TCP is a MUST.  While some additional clarification provided by
this draft may also be useful, I'm personally not convinced that it's
sufficiently substantial that justifies the overhead and resource
consumption of the wg.  If this were a yes-or-no vote, I'd probably
vote for 'no'.

That said, I wouldn't be opposed to adopting it either, and if it's
adopted I'm willing to review subsequent versions.

> Please also indicate if you are willing to contribute text, review, etc.

Finally, a few comments on the current version:

- Section 2.2
   At least two new, widely anticipated developments were set to elevate
   the need for DNS over TCP transactions.  The first was dynamic
   updates defined in [RFC2136] and the second was the set of extensions
   collectively known as DNSSEC originally specified in [RFC2541].  The
   former suggested "requestors who require an accurate response code
   must use TCP", [...]

  I'm not sure if DDNS update bolsters the need for TCP.  In
  my understanding DDNS update exchanges are largely done over UDP
  today (e.g., ISC's nsupdate utility uses UDP by default):

       −v
           Use TCP even for small update requests. By default, nsupdate uses
           UDP to send update requests to the name server unless they are too
           large to fit in a UDP request in which case TCP will be used.

  And I don't see any new trend that changes this practice.

- Section 3

   o  Recursive servers (or forwarders) MUST service TCP queries so that
      they do not prevent large responses from a TCP-capable server from
      reaching its TCP-capable clients.

  The term "forwarder" can be ambiguous (see, e.g, RFC7766).  You
  might want to use a different term to be clearer.

--
JINMEI, Tatuya

---

From: Tony Finch <[email-masked]>
Date: Fri, 12 May 2017 11:35:26 +0100

>   today (e.g., ISC's nsupdate utility uses UDP by default):

Well, that depends on the transaction size :-) My servers fairly
frequently handle updates containing hundreds or records.

And `nsupdate` basically assumes that TCP is available - it doesn't give
the caller a way to find out what the server's maximum update size is.
(Similarly, my `nsupdate` wrapper `nsdiff` also assumes transactions can
be up to 64KB in size.)

So I think you'll be sad if you try to deploy an UPDATE server without TCP.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Southwest 5 to 7 veering west 4 or 5. Moderate or rough, becoming
moderate. Thundery showers. Good, occasionally poor.

---

From: John Kristoff <[email-masked]>
Date: Fri, 12 May 2017 06:45:52 -0500

On Thu, 11 May 2017 23:25:13 +0000
神明達哉 <[email-masked]> wrote:

> I've read draft-kristoff-dnsop-dns-tcp-requirements-02.

Thank you for taking the time to read, review, and comment on it!

> I think RFC7766 already pretty clearly states TCP is a MUST.

IETF RFC 7766 does very explicitly declare TCP is a MUST in the context
of DNS implementation.  It is also very explicit about not declaring
this to be so from an operational standpoint, although with a strong
warning about the consequences.  The last paragraph is Section 1 in that
document is the operative text.  It was that in addition to my own
operational and teaching experience I felt made this draft necessary. I
tried to make this case at the meeting in Chicago and elsewhere that
this is an important distinction that matters.  I can try to make this
case more compelling and convincing in the text.

>   I'm not sure if DDNS update bolsters the need for TCP.
[...]
>   And I don't see any new trend that changes this practice.

I see Tony has chimed on this so I'll simply add that the goal of
Section 2 was not necessarily intended to make or bolster the modern
argument for carrying DNS over TCP.  In fact, the purpose was to help
show how it is difficult to conclude one way or another whether carrying
DNS over TCP is an operational requirement or not. I can make this
objective more explicit at the beginning of that section.

>   might want to use a different term to be clearer.

Thanks again, I can try to make the wording and meaning more precise.

John

---

From: 神明達哉 <[email-masked]>
Date: Fri, 12 May 2017 08:25:40 -0700

At Fri, 12 May 2017 11:35:26 +0100,

> So I think you'll be sad if you try to deploy an UPDATE server without TCP.

I didn't make that comment to say we can deploy DDNS without TCP.
Citing the draft text again:

   At least two new, widely anticipated developments were set to elevate
   the need for DNS over TCP transactions.  The first was dynamic
   updates defined in [RFC2136] and the second was <not about DDNS>.  The
   former suggested "requestors who require an accurate response code
   must use TCP", while the later <not about DDNS>

This read to me that DDNS elevates the need for DNS over TCP as
RFC2136 suggests to use TCP for an accurate response code (because TCP
is reliable but UDP isn't) and requestors are actually following that
suggestion.

My comment was to point out that this is probably not the case in
today's common practice: I suspect many requestors don't too much
worry about this particular point and don't really use TCP at least
for that reason by overriding utilities' default.  Of course, in some
deployments the transaction size can be quite large and require TCP.
I don't know how common such a deployment is, but regardless of that,
I don't think the current draft text tries to say that.  If the actual
intent is that large DDNS transactions can require TCP, it should
simply say so (it doesn't have to cite the above suggestion of
RFC2136; it's even a confusing distraction in that sense).  And, to
that end, it's not even specific to DDNS.  Even a normal query
response can be too large to fit in a UDP message even with EDNS(0).

So, in summary, I basically try to say I don't see anything special
about DDNS here.

Anyway, this is a pretty minor technical detail.  I don't think it
affects the overall quality of the draft very much.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 12 May 2017 08:46:59 -0700

At Fri, 12 May 2017 06:45:52 -0500,

> case more compelling and convincing in the text.

I understand this draft tries to focus on an operational standpoint.
It states the intent pretty clearly.  It's just that I wasn't
convinced about the need to publish a separate RFC for that purpose
with all the overhead.  But, if a new version provides more compelling
arguments about the need it might change my mind.  And, in any case, I
wouldn't be surprised if others see stronger need for a separate
operational document - it can be quite subjective.  That's why I said
I wouldn't be (necessarily) opposed to
> objective more explicit at the beginning of that section.

Regarding this, see my followup response to Tony.

--
JINMEI, Tatuya

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 23 May 2017 13:22:34 +0100

> On 11 May 2017, at 11:57, tjw ietf <[email-masked]> wrote:

> This starts a Call for Adoption for: draft-kristoff-dnsop-dns-tcp-requirements
> 
> The draft is available here: https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/ <https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/>
Hi, 

I’ve reviewed this draft and as stated previously support adoption as a companion document to RFC7766. 

Minor comments:

Section 2.2: I think the argument around DNSSEC can be bolstered by the fact that recent root ZSK and upcoming KSK rollovers involved large responses. 

Section 2: I think it might be useful to include a section in section 2 describing the fact that the lack of, or very limited implementation of TCP also fed the perception that it was a security risk. 

Section 6.3  s/[RFC7766] is might be/[RFC7766] might be/

Should there be a section in Section 6 about RFC7858 (DNS-over-TLS)? And since it is stated as TCP related development should RFC2136 be there (even though it is discussed earlier)?

How about including a reference to https://datatracker.ietf.org/doc/draft-stenberg-httpbis-tcp/ <https://datatracker.ietf.org/doc/draft-stenberg-httpbis-tcp/> ?

Regards

Sara.

---

From: John Kristoff <[email-masked]>
Date: Thu, 25 May 2017 12:00:48 -0500

On Tue, 23 May 2017 12:22:34 +0000

> a companion document to RFC7766.

Thank you for your review.

> Section 2.2: I think the argument around DNSSEC can be bolstered by
> the fact that recent root ZSK and upcoming KSK rollovers involved
> large responses.

Thank you, we can note that in a future revision.

> Section 2: I think it might be useful to include a section in section
> 2 describing the fact that the lack of, or very limited
> implementation of TCP also fed the perception that it was a security
> risk.

The references

  Cheswick, W. and S. Bellovin book
  <https://cr.yp.to/djbdns/tcp.html#why>

in section 2.4 I think may largely sums up the general concern.
Maybe the section 2.4 is not correctly titled or incompletely detailed
to highlight your point.  Any specific text or additional references are
welcome of course.

> Section 6.3  s/[RFC7766] is might be/[RFC7766] might be/

Thank you.

> Should there be a section in Section 6 about RFC7858 (DNS-over-TLS)?

Yes, thanks for pointing that out.  That section is still work in
progress.

> And since it is stated as TCP related development should RFC2136 be
> there (even though it is discussed earlier)?

Probably should be there.  Need I worry about section 6's length at
all?  It could take up a significant portion of the document given the
way this section is going.  Note, this section was added based on some
earlier feedback that having this sort of list might be helpful.
> 
> How about including a reference to
> https://datatracker.ietf.org/doc/draft-stenberg-httpbis-tcp/ ?

Looks potentially worth including this sort of work in section 4.

Thanks again,

John

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 26 May 2017 13:23:10 +0100

> On 25 May 2017, at 18:00, John Kristoff <[email-masked]> wrote:
> 
> 

I sadly don’t have a copy of that book to hand so I can’t comment on the content there…. 

> to highlight your point.  Any specific text or additional references are

How about:

   “There are many in the DNS community who configure DNS over TCP services and expect DNS over TCP transactions
   to occur without interference. However there has also been a long held belief
   by some operators, particularly for security-related reasons,
   that DNS over TCP services should be purposely limited or not provided at all [CHES94], [DJBDNS].  
   A popular meme has also held the imagination of some that DNS over TCP is only ever used for zone
   transfers and is generally unnecessary otherwise, with filtering all
   DNS over TCP traffic even described as a best practice. 
   
   The position on restricting DNS over TCP had some justification given that historic implementations of DNS nameservers provided
   very little in the way of TCP connection management (for example see Section 6.1.2 of [RFC7766] 
   for more details). However modern standards and implementations are moving to align with the more
   sophisticated TCP management techniques employed by, for example, HTTP(S) servers and load balancers. 

> earlier feedback that having this sort of list might be helpful.

If it gets too long then perhaps I could be moved to an Appendix? I think it is very useful for reference but as you say it should not necessarily dominate the document. 

Sara.

---

From: tjw ietf <[email-masked]>
Date: Fri, 26 May 2017 19:50:51 -0400

All

The Call for Adoption ended last night, and there was consensus to adopt
this document much like their was in Chicago, We will hold those volunteers
to their promise to review, and we'll have the authors upload new versions
of the draft.

the chairs

On Thu, May 11, 2017 at 6:57 AM, tjw ietf <[email-masked]> wrote:

> The draft is available here: https://datatracker.
> ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>