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

[Sara Dickinson]

> On 25 May 2017, at 18:00, John Kristoff  wrote:
> 
> 
>> 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

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

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

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. 

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

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. 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Kristoff]

On Tue, 23 May 2017 12:22:34 +
Sara Dickinson  wrote:

> I’ve reviewed this draft and as stated previously support adoption as
> 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
  

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Sara Dickinson]

> On 11 May 2017, at 11:57, tjw ietf <tjw.i...@gmail.com> 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. ___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

At Fri, 12 May 2017 06:45:52 -0500,
John Kristoff  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 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
>
> >   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.

Regarding this, see my followup response to Tony.

--
JINMEI, Tatuya

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

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

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

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 .  The
   former suggested "requestors who require an accurate response code
   must use TCP", while the later 

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Kristoff]

On Thu, 11 May 2017 23:25:13 +
神明達哉  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.

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

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

John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

At Thu, 11 May 2017 06:57:51 -0400,
tjw ietf <tjw.i...@gmail.com> wrote:

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[tjw ietf]

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop