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
