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