BIND 9.11 no longer respects edns-udp-size?

Stéphane Bortzmeyer bortzmeyer at nic.fr
Mon Mar 11 09:14:57 UTC 2019


This machine has 'edns-udp-size: 1432' and, indeed, in the reply, it
displays this buffer size. But it does not respect that limit. Here,
with a big DNSKEY RRset, BIND should have truncated the answer and set
the TC bit but it didn't:

% dig @194.0.9.1 DNSKEY ma

; <<>> DiG 9.10.3-P4-Debian <<>> @194.0.9.1 DNSKEY ma
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54499
;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1432
;; QUESTION SECTION:
;ma.			IN DNSKEY

;; ANSWER SECTION:
ma.			1296000	IN DNSKEY 256 3 8 (
				AwEAAcKOK/IPpC+iUOHmrMg76aV+hAimErdlpiCpTGlu
				c1+ZCXCLYEpZwaME9vUl5eMDPuEKxa/PkWMsXa89b+Ow
				YveMSlESiHv/Jh7lu13Ar+9Ba3vQlTmt/JMBJ0/hR+jD
				UXZNLuSjOdcDRfgafQt+pufpClocDCZPdvyP8u466xIr
				) ; ZSK; alg = RSASHA256; key id = 25503
ma.			1296000	IN DNSKEY 256 3 8 (
				AwEAAagLY1Xa6PqbPvsC5zHybhLFaJtnA/6/i+3wnLyh
				3uvWzCOP56VXkn44aYDII+4E/ZrsC7GR4u7/P71PGejD
				HcYRvHdRcreIItU8Xtql+hz2BgEn/IeG/Gs67EEEXbE2
				t84pfyRzrcGQAz6nwwbzld1Ld+fQeS0ZT8w4XfMDBpa7
				) ; ZSK; alg = RSASHA256; key id = 51900
ma.			1296000	IN DNSKEY 257 3 8 (
				AwEAAaa+pkZNOrS5ZBslnyPGF5BwSFaAAUp48zevzufu
				qRKH8bhWGNCV1t7IjX9a7VlxDGoSZk3evYQI6d7h4jzZ
				8y0RjVc2jxZMKQeKHTHLVbUcTTqEp2jRFXSCRjT5vkuD
				gPfVbajQZOpv+IZxroDdX6UpppEcB7l2qn6QO9RkVuZ9
				Oy4CHhVre2vxL6TTcFGhP3ah/yaDYrmojbspdiCzW4nr
				z1HClgy/VmNWQYWwx0ZgYIZiCbsS2gZTZYy8AX+40Y5Q
				ZKGTPfF818g6OkEO9OJaZr/gKo+jqKYAIqkoHbsVlmII
				jCcmt4rodAzWy59mrlLGiAZIlb93OAmo82SxmNU=
				) ; KSK; alg = RSASHA256; key id = 15319
ma.			1296000	IN DNSKEY 257 3 8 (
				AwEAAa2j7taBE5OkjqCWbfZ4k+A/lBedIt94dVhEfNpU
				nskerqW5c+WL5thP/P3VdcHsPqdUv8fIqeGmVI1BwoUt
				MqZmQiKkYntqagX1JpYXwgZmEyybfGUHls81dPIW74bd
				aB5K4xcpfdEhnWxN3J9WGaDTRseCHWDKnMNhtqYi/4Sv
				aXNH0eB1/8MZ/IH0ukPbwRSn8V8R6Qmn6HNjUpMtGh3e
				7OROdDvMp/aTaKPUJ+Dgt74zlWCNwv/VmiEpC4AfHz5p
				A23NR46qlIUED/aOuvCp3gZAp7R9uIqTMH0rRz4mB5ru
				KJB/Xg5xLyqwOKx6cMHRSoA/nQQ4AKkZa4tWPhc=
				) ; KSK; alg = RSASHA256; key id = 33982
ma.			1296000	IN RRSIG DNSKEY 8 1 1296000 (
				20190401105301 20190302095632 15319 ma.
				WD09LaVuAnrTMl8aZ4qVwiMz0r1qm98a68+vPdfHLsY4
				W2nAriwpSZ+asGiWhrq4P4S+PEOStIgTycsnoKNyR8cX
				VwLzXM7w7J9wGaDmvg0j4l0617zG18SKKD4sQoUoxCGV
				zBE2j7HgAKwQVLKNOnN1EKSciBZS3o361t80TsG5Iid/
				dNu2cYLIPTVblck/mA2CZaTzVz01zbUn5bGOx8GdEZvE
				ld+1ej/jacaGCq80KXwEMxujPmp3tmi5kRpGgv4I+N82
				WS4kdCMuDO05hwwqg52h2QfOkkPDR7g2G0D/6XokYAkg
				5pvoj94N5n5zBR2L4BZVmxVZ5DcoE9+q7Q== )
ma.			1296000	IN RRSIG DNSKEY 8 1 1296000 (
				20190401105301 20190302095632 33982 ma.
				ItE1M13I/Nq9iY1PusCghth9oUbo4+tigZadHvZxjQRY
				KNMOtCsOJg0pIdUXbBlPqpu2AG6vCO4gX+cc5/ZdP0Og
				IKiAtCagA6/em/JBqR3QObWkJlcBtMoSpcs+rhUckd73
				Y7MJYCMP6I08K1uD9KN6NqThjUEZ/RY9VUyVHlvZ+meJ
				ajExJGDLJQ+dK4LPvmmS0JeXjIyOOmMt8411uzw+vTHc
				iY4wleGbAfrfYiOsQWmoXJAU0piy5feUHBg8NdadCM6X
				cG2k5pybSDEO2ghYK16P9cv0kvMchmTBvVJvDc4+YbWc
				ocd9aqjmLCdWeeMQNi3gjZztLTe8Db6umw== )
ma.			1296000	IN RRSIG DNSKEY 8 1 1296000 (
				20190401105301 20190302095632 51900 ma.
				JUSYyoMbvmquVaxG3lPKBtNfcRYbx79xMKSSSDh8jP4b
				TL10HIyYDpGBKujDX0E4TLIDcZWro97t4Mv8JTKL/n1H
				0uphGTIFsHzBnp2w4o2/3TuRpoMBcqiTJDUL5PZz4tiO
				YcQgwVgXcMjsoee6oFYTJ9O/B3z4eDlqaJQ6UQc= )

;; Query time: 4 msec
;; SERVER: 194.0.9.1#53(194.0.9.1)
;; WHEN: Fri Mar 08 15:39:42 CET 2019
;; MSG SIZE  rcvd: 1621

(If you repeat the test, be careful, this IP address is an anycasted
machine, and some instances run NSD, which does not have the bug.)

You can see here this BIND 9.11 server returning a fragmented answer (precisely
what we wanted to avoid with edns-udp-size):

16:38:37.506180 64:00:6a:78:28:40 > 00:1b:17:00:01:35, ethertype IPv4 (0x0800), length 73: 10.10.86.133.50572 > 194.0.9.1.53: 45007+ [1au] DNSKEY? ma. (31)
16:38:37.510516 00:1b:17:00:01:35 > 64:00:6a:78:28:40, ethertype IPv4 (0x0800), length 1514: 194.0.9.1.53 > 10.10.86.133.50572: 45007*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG, RRSIG[|domain]
16:38:37.510531 00:1b:17:00:01:35 > 64:00:6a:78:28:40, ethertype IPv4 (0x0800), length 183: 194.0.9.1 > 10.10.86.133: ip-proto-17

This is with BIND 9.11.5. NSD 4.1 does not have the bug and, on the
same zone, behaves correctly.


More information about the bind-users mailing list