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

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 6 Jul 2016 13:54:49 +0000

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-masked] on behalf of [email-masked]> 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-masked]
>https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Geoff Huston <[email-masked]>
Date: Fri, 8 Jul 2016 10:50:53 +1000

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-masked]> wrote:
> 
> Hi Geoff,