Might I suggest the following single additional sentence to section 4?
Where it says: "The DNS server must ensure that the DNS response size does not
exceed the Path MTU”
you may want to say:
"The DNS server must ensure that the DNS response size does not exceed the Path
MTU, i.e.: Each DTLS record MUST fit within a single datagram, as required by
[RFC6347].”
(explicitly reference RFC6347 as the source of this constraint on response
sizes)
thanks,
Geoff
> On 6 Jul 2016, at 11:54 PM, Prashanth Patil (praspati) <[email protected]>
> wrote:
>
> 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
