[Dnsmasq-discuss] Cannot set edns-packet-max < 4096 with DNSSEC enabled

Simon Kelley simon at thekelleys.org.uk
Mon Dec 15 17:44:15 GMT 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I confess I can't come up with a sensible rationalisation for this,
but I think it has something to to with the immediately preceding
commit in dnsmasq, which adds, this code.

+	  if (header->hb3 & HB3_TC)
+	    {
+	      /* Truncated answer can't be validated.
+		 The client will retry over TCP, but if this is an answer to a
+		 DNSSEC-generated query, we have a problem. Should really re-send
+		 over TCP. No-one with any sense will make a DNSKEY or DS RRset
+		 exceed 4096, so this may not be a real problem. Just log
+		 for now. */
+	      if (forward->flags & (FREC_DNSKEY_QUERY | FREC_DS_QUERY))
+		my_syslog(LOG_ERR, _("Reply to DNSSEC query truncated - validation
fails."));
+	      status = STAT_INSECURE;
+	    }
+	  else if (forward->flags & FREC_DNSKEY_QUERY)

Which details a big limitation: if a query arrives by UDP, dnsmasq
can't use TCP for any of the DNSKEY etc queries needed to validate it.
Hence the desire to force the packet size to 4096.

That code was later removed and the limitation removed, so the limit
is not required. I'll push a fix.

Cheers,

Simon.


On 25/11/14 11:01, Anders Kaseorg wrote:
> dnsmasq refuses to honor an --edns-packet-max option less than 
> EDNS_PKTSZ == 4096:
> 
> #ifdef HAVE_DNSSEC /* Enforce min packet big enough for DNSSEC */ 
> if (option_bool(OPT_DNSSEC_VALID) && daemon->edns_pktsz <
> EDNS_PKTSZ) daemon->edns_pktsz = EDNS_PKTSZ; #endif
> 
> Since 4096 is already the default value if --edns-packet-max is
> not specified, and no standard requires a minimum of 4096, I think
> this check should be deleted so that a user can force dnsmasq to
> advertise a lower UDP payload size if they know that TCP fallback
> is working better than UDP fragments.
> 
> (The context is that I’m trying to debug a problem with Comcast’s
> IPv6 DNS servers, which seem unable to send me large UDP packets:
> 
> $ dig +short +bufsize=4096 +dnssec @2001:558:feed::1 org -t dnskey 
> ;; connection timed out; no servers could be reached $ dig +short
> +bufsize=1500 +dnssec @2001:558:feed::1 org -t dnskey ;; Truncated,
> retrying in TCP mode. 256 3 7
> AwEAAXQRcjCcYDIZTLZZq46iF8oUX+c15GVdbszCa2RrrPz7yWEWAhu1 […] 257 3
> 7 AwEAAZTjbIO5kIpxWUtyXc8avsKyHIIZ+LjC2Dv8naO+Tz6X2fqzDC1b […] 257
> 3 7 AwEAAYpYfj3aaRzzkxWQqMdl7YExY81NdYSv+qayuZDodnZ9IMh0bwMc […] 
> 256 3 7 AwEAAal0CL9S++dL7Yg1BcHGOv0m3faUwZW9FuBW7ZsJTUnvFtUws17E
> […] DNSKEY 7 1 900 20141208155603 20141117145603 9795 org.
> ScWxHC+pzp[…] DNSKEY 7 1 900 20141208155603 20141117145603 21366
> org. AlSsJz93j[…] DNSKEY 7 1 900 20141208155603 20141117145603
> 60764 org. RySS8Ft6P[…]
> 
> The IPv4 DNS servers work better, but that doesn’t help dnsmasq
> because it only sends DNSSEC queries back to the same server that
> gave it the reply, which in my case is usually an IPv6 server.)
> 
> Anders
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUjx3vAAoJEBXN2mrhkTWizn4P/1ZaoGEbgWRPDaepSDiUPd/+
Z3tTeq/3+OOlXYVMe2TWqobCAT4oKGg+BlVaAy33kPK643oAix4K++lAG77YOI4G
snohs2K2hat5Za6ErM350JSeJkS8cQNVoF+z9jVWGm6S0vx1hKonJ02Qt8ocoUnH
k1CA4Z35IpYW/4kGn8+eV5Lb9v5Jl0NOseOh2YWHKmeq+9jh/E/tdj43I6bV3jfh
eN9QZGsl7xapEE7ShUuqZb3iX3FKfINtOUR/aPgkSdgQ8R16DmcoSdysoeKF695X
gmb81lvC42fWeAoPDqt9P3w25xyAf5crMD13n/ZPeqiiIn92OD2pFp/BSVdlzhgX
9NXCrXJWnOri4fgt8859hH0X4RI58hE1S4BDlc8+Rdbs2IEzqiiP9CfB44JJSwVn
j2a2uY82yMmoi/ftK6Ovd3ebRdDhVU5I08VkWWuPd3bXJ1QUWZvTtlsQArdRUOaC
Xcfa4hi7ju3pTnstfgyJQF2o4wptswcrpNkgRbxb+83RkfZIhgsqGdKd2FdkSkDd
Sjh0/EEv2NoR9/ytc3evpfnWWnSEf7ZW3KdTHsyexqpZ92KhbHncbrlhMNMvhBbd
Afw24iqlYkvcnTWTATCOmuuwvn2xSSxgx4gJhgX2fOdvjbqJWfk7e6PfjOaTOkje
CxRJaaCB5SI+TtoctSQ8
=IAWV
-----END PGP SIGNATURE-----



More information about the Dnsmasq-discuss mailing list