Hi Geoff, We¹ve submitted a revision that should address the concern you¹ve rightly pointed out below.
-Prashanth On 5/25/16, 9:24 AM, "dns-privacy on behalf of Geoff Huston" <[email protected] on behalf of [email protected]> wrote: >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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
