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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
