Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-06.txt

[Geoff Huston <[e-mail]>]

Hi 

I have been reading this draft and comparing it to the DTLS RFC (RFC6347)

RFC6347 says:

4.1.1.  Transport Layer Mapping

   Each DTLS record MUST fit within a single datagram.  In order to
   avoid IP fragmentation, clients of the DTLS record layer SHOULD
   attempt to size records so that they fit within any PMTU estimates
   obtained from the record layer.




draft-ietf-dprive-dnsodtls-06.txt says:

   client and server MUST support the EDNS0 option defined in [RFC6891]
   so that the DNS client can indicate to the DNS server the maximum DNS
   response size it can handle without IP fragmentation.  If the DNS
   server's response exceeds the EDNS0 value, the DNS server sets the TC
   (truncated) bit.  On receiving a response with the TC bit set, the
   client establishes a DNS-over-TLS connection to the same server, and
   sends a new DNS request for the same resource record.

These are not precisely consistent. EDNS0 does not specify the maximum
unfragmented size, of course. It specifies the maximum size that the
querier is willing to reassemble. 

To quote from RFC6891

   The requestor's UDP payload size (encoded in the RR CLASS field) is the
   number of octets of the largest UDP payload that can be reassembled and
   delivered in the requestor's network stack.  Note that path MTU, with
   or without fragmentation, could be smaller than this.

So at this point I'm confused. If the intent is to prevent IP
fragmentation then the server must sit within the local PMTU estimate, or
truncate the response to indicate that it could not do so, which means
that the text in the draft needs revision to reflect this normative
(MUST) constraint imposed by RFC6347.

Or are these extenuating circumstances in DNS over DTLS that would allow a
fragmented response that sits within an offerred EDNS0 UDP Buffer size?
If so, then the draft should clearly document what these circumstances are
and why the MUST in RFC6347 is not being applied in this case.

thanks,

  Geoff