> 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
