Subject: [DNSOP] avoiding fragmented DNS-over-UDP

From: Tony Finch <[email-masked]>
Date: Wed, 21 Mar 2018 16:10:15 +0000

In the intarea meeting, there was some discussion of
"IP fragmentation considered fragile"
https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile

That draft correctly calls out the DNS as particularly problematic wrt
fragmentation, so I think it might be worth writing a dnsop draft that
explains how to reduce the amount that the DNS causes fragmented packets
and relies on them working.

I think this draft should provide advice to implementers about how
their code should behave in its default configuration. I think a lot
of the advice should be basically writing down things that we (or some
of us) already know.

I don't know if we need different flavours of advice for stub -> recursive
and for recursive -> authoritative.

Here are some sketchy notes on what this might say...

* client side

    * implement PMTUD by probing with diferent EDNS buffer sizes

    * needs to be per-server

    * start with small buffer size and work upwards

    * probe sizes (not necessarily in this order)

        * 512
        * 1280 - tunnel headers
        * 1280
        * 1500 - tunnel headers
        * 1500
        * 4096

* server side

    * avoid putting too many records in a response

        * when the client has a small buffer size, try to avoid truncating

        * when the client has a large buffer size, still return a small
          sub-MTU response, e.g. with unilateral minimized responses,

    * does it make sense to provide partial glue instead of truncating,
      to avoid fallback to TCP?

    * does it make sense for a server to try to work out if the client is
      doing PMTUD, or is that too much complexity for too little benefit?

    * recommend minimal-any :-)

* security considerations

    * reflection / amplification ddos is bad, mmmkay?

    * risks of excess TC leading to overload

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire, Forties, Cromarty, Forth: Westerly or southwesterly, veering
northwesterly for a time, 5 to 7, decreasing 4 or 5 later. Slight or moderate
in Cromarty and Forth, otherwise moderate or rough. Occasional rain. Good,
occasionally poor.

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 21 Mar 2018 21:56:20 +0530

> and relies on them working.

Some topics in the same area:

(1) An alternative is to split responses at the application level into
into multiple UDP datagrams:
https://tools.ietf.org/html/draft-muks-dnsop-dns-message-fragments-00

(2) There is a tiny risk of spoofed fragments. Cookies should mitigate
some of this risk as the OPT RR would usually go in the last IP fragment
(this should be OK for up to 2 fragments). A mechanism to mitigate IP
fragment spoofing would be a stronger (than UDP) checksum:
https://tools.ietf.org/html/draft-muks-dnsop-dns-message-checksums-01

		Mukund

---

From: Tony Finch <[email-masked]>
Date: Wed, 21 Mar 2018 16:37:43 +0000

> Some topics in the same area:

Thanks for your thoughts :-)

WRT Bert's camel, the draft I have in mind is just implementation advice
within the existing protocol. Part of the idea is to reduce fragmentation
in the presence of old deployed software, e.g. new client uses a small
buffer to avoid provoking fragments from an old server; new server uses a
small response despite a large buffer from an old client.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Northerly or northeasterly 5 to 7, occasionally 4 later, becoming
variable 3 or 4 in northwest. Rough, occasionally moderate. Fair. Good.

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Mar 2018 12:39:57 +0000

> Here are some sketchy notes on what this might say...

Geoff Huston just told me I need to read Davey Song's very clever
"additional truncated response" and that he would roast my suggestions
if I didn't mention ATR :-)
https://tools.ietf.org/html/draft-song-atr-large-resp
http://iepg.org/2018-03-18-ietf101/geoff.pdf

Geoff is very keen on ATR. I think we should work on ATR, and as well as
that it would still be a good idea to work on both client-side mitigations
(for servers that don't have mitigations) and on server-side response size
reduction to avoid unnecessary ATR / TCP.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: South or southwest 5 to 7, occasionally gale 8 for a time. Slight
or moderate, becoming rough. Occasional rain. Good occasionally poor.

---

From: Davey Song <[email-masked]>
Date: Fri, 23 Mar 2018 13:47:50 +0800

Flattered to be mentioned. Specially thanks to Geoff and Joao for their
effort to demontrate ATR with measurement and facts. You did what I desired
but failed to do.

If you think ATR is worth of doing, I'm looking forward to more comments to
improve it towards a formal document.

-Davey
On 22 March 2018 at 20:39, Tony Finch <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: [email-masked]
Date: Tue, 27 Mar 2018 18:17:57 +0100

> On 21 Mar 2018, at 16:10, Tony Finch <[email-masked]> wrote:
> 
https://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-01 is worth a mention specifically in relation to PMTUD

John

---

From: Tony Finch <[email-masked]>
Date: Wed, 28 Mar 2018 11:52:02 +0100

[email-masked] wrote:
>
> https://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-01 is
> worth a mention specifically in relation to PMTUD

Thanks for the pointer!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Northeast Viking, North Utsire: Southeasterly 6 to gale 8. Moderate or rough.
Fair. Good.