You are using the wrong control.
Max-udp-size is what you want.  

-- 
Mark Andrews

> On 11 Mar 2019, at 20:14, Stéphane Bortzmeyer <bortzme...@nic.fr> wrote:
> 
> 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.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to