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

Fri Jul 20 12:34:45 UTC 2012

On 12-05-15 09:01 AM, Phil Mayers wrote:
> 

Sorry about the way delayed response.  There seems to be some confusion
about which list/group gmane is following.

> 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:
> 
> 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/eNmMA479JFoZyHmxRrepTaJWLya+R 1F2Y2LI/T12QlFkw09KBsgZo+hGr2MWfPyMAjNttzDLCqGM7dDNBUnuz H4G7DUnTvpnIV3VcLHqIh2z+j5ZmBb4+O4MIbNbBh8reVIacM8jgGNPH Evs=

;; 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 20120806213024 20120707210235 4743 ic.ac.uk. AYa7xE/1ZDMvt0c1wGY/+eu4vgbJm4EV+i+1YYZhtLu44bdnHndfptNZ ECxeOI8JVeaKUq1zPspK9UnTCLFDkfCq9cIVFjZhpHQSPHtd3Vss40Vl gKrOG6qm4RfmPbLaUDKxu/LsR/W+iRbbiwI2fsso34BTUJeKPZGwqHPG j9k=

;; 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 20120807164706 20120708162343 4743 ic.ac.uk. SDz7qZbq+O/SMopAP4L1W9QeeuJu6+vBW25h4WIoDmFgXb+OPx3/M/6H 6pBFUpO2XoBfurRHly0r2yy7C4x3X7vth8nT9Xo16ZL9nauYwbUIM3f3 zDECyEzrkPf8EDcwRYycOJfcKcAlxG0FiPBav+WJW8PNMR43YAsr6w5D ZLU=
ns0.ic.ac.uk.           300     IN      RRSIG   AAAA 5 4 300 20120809142748 20120710132748 4743 ic.ac.uk. U+LTVkUNoTWXNTabEd/rt15qze4iLWhDFyw+inaYgToGxYA5y3JS+fnx qfe2+GUFSLOz/Xo6czEe7728vCLgXzLQckAyS3g56NUfHKyXO1WWa6lQ k1r9UoNOSj5vTu0YLQN1FgP4aSFjowZzeQtbX//aDXZEVHKjNz4UFwBA zPs=
ns1.ic.ac.uk.           86400   IN      RRSIG   A 5 4 86400 20120816015657 20120717011404 4743 ic.ac.uk. dFRwdOkf670aLyyLtnLAYwo18XQGIFgT8YWQukrsj514pINSR5WUkcpd ReUOGLy9+RDEfpWwDsvdp1DLrxbUzElTF5Qkg/1d76qqB6WxmnQq6lqz r5zKgfh9GNZHKrAOzvLcxlUFhd2xm1NXjktjIhb6CLH+qrJRR9h9+Zxy MlQ=
ns1.ic.ac.uk.           300     IN      RRSIG   AAAA 5 4 300 20120809142748 20120710132748 4743 ic.ac.uk. OBSX8EyrqDcE6QzArCOaecx3Rf5fuBqfMctc/6M+3SnCHqQ9Dzp0YZly 2f6OJXu2JCrR4lGEUfgnA8rXDCKLgkzVIWFZi4y0GVuY2VHXhBptT9ri P0xRDqytbK9FAmIQMjn0gVuRBA6FhHhalh59FrcimXT/DyEj3TjsW2iD IsQ=
ns2.ic.ac.uk.           86400   IN      RRSIG   A 5 4 86400 20120804065011 20120705063843 4743 ic.ac.uk. IQ9KZAqCZLRpDwSpFpwor5ru7ltRfgBkFITKVs5ICz0fGrMQ9uWeWVY2 CLNVmPeXtMseId7Y67+CM4q2Zu+zfBtSiLlDbbqD13FnSdmjqLCHF4PG 7UVW1Z9uqjSHndKuuXeihNUSogyDZyoqf1b4SRcmRwOjgsM7HX0gWy87 jBs=

;; 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

> ...and you should see:
> 
> ; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18199
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 11
> 
> 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.

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=1 ttl=58 time=29.1 ms
3008 bytes from 74.125.226.17: icmp_req=2 ttl=58 time=28.2 ms
3008 bytes from 74.125.226.17: icmp_req=3 ttl=58 time=28.6 ms
3008 bytes from 74.125.226.17: icmp_req=4 ttl=58 time=29.0 ms
3008 bytes from 74.125.226.17: icmp_req=5 ttl=58 time=29.9 ms
3008 bytes from 74.125.226.17: icmp_req=6 ttl=58 time=28.8 ms
3008 bytes from 74.125.226.17: icmp_req=7 ttl=58 time=28.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?

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120720/0eaf9cea/attachment.bin>