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 <iesg-secret...@ietf.org> 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 > i...@ietf.org mailing lists by 2018-09-04. Exceptionally, comments may be > sent to i...@ietf.org 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. > > > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
