-- Mark Andrews
> On 9 May 2022, at 22:32, Veronique Lefebure <veronique.lefeb...@cern.ch> > wrote: > > Second thought on this topic: > > are the BIND EDNS messages rather related to > > gr/DNSKEY (alg 8, id 13987): No response was received until the UDP payload > size was decreased, indicating that the server might be attempting to send a > payload that exceeds the path maximum transmission unit (PMTU) size. > (139.91.191.3, 2001:648:2c30::191:3, UDP_-_EDNS0_4096_D_KN) > gr/DNSKEY (alg 8, id 45264): No response was received until the UDP payload > size was decreased, indicating that the server might be attempting to send a > payload that exceeds the path maximum transmission unit (PMTU) size. > (139.91.191.3, 2001:648:2c30::191:3, UDP_-_EDNS0_4096_D_KN) > > as indicated by https://dnsviz.net/d/physics.uoi.gr/dnssec/ ? > > I guess so. > > So with BIND 9.19 all queries using 139.91.191.3 will fail, but other NS will > answer successfully ? > > >> On 09/05/2022 13:19 Veronique Lefebure <veronique.lefeb...@cern.ch> wrote: >> >> >> Hello, >> >> Now we are investigating another case: >> >> On our internal DNS server we see : >> >> 08-May-2022 20:48:14.248 edns-disabled: info: success resolving >> 'grid31.physics.uoi.gr/A' (in '.'?) after reducing the advertised EDNS UDP >> packet size to 512 octets >> 08-May-2022 20:48:14.249 edns-disabled: info: success resolving >> 'grid31.physics.uoi.gr/AAAA' (in '.'?) after reducing the advertised EDNS >> UDP packet size to 512 octets >> >> and on our external cache DNS server we see: >> >> 03-May-2022 20:47:40.934 edns-disabled: info: success resolving >> 'grid31.physics.uoi.gr/AAAA' (in 'physics.uoi.gr'?) after disabling EDNS >> 03-May-2022 20:47:40.937 edns-disabled: info: success resolving >> 'grid31.physics.uoi.gr/A' (in 'physics.uoi.gr'?) after disabling EDNS >> >> Looking into our detailed logs, it seems to us that the root cause of the >> problem for this domain is that the DNS server used by physics.uoi.gr don't >> reply over ipv6, and that our DNS servers finally get an answer when they >> query the ipv4 NS. >> >> This seems also to be confirmed by >> https://dnsviz.net/d/physics.uoi.gr/dnssec/ (really great tool !). >> >> If the problem is simply ipv6, is it correct to say that the BIND messages >> above are misleading ? >> Or is there really a EDNS-related issue ? >> >> Thanks again, >> Veronique >> >> >>>> On 05/05/2022 03:01 Mark Andrews <ma...@isc.org> wrote: >>> >>> >>>> On 5 May 2022, at 00:17, Veronique Lefebure <veronique.lefeb...@cern.ch> >>>> wrote: >>>> >>>> Thanks Greg and Ondrej, >>>> >>>> Many thanks for the pointer to DNS Cookies in BIND 9 (isc.org) >>>> >>>> I have used https://ednscomp.isc.org/ednscomp/1ba42afa27 to check if they >>>> are compliant, but the answer is ambiguous: >>>> >>>> EDNS Compliance Tester >>>> Checking: 'sour.woinsta.com' as at 2022-05-04T13:45:39Z >>>> sour.woinsta.com.: NS lookup failed >>>> Codes >>>> • ok - test passed. >>> >>> Use the zone name ‘woinsta.com’. The site asks for the zone name not an >>> arbitrary zone name. >>> That said we make need to tweak the nameserver settings the tester is using >>> to get the initial >>> NS lookup to succeed with broken servers like this. >>> >>>> Anyway, from what you have seen you are suspecting that the problem is on >>>> the woinsta.com side and not on our side ? >>>> >>>> The following indeed indicates a problem related to cookies: >>>> >>>> dig @ns1.thednscloud.com. +nocookie sour.woinsta.com A +short >>>> 23.82.12.29 >>>> >>>> while >>>> >>>> dig @ns1.thednscloud.com. +cookie sour.woinsta.com A +short >>>> ; <<>> DiG 9.11.36 <<>> @ns1.thednscloud.com. +cookie sour.woinsta.com A >>>> +short >>>> ; (2 servers found) >>>> ;; global options: +cmd >>>> ;; connection timed out; no servers could be reached >>> >>> The servers will echo back a COOKIE option that has both the client and a >>> server cookie present. >>> >>> % dig sour.woinsta.com ns @23.82.12.27 +norec >>> +cookie=44fd7abd853763e60100000062731621e76cd1b746056de3 +qr >>> >>> ; <<>> DiG 9.17.22 <<>> sour.woinsta.com ns @23.82.12.27 +norec >>> +cookie=44fd7abd853763e60100000062731621e76cd1b746056de3 +qr >>> ;; global options: +cmd >>> ;; Sending: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2072 >>> ;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 1232 >>> ; COOKIE: 44fd7abd853763e60100000062731621e76cd1b746056de3 >>> ;; QUESTION SECTION: >>> ;sour.woinsta.com. IN NS >>> >>> ;; QUERY SIZE: 73 >>> >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2072 >>> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 1232 >>> ; COOKIE: 44fd7abd853763e60100000062731621e76cd1b746056de3 (good) >>> ;; QUESTION SECTION: >>> ;sour.woinsta.com. IN NS >>> >>> ;; AUTHORITY SECTION: >>> woinsta.com. 300 IN SOA ns1.emu-dns.com. admin.woinsta.com. >>> 2022020800 86400 10800 604800 300 >>> >>> ;; Query time: 236 msec >>> ;; SERVER: 23.82.12.27#53(23.82.12.27) (UDP) >>> ;; WHEN: Thu May 05 10:16:25 AEST 2022 >>> ;; MSG SIZE rcvd: 127 >>> >>> % >>> >>> I suspect a stupid firewall in front of it that thinks it knows what is a >>> valid COOKIE option is >>> but really it doesn’t. The firewall then did the stupid thing of dropping >>> the request. The correct >>> protocol response to an invalid EDNS option is FORMERR with an OPT record >>> present if you understand >>> EDNS. If you don’t understand EDNS the correct response to EDNS is FORMERR >>> *without* an OPT record >>> being present or just ignore the OPT record. >>> >>> Too many servers don’t know how to construct a valid FORMERR response. You >>> DO NOT just copy the >>> request, set rcode to FORMERR and QR to 1 and send the resulting message. >>> Why would you send what >>> you believe is garbage to the client? The DNS message has a well defined >>> header which identifies >>> the request / response. Construct a valid response header based on the >>> header in the request and >>> set the rcode to FORMERR. Zero out the response header, copy the ID and >>> OPCODE fields. Copy any >>> header bits that you know are supposed to be copied. Set the RCODE field >>> to FORMERR. If it was >>> a QUERY, and you understood the QUESTION section, you can copy that as well >>> updating the QUESTION >>> count. >>> >>> Basically there is a broken firewall and a broken DNS server here. Both >>> need to be fixed. >>> >>> Mark >>> >>>> I will try send-cookie no for that server to confirm it is the source of >>>> the issue. >>>> >>>> Cheers, >>>> Veronique >>>> >>>>> On 04/05/2022 14:34 Greg Choules <gregchoules+bindus...@googlemail.com> >>>>> wrote: >>>>> >>>>> >>>>> Hi Veronique. >>>>> Every DNS server should support EDNS by now. It has been around for a >>>>> very long time. Even if it doesn't support EDNS it should ignore it. >>>>> >>>>> I made some test queries and packet captures to 23.82.12.28. Whatever >>>>> this box is, please talk to the manufacturer about EDNS support. >>>>> Or.. it may be that some network infrastructure - firewalls are usually >>>>> the first place to look - is blocking this traffic. >>>>> >>>>> Whatever is happening at the authoritative end, it needs to be fixed. All >>>>> modern recursive servers will use EDNS. >>>>> >>>>> Cheers, Greg >>>> -- >>>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe >>>> from this list >>>> >>>> ISC funds the development of this software with paid support >>>> subscriptions. Contact us at https://www.isc.org/contact/ for more >>>> information. >>>> >>>> >>>> bind-users mailing list >>>> bind-users@lists.isc.org >>>> https://lists.isc.org/mailman/listinfo/bind-users >>> >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
