Bind, dnssec, udp fragmentation woes.
Nicholas Wheeler
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 appreciated....such 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
Mark Andrews
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
Nicholas Wheeler
> 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,
Mark Andrews
In message <1254502519.14277.16.camel@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.
> > % 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
>
> (note: I replaced se with my domain.tld, and the @ with my server).
>
>
> > % 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-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> --===============2355657698356755570==--