Subject: Re: Last Call: <draft-ietf-dnsop-refuse-any-07.txt> (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

From: Ted Hardie <[email-masked]>
Date: Tue, 21 Aug 2018 09:48:20 -0700

Howdy,

I note that section 4.4 calls out TCP transport and says this:

4.4.  Behaviour with TCP Transport

   A DNS responder MAY behave differently when processing ANY queries
   received over different transport, e.g. by providing a conventional
   ANY response over TCP whilst using one of the other mechanisms
   specified in this document in the case where a query was received
   using UDP.

   Implementers SHOULD provide configuration options to allow operators
   to specify different behaviour over UDP and TCP.

Given that we now have multiple available transports for the DNS (TLS,
DTLS, HTTPS), it may be worth generalizing the heading and updating the
text to handle those cases.  I suspect that involves a bit more work than
just adding the transport names to the paragraph, unfortunately.  All of
the newer transports provide return routability, which means, as for TCP,
that ANY doesn't create DNS amplification for them.  But they also have
other characteristics (e.g. channel confidentiality and/or additional
caching layers) that may make for other decision points.  Some text on that
would be useful, at least in my opinion.

regards,

Ted Hardie

On Tue, Aug 21, 2018 at 8:59 AM, The IESG <[email-masked]> wrote:

>
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document: - 'Providing Minimal-Sized
> Responses to DNS Queries that have QTYPE=ANY'
>   <draft-ietf-dnsop-refuse-any-07.txt> as Proposed Standard
>
> 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 2018-09-04. 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 Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>    The operator of an authoritative DNS server might choose not to
>    respond to such queries for reasons of local policy, motivated by
>    security, performance or other reasons.
>
>    The DNS specification does not include specific guidance for the
>    behaviour of DNS servers or clients in this situation.  This document
>    aims to provide such guidance.
>
>    This document updates RFC 1034 and RFC 1035.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 21 Aug 2018 12:56:17 -0400

Ted,
Would it be acceptable to just do
s/TCP/Connection oriented Transport/

Olafur

-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Aug 2018 13:03:57 -0400 (EDT)

On Tue, 21 Aug 2018, Ólafur Guðmundsson wrote:

> Ted, Would it be acceptable to just do 

For RFC 7901 we used "source-IP-verified transport"

Paul

---

From: Ted Hardie <[email-masked]>
Date: Tue, 21 Aug 2018 10:08:32 -0700

> For RFC 7901 we used "source-IP-verified transport"
If this is the only characteristic that the working group believes will
cause variance in ANY responses, then reusing this terminology seems fine.
I suspect, however, that it is not  the only characteristic that will in
practice.  I can easily imagine cases where ANY returns full answers when
the transport is confidential and minimal ones when it is not.

I have absolutely no data to back this intuition, though, so I will
understand if the working group and authors disagree.

regards,

Ted Hardie

---

From: Bob Harold <[email-masked]>
Date: Tue, 21 Aug 2018 13:20:11 -0400

> understand if the working group and authors disagree.
As I see it, the data is 'public' in the sense that any other client could
also request "ANY" over a confidential transport and get the same info, so
I don't see why the server would care that the transport is confidential.
It only protects the privacy of the client.
Preventing amplification, or unnecessary traffic in general, is the basic
use case that I see.

-- 
Bob Harold

---

From: Tony Finch <[email-masked]>
Date: Tue, 21 Aug 2018 20:31:50 +0100

> For RFC 7901 we used "source-IP-verified transport"

I don't think that's a good idea, because it suggests oversised responses
over UDP with cookies. I wanted minimal-any in order to reduce both UDP
fragmentation and fallback to TCP for all UDP queries from legitimate
clients. (Spoofed queries are dealt with by RRL.)

I suggest:

4.4.  Behaviour over different DNS transports

   A DNS responder MAY behave differently when processing ANY queries
   received over different DNS transports or with different levels
   of client authentication, e.g. by providing a conventional
   ANY response over TCP whilst using one of the other mechanisms
   specified in this document in the case where a query was received
   using UDP.

   Implementers SHOULD provide configuration options to allow operators
   to specify different behaviour over different DNS transports or for
   authenticated clients.

(the TCP/UDP e.g. is just a non-normative example; more outre transports
and options are covered by the normative text)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Bailey: Northwest 5 or 6, backing west 5 to 7. Moderate or rough. Showers.
Good.