Subject: [DNSOP] RFC 2671

From: [email-masked]
Date: Wed, 23 Dec 2009 18:37:07 +0000

There has been some discussion of late about DNS MTU sizing and EDNS0 "fall-back".
I've found another "culprit" in the program DNSMASQ - distributed with FedoraCore 10
and later versions of RedHat.

to wit:

       -P, --edns-packet-max=<size>
              Specify the largest EDNS.0 UDP packet which is supported  by  the  DNS  for-
              warder.  Defaults to 1280, which is the RFC2671-recommended maximum for eth-
              ernet.

Is there any interest in revisting this RFC or should we be happy with a functional limit
on EDNS0 message size being 1280 bytes?

--bill

---

From: [email-masked]
Date: Wed, 23 Dec 2009 18:58:53 +0000

On Wed, Dec 23, 2009 at 01:46:58PM -0500, Paul Wouters wrote:
> On Wed, 23 Dec 2009, [email-masked] wrote:
> 
> I could talk to the Fedora maintainer to see if we can change the default
> using a /etc/sysconfig/dnsmasq parameter.
> 
> Paul

	that might work ... for this particular instance but who else will read
	that text and make the same choice for their application?

--bill

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Dec 2009 13:46:58 -0500 (EST)

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Dec 2009 07:42:51 +0900

> on EDNS0 message size being 1280 bytes?

The RFC needs revision.

First of all, because the largest IPv4 header is 60B and UDP
header is 8B, the following statement:

> 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
>        reassembly buffer.

is wrong and DNS requires the IPv4 reassembly buffer 580B or larger,
which is beyond the requirement of 576B in RFC791.

But, we can reasonably expect reassembly buffer > 1400B, of course.

Then, it is reasonable to allow messages as large as 1280B over IPv4,
as long as don't fragment bit is *NOT* asserted.

Further, *IF* we can safely assume path MTU larger than 1348B,
don't fragment bit may be asserted. But, if we can assume path
MTU larger than 1348B, there is no point to perform path MTU
discovery to send a 1348B packet. That is, we don't have to
assert the don't fragment bit.

On the other hand, for IPv6, as the minimum MTU is only 1280B long,
even when there are no extension headers, DNS message size can be
only as large as 1280-40-8=1232B.

Worse, as extension headers are silently inserted for mobility and
other purposes and can be infinitely lengthy, the DNS message size
safely carried over IPv6 is 0B.

You can request IETF to limit the maximum length of extension headers
below certain limit (e.g. 208B to allow for 1024B messages), though
a request was formally rejected by IPv6 WG when I did so last time
with the exact example of the DNS message size requirement.

It should be a lot of fun, because the request imply to change
the IPv6 specification and all the implementations (at least
those following RFC3542).

Or, just stick to (port restricted) IPv4 and to ignore IPv6
saying "you have been warned".

						Masataka Ohta

---

From: Francis Dupont <[email-masked]>
Date: Wed, 23 Dec 2009 23:48:47 +0000

In your previous mail you wrote:

   I've found another "culprit" in the program DNSMASQ - distributed
   with FedoraCore 10 and later versions of RedHat.
   
=> I asked some days ago the author to change the defaut to 4096
and in his answer he wrote it will be fixed in the next release.

BTW as you can easily put the right value in command line / config
file I asked the same thing to OpenWrt for the default config but
it bumped because I was not in the list (I've noted to retry).

Thanks

[email-masked]

PS: there was another DNSSEC fix in dnsmasq, I'll ask if I can forward
the full answer to this list.