Skip to content

Fix BIND and dig to support large DNS messages over DoH, disable XFRs over DoH

Artem Boldariev requested to merge artem/dig-large-doh-responses-support into main

This merge request fixes support for large DNS messages via DoH both in BIND and diq. Now, when BIND serves as a resolver and dig requests a large DNS response, it will be handled correctly (e.g. dig +https A cmts1-dhcp.longlines.com). This is done by:

  1. making BIND treating HTTP as a stream protocol (previously it was treating it like UDP).
  2. fixing various bugs in dig revealed when receiving such responses.

Last but not least: this merge request explicitly disables zone transfers over DoH.

Making BIND think of HTTP as a stream protocol tricked it into allowing zone transfers over DoH. There was an error which could cause BIND to hang on shutdown because of the transfers, but it was fixed.

However, XFRs over DoH are not possible to do reliably because, according to RFC8484, a request and a response should contain no more than one DNS message in wire format (see section 6 of the RFC for the definition of application/dns-message media type).

The data payload for the "application/dns-message" media type is a single message of the DNS on-the-wire format defined in Section 4.2.1 of [RFC1035], which in turn refers to the full wire format defined in Section 4.1 of that RFC.

Although [RFC1035] says "Messages carried by UDP are restricted to 512 bytes", that was later updated by [RFC6891]. This media type restricts the maximum size of the DNS message to 65535 bytes.

This rules out zone transfers in generic case because they usually need more than one DNS message. Making them work would require standardising how multiple DNS messages can be carried in a DNS response over DoH, and for now, this is not standardised. Furthermore, I think that making zone transfers work over DoH would require standardising a media type that can carry multiple media messages (e.g. application/dns-multi-message which carries messages in the same format other XFR-enabled transports use). For now, there is no standard way to do so, so the best thing which we can do is respond to XFRs with "not implemented" (if only for security reasons). We have DoT to handle zone transfers securely (XoT), after all.

Edited by Artem Boldariev

Merge request reports