Re: Bind, dnssec, udp fragmentation woes.
In message 1254502519.14277.16.ca...@dv6d4k1-u, Nicholas Wheeler writes: On Fri, 2009-10-02 at 13:22 +1000, Mark Andrews wrote: You really want to work out what is being blocked, EDNS?, responses bigger that 512 bytes? DNSSEC? fragmented responses? With a clean path all of these should succeed but only the last one won't have tc set. This does a plain DNS query, a EDNS query that limits the response to 512 bytes, a DNSSEC query that limits the response to 512 bytes, a DNSSEC query that limits the response to something that would not normally be fragmented but exceeds 512 bytes, a DNSSEC query that will normally be fragmented. =20 % dig soa se @192.36.133.107 +norec +ignore=20 % dig soa se @192.36.133.107 +norec +ignore +bufsize=3D512 The above two work, the below four do not work (connection timed out; no servers could be reached).=20 (note: I replaced se with my domain.tld, and the @ with my server). % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=3D1200 % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=3D512 +dnssec % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=3D1200 +dnssec % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=3D4096 +dnssec =20 Mark Thanks for the help, but I don't know what this implies, other than nothing dnssec-related with udp works ;) It means you have a device in the path that doesn't like UDP answer bigger that 512 bytes *and* also doesn't like having DO set. ; DiG 9.3.6-P1 dnskey se @192.36.133.107 +norec +ignore +bufsize=512 +dnssec ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 52624 ;; flags: qr aa tc ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;se.IN DNSKEY ;; Query time: 334 msec ;; SERVER: 192.36.133.107#53(192.36.133.107) ;; WHEN: Tue Oct 6 09:16:58 2009 ;; MSG SIZE rcvd: 31 Now what you need to do is use a packet sniffer to see which devices are blocking the queries/responses (there may be more than one). You may also want to talk to the manufactures first. They should be able to tell you how to configure your boxes to work correctly to support DNSSEC. As things are curently configured you won't get DNSSEC working. You may need to upgrade firmware or even replace some boxes. The IP330 was introduced in 1999 so it may not have firmware that handles DNSSEC properly. Mark Thanks, --=20 Nicholas Wheeler Systems Administrator Development Infostructure --=-4uanAoS33Xc7mxoOFN+w Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkrGMHQACgkQ8xWIEdi0CHEavwCdGACm3VOyfctcd/IfmiW2upIK Q2YAnAhSkPdnAgvPqzJg6Nzod4EKNuXc =//Z9 -END PGP SIGNATURE- --=-4uanAoS33Xc7mxoOFN+w-- --===2355657698356755570== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --===2355657698356755570==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind, dnssec, udp fragmentation woes.
On Fri, 2009-10-02 at 13:22 +1000, Mark Andrews wrote: You really want to work out what is being blocked, EDNS?, responses bigger that 512 bytes? DNSSEC? fragmented responses? With a clean path all of these should succeed but only the last one won't have tc set. This does a plain DNS query, a EDNS query that limits the response to 512 bytes, a DNSSEC query that limits the response to 512 bytes, a DNSSEC query that limits the response to something that would not normally be fragmented but exceeds 512 bytes, a DNSSEC query that will normally be fragmented. % dig soa se @192.36.133.107 +norec +ignore % dig soa se @192.36.133.107 +norec +ignore +bufsize=512 The above two work, the below four do not work (connection timed out; no servers could be reached). (note: I replaced se with my domain.tld, and the @ with my server). % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=1200 % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=512 +dnssec % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=1200 +dnssec % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=4096 +dnssec Mark Thanks for the help, but I don't know what this implies, other than nothing dnssec-related with udp works ;) Thanks, -- Nicholas Wheeler Systems Administrator Development Infostructure signature.asc Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind, dnssec, udp fragmentation woes.
Hello all, For the last couple days I've been trying to figure out how to get dnssec implemented within my environment. A simplified description of my network is as follows: cloud - Nokia IP330(Check Point) - BigIP F5 - debian - named. My problem seems to be that when asking for dnssec-related information over udp, bind generates fragmented UDP packets that are then being blocked somewhere-along-the-way. I am not currently able to determine at what point it's being blocked, however. Here's what I can do: (within named's network): dig @named +dnssec +notcp DNSKEY domain.tld dig @named +dnssec +tcp DNSKEY domain.tld (outside of named's network): dig @named +dnssec +tcp DNSKEY domain.tld dig @named +notcp A domain.tld Here's what I can't do: (outside of named's network): dig @named +notcp +dnssec A domain.tld dig @named +notcp +dnssec DNSKEY domain.tld This is making it so my TLD can't get the DNSKEY via UDP, and therefore fails. I've tried setting various options in bind (edns-udp-size 512;, max-udp-size 512;), to no avail. As far as I can see from tcpdump, bind gets the request, generates some fragmented udp packets, which then enter TheVoid. Does anyone have any experience in getting bind to work with dnssec through potentially faulty firewalls and/or *NOT* fragment the UDP packets? It's possible that the firewall does both: denies fragmented udp packets, and denies udp packets which are not 512 bytes. Any help at all would be greatly appreciatedsuch as category logging statements that might be of relevance, tools to diagnose udp fragmentation problems, documentation of linux kernel parameters that might affect bind's generation of UDP packets (fragmentation?), etc. Thank you very much for your time, -- Nicholas Wheeler Systems Administrator Development Infostructure signature.asc Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind, dnssec, udp fragmentation woes.
You really want to work out what is being blocked, EDNS?, responses bigger that 512 bytes? DNSSEC? fragmented responses? With a clean path all of these should succeed but only the last one won't have tc set. This does a plain DNS query, a EDNS query that limits the response to 512 bytes, a DNSSEC query that limits the response to 512 bytes, a DNSSEC query that limits the response to something that would not normally be fragmented but exceeds 512 bytes, a DNSSEC query that will normally be fragmented. % dig soa se @192.36.133.107 +norec +ignore % dig soa se @192.36.133.107 +norec +ignore +bufsize=512 % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=1200 % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=512 +dnssec % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=1200 +dnssec % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=4096 +dnssec Named does the following by default. Ensure you have a up to date version of namesd dig dnskey se @192.36.133.107 +norec +ignore +bufsize=4096 +dnssec dig dnskey se @192.36.133.107 +norec +ignore +bufsize=512 +dnssec dig dnskey se @192.36.133.107 +norec +ignore Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
