named validating @0x...: ... SOA: no valid signature found

Mark Andrews marka at isc.org
Fri Jul 20 13:42:15 UTC 2012


In message <50095065.3050802 at interlinx.bc.ca>, "Brian J. Murrell" writes:
> 
> On 12-05-15 09:01 AM, Phil Mayers wrote:
> >=20
> 
> Sorry about the way delayed response.  There seems to be some confusion
> about which list/group gmane is following.
> =20
> > Isn't it more likely it's a local problem?
> 
> Indeed.  But what, is the question (and I do have the answer, now --
> see below).
> 
> > Which version of bind are you running?
> 
> I was running 9.8.3 and now 9.9.1-P1
> 
> > Does *any* zone validate
> 
> Yes.
> 
> > e.g. try:
> >=20
> > dig +dnssec @localhost www.ic.ac.uk
> 
> # dig +dnssec @localhost www.ic.ac.uk
> 
> ; <<>> DiG 9.9.1-P1 <<>> +dnssec @localhost www.ic.ac.uk
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 725
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 13
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;www.ic.ac.uk.                  IN      A
> 
> ;; ANSWER SECTION:
> www.ic.ac.uk.           3600    IN      A       155.198.140.14
> www.ic.ac.uk.           3600    IN      RRSIG   A 5 4 3600 20120812165527=
>  20120713164639 4743 ic.ac.uk. UZDw0aM0xPFXAmb5/PReP8hSWR/eNmMA479JFoZyHm=
> xRrepTaJWLya+R 1F2Y2LI/T12QlFkw09KBsgZo+hGr2MWfPyMAjNttzDLCqGM7dDNBUnuz H=
> 4G7DUnTvpnIV3VcLHqIh2z+j5ZmBb4+O4MIbNbBh8reVIacM8jgGNPH Evs=3D
> 
> ;; AUTHORITY SECTION:
> ic.ac.uk.               86400   IN      NS      ns1.ic.ac.uk.
> ic.ac.uk.               86400   IN      NS      authdns1.csx.cam.ac.uk.
> ic.ac.uk.               86400   IN      NS      ns2.ic.ac.uk.
> ic.ac.uk.               86400   IN      NS      ns0.ic.ac.uk.
> ic.ac.uk.               86400   IN      RRSIG   NS 5 3 86400 201208062130=
> 24 20120707210235 4743 ic.ac.uk. AYa7xE/1ZDMvt0c1wGY/+eu4vgbJm4EV+i+1YYZh=
> tLu44bdnHndfptNZ ECxeOI8JVeaKUq1zPspK9UnTCLFDkfCq9cIVFjZhpHQSPHtd3Vss40Vl=
>  gKrOG6qm4RfmPbLaUDKxu/LsR/W+iRbbiwI2fsso34BTUJeKPZGwqHPG j9k=3D
> 
> ;; ADDITIONAL SECTION:
> ns0.ic.ac.uk.           86400   IN      A       155.198.142.80
> ns0.ic.ac.uk.           86400   IN      AAAA    2001:630:12:600:1::80
> ns1.ic.ac.uk.           86400   IN      A       155.198.142.81
> ns1.ic.ac.uk.           86400   IN      AAAA    2001:630:12:600:1::81
> ns2.ic.ac.uk.           86400   IN      A       155.198.142.82
> authdns1.csx.cam.ac.uk. 86400   IN      A       131.111.12.37
> authdns1.csx.cam.ac.uk. 86400   IN      AAAA    2001:630:212:12::d:a1
> ns0.ic.ac.uk.           86400   IN      RRSIG   A 5 4 86400 2012080716470=
> 6 20120708162343 4743 ic.ac.uk. SDz7qZbq+O/SMopAP4L1W9QeeuJu6+vBW25h4WIoD=
> mFgXb+OPx3/M/6H 6pBFUpO2XoBfurRHly0r2yy7C4x3X7vth8nT9Xo16ZL9nauYwbUIM3f3 =
> zDECyEzrkPf8EDcwRYycOJfcKcAlxG0FiPBav+WJW8PNMR43YAsr6w5D ZLU=3D
> ns0.ic.ac.uk.           300     IN      RRSIG   AAAA 5 4 300 201208091427=
> 48 20120710132748 4743 ic.ac.uk. U+LTVkUNoTWXNTabEd/rt15qze4iLWhDFyw+inaY=
> gToGxYA5y3JS+fnx qfe2+GUFSLOz/Xo6czEe7728vCLgXzLQckAyS3g56NUfHKyXO1WWa6lQ=
>  k1r9UoNOSj5vTu0YLQN1FgP4aSFjowZzeQtbX//aDXZEVHKjNz4UFwBA zPs=3D
> ns1.ic.ac.uk.           86400   IN      RRSIG   A 5 4 86400 2012081601565=
> 7 20120717011404 4743 ic.ac.uk. dFRwdOkf670aLyyLtnLAYwo18XQGIFgT8YWQukrsj=
> 514pINSR5WUkcpd ReUOGLy9+RDEfpWwDsvdp1DLrxbUzElTF5Qkg/1d76qqB6WxmnQq6lqz =
> r5zKgfh9GNZHKrAOzvLcxlUFhd2xm1NXjktjIhb6CLH+qrJRR9h9+Zxy MlQ=3D
> ns1.ic.ac.uk.           300     IN      RRSIG   AAAA 5 4 300 201208091427=
> 48 20120710132748 4743 ic.ac.uk. OBSX8EyrqDcE6QzArCOaecx3Rf5fuBqfMctc/6M+=
> 3SnCHqQ9Dzp0YZly 2f6OJXu2JCrR4lGEUfgnA8rXDCKLgkzVIWFZi4y0GVuY2VHXhBptT9ri=
>  P0xRDqytbK9FAmIQMjn0gVuRBA6FhHhalh59FrcimXT/DyEj3TjsW2iD IsQ=3D
> ns2.ic.ac.uk.           86400   IN      RRSIG   A 5 4 86400 2012080406501=
> 1 20120705063843 4743 ic.ac.uk. IQ9KZAqCZLRpDwSpFpwor5ru7ltRfgBkFITKVs5IC=
> z0fGrMQ9uWeWVY2 CLNVmPeXtMseId7Y67+CM4q2Zu+zfBtSiLlDbbqD13FnSdmjqLCHF4PG =
> 7UVW1Z9uqjSHndKuuXeihNUSogyDZyoqf1b4SRcmRwOjgsM7HX0gWy87 jBs=3D
> 
> ;; Query time: 451 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Jul 20 07:24:59 2012
> ;; MSG SIZE  rcvd: 1466
> =20
> > ...and you should see:
> >=20
> > ; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18199
> > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 1=
> 1
> >=20
> > Note the "ad" flag - "authenticated data".
> 
> Yup, I did see that.
> 
> The problem here seems to be fragmented UDP.  I only ever receive the
> first fragment.  Since I am tcpdumping on the external interface of my
> router, I know it's not my router dropping it (which does have an
> iptables policy installed, but tcpdump happens before iptables AFAIU;
> that is you see *everything* with tcpdump, even on an interface where
> iptables is set to drop traffic).  I can only assume it's my ISP or
> something upstream.

They are most probably permitting the responses based on the UDP
ports but as the fragments don't have the UDP header they are dropped.

"pass udp from any to any frag" or similar is needed.

All ICMP fragments have ICMP in the protocol field of the the IP header
so if the firewall permits all ICMP they just get through.


> I am able to receive fragmented ICMP however.  For example:
> 
> $ ping -M want -s 3000 74.125.226.17
> PING 74.125.226.17 (74.125.226.17) 3000(3028) bytes of data.
> 3008 bytes from 74.125.226.17: icmp_req=3D1 ttl=3D58 time=3D29.1 ms
> 3008 bytes from 74.125.226.17: icmp_req=3D2 ttl=3D58 time=3D28.2 ms
> 3008 bytes from 74.125.226.17: icmp_req=3D3 ttl=3D58 time=3D28.6 ms
> 3008 bytes from 74.125.226.17: icmp_req=3D4 ttl=3D58 time=3D29.0 ms
> 3008 bytes from 74.125.226.17: icmp_req=3D5 ttl=3D58 time=3D29.9 ms
> 3008 bytes from 74.125.226.17: icmp_req=3D6 ttl=3D58 time=3D28.8 ms
> 3008 bytes from 74.125.226.17: icmp_req=3D7 ttl=3D58 time=3D28.5 ms
> 
> works just fine, and using the same tcpdumping technique I used to
> identify the UDP fragmentation receiving problem, I can see the
> multiple IP fragments both being sent and being received.
> 
> I suppose one hack-around would be to tell BIND to try to use
> TCP if a UDP query fails.
> 
> Other than that, any other ideas?

	server 74.125.226.17 {
		edns-udp-size 1400;
	};
 
> FWIW, I'm not yet convinced that it is my ISP and am still
> open to the idea that the problem is local.  It just doesn't
> appear to me that way in any of the testing that I have been
> able to do so far.
> 
> Cheers,
> b.
> 
> 
> --------------enigB13BF6E5B6A7B37401E91153
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: OpenPGP digital signature
> Content-Disposition: attachment; filename="signature.asc"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAlAJUGYACgkQl3EQlGLyuXAhQQCgt9HbRWPYD9QNkzgjHCweSyrc
> mdQAnRO1J4f+hTv08p7Gts/NGBWBo3wp
> =xH02
> -----END PGP SIGNATURE-----
> 
> --------------enigB13BF6E5B6A7B37401E91153--
> 
> 
> --===============7167988486076323267==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> --===============7167988486076323267==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



More information about the bind-users mailing list