Howdy,
I note that section 4..4 calls out TCP transport and says this:
4.4. Behaviour with TCP TransportA 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-secretary@xxxxxxxx> 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
ietf@xxxxxxxx mailing lists by 2018-09-04. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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.
