Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

7,925 views
Skip to first unread message

Brian J. Murrell

unread,
May 2, 2012, 8:46:45 AM5/2/12
to bind9...@isc.org
Not having dipped my toe into DNSSEC yet (yes, I know, but time is
always so scarce)...

So I am seeing a bunch of this sort of thing in my BIND logs now:

04:02:18 named validating @0xb0f58988: 124.in-addr.arpa SOA: no valid signature found
04:02:18 named validating @0xb0f58988: 124.in-addr.arpa NSEC: no valid signature found
04:02:18 named validating @0xb0f58988: 227.124.in-addr.arpa NSEC: no valid signature found
04:03:30 named validating @0xb0f58988: net SOA: no valid signature found
04:03:30 named validating @0xb0f58988: a1rt98bs5qgc9nfi51s9hci47uljg6jh.net NSEC3: no valid signature found
04:03:30 named validating @0xb0f58988: 5VI63OJ105LD6R767I45IDJR5Q55T1R1.net NSEC3: no valid signature found
04:03:30 named validating @0xb0f58988: EEE0K4ONQCCHCJQTQ5VJD52NKJTEHAJN.net NSEC3: no valid signature found
04:03:30 named validating @0xb0f4d8c0: uk SOA: no valid signature found
04:03:30 named validating @0xb21ea7c0: u1fmklfv3rdcnamdc64sekgcdp05bbiu.uk NSEC3: no valid signature found
04:03:30 named validating @0xb0f67990: pl SOA: no valid signature found
04:03:30 named validating @0xb18914a0: RVLFSE0643QVHS3RI8VPKGANFBCJVJ06.pl NSEC3: no valid signature found
04:03:31 named validating @0xb0f949d0: GSV9U2BOSCL9B9TQAL1UAV4BNVI9EVUE.pl NSEC3: no valid signature found
04:03:31 named validating @0xb21cc520: org SOA: no valid signature found
04:03:31 named validating @0xb18f2c08: org SOA: no valid signature found
04:03:31 named validating @0xb21ea7c0: fk47636n6psb8mv7rdu6tpdhas69cbjp.org NSEC3: no valid signature found
04:03:31 named validating @0xb0fe6528: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org NSEC3: no valid signature found
04:03:31 named validating @0xb0f61960: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org NSEC3: no valid signature found
04:03:31 named validating @0xb21cc520: 4rkhv4s4situ82j70sp5tq5utm12o2t8.org NSEC3: no valid signature found
04:03:31 named validating @0xb18f2c08: ic8a82pge1m0qdob5sce1e3613hqr7br.org NSEC3: no valid signature found
04:03:31 named validating @0xb0f949d0: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org NSEC3: no valid signature found
04:03:31 named validating @0xb0f949d0: vai6s58iqmjmin7ju8mq61aju3q4ms5h.org NSEC3: no valid signature found
04:03:31 named validating @0xb0f949d0: org SOA: no valid signature found
04:03:31 named validating @0xb18914a0: vai6s58iqmjmin7ju8mq61aju3q4ms5h.org NSEC3: no valid signature found
04:03:31 named validating @0xb21e1518: vai6s58iqmjmin7ju8mq61aju3q4ms5h.org NSEC3: no valid signature found
04:09:43 named validating @0xb0f58988: 117.in-addr.arpa SOA: no valid signature found
04:09:43 named validating @0xb0f58988: 117.in-addr.arpa NSEC: no valid signature found
04:09:43 named validating @0xb0f58988: 240.117.in-addr.arpa NSEC: no valid signature found
04:13:52 named validating @0xb0f58988: 27.in-addr.arpa SOA: no valid signature found
04:13:52 named validating @0xb0f58988: 22.115.27.in-addr.arpa NSEC: no valid signature found
04:13:52 named validating @0xb0f58988: 99.114.27.in-addr.arpa NSEC: no valid signature found
04:15:16 named validating @0xb0f58988: 117.in-addr.arpa SOA: no valid signature found
04:15:16 named validating @0xb0f58988: 117.in-addr.arpa NSEC: no valid signature found
04:15:16 named validating @0xb0f58988: 99.20.117.in-addr.arpa NSEC: no valid signature found
04:15:48 named validating @0xb0f58988: org SOA: no valid signature found
04:15:48 named validating @0xb0f58988: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org NSEC3: no valid signature found
04:15:48 named validating @0xb0f58988: osfek8jf3dv7trcfcuheumjh9bpmjkeq.org NSEC3: no valid signature found
04:15:48 named validating @0xb0f58988: vai6s58iqmjmin7ju8mq61aju3q4ms5h.org NSEC3: no valid signature found

And am wondering what they are really telling me. Are they all
different flavours of "zone is not signed" or are they more like
"zone is supposed to be signed but there are problems with it"?

Cheers,
b.

signature.asc

Mark Andrews

unread,
May 2, 2012, 9:29:30 AM5/2/12
to Brian J. Murrell, bind9...@isc.org

In message <jnrabn$olm$1...@dough.gmane.org>, "Brian J. Murrell" writes:
> Not having dipped my toe into DNSSEC yet (yes, I know, but time is
> always so scarce)...
>
> So I am seeing a bunch of this sort of thing in my BIND logs now:
>
> 04:02:18 named validating @0xb0f58988: 124.in-addr.arpa SOA: no valid sig=
> nature found
> 04:02:18 named validating @0xb0f58988: 124.in-addr.arpa NSEC: no valid si=
> gnature found
> 04:02:18 named validating @0xb0f58988: 227.124.in-addr.arpa NSEC: no vali=
> d signature found
> 04:03:30 named validating @0xb0f58988: net SOA: no valid signature found
> 04:03:30 named validating @0xb0f58988: a1rt98bs5qgc9nfi51s9hci47uljg6jh.n=
> et NSEC3: no valid signature found
> 04:03:30 named validating @0xb0f58988: 5VI63OJ105LD6R767I45IDJR5Q55T1R1.n=
> et NSEC3: no valid signature found
> 04:03:30 named validating @0xb0f58988: EEE0K4ONQCCHCJQTQ5VJD52NKJTEHAJN.n=
> et NSEC3: no valid signature found
> 04:03:30 named validating @0xb0f4d8c0: uk SOA: no valid signature found
> 04:03:30 named validating @0xb21ea7c0: u1fmklfv3rdcnamdc64sekgcdp05bbiu.u=
> k NSEC3: no valid signature found
> 04:03:30 named validating @0xb0f67990: pl SOA: no valid signature found
> 04:03:30 named validating @0xb18914a0: RVLFSE0643QVHS3RI8VPKGANFBCJVJ06.p=
> l NSEC3: no valid signature found
> 04:03:31 named validating @0xb0f949d0: GSV9U2BOSCL9B9TQAL1UAV4BNVI9EVUE.p=
> l NSEC3: no valid signature found
> 04:03:31 named validating @0xb21cc520: org SOA: no valid signature found
> 04:03:31 named validating @0xb18f2c08: org SOA: no valid signature found
> 04:03:31 named validating @0xb21ea7c0: fk47636n6psb8mv7rdu6tpdhas69cbjp.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb0fe6528: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb0f61960: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb21cc520: 4rkhv4s4situ82j70sp5tq5utm12o2t8.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb18f2c08: ic8a82pge1m0qdob5sce1e3613hqr7br.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb0f949d0: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb0f949d0: vai6s58iqmjmin7ju8mq61aju3q4ms5h.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb0f949d0: org SOA: no valid signature found
> 04:03:31 named validating @0xb18914a0: vai6s58iqmjmin7ju8mq61aju3q4ms5h.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb21e1518: vai6s58iqmjmin7ju8mq61aju3q4ms5h.o=
> rg NSEC3: no valid signature found
> 04:09:43 named validating @0xb0f58988: 117.in-addr.arpa SOA: no valid sig=
> nature found
> 04:09:43 named validating @0xb0f58988: 117.in-addr.arpa NSEC: no valid si=
> gnature found
> 04:09:43 named validating @0xb0f58988: 240.117.in-addr.arpa NSEC: no vali=
> d signature found
> 04:13:52 named validating @0xb0f58988: 27.in-addr.arpa SOA: no valid sign=
> ature found
> 04:13:52 named validating @0xb0f58988: 22.115.27.in-addr.arpa NSEC: no va=
> lid signature found
> 04:13:52 named validating @0xb0f58988: 99.114.27.in-addr.arpa NSEC: no va=
> lid signature found
> 04:15:16 named validating @0xb0f58988: 117.in-addr.arpa SOA: no valid sig=
> nature found
> 04:15:16 named validating @0xb0f58988: 117.in-addr.arpa NSEC: no valid si=
> gnature found
> 04:15:16 named validating @0xb0f58988: 99.20.117.in-addr.arpa NSEC: no va=
> lid signature found
> 04:15:48 named validating @0xb0f58988: org SOA: no valid signature found
> 04:15:48 named validating @0xb0f58988: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.o=
> rg NSEC3: no valid signature found
> 04:15:48 named validating @0xb0f58988: osfek8jf3dv7trcfcuheumjh9bpmjkeq.o=
> rg NSEC3: no valid signature found
> 04:15:48 named validating @0xb0f58988: vai6s58iqmjmin7ju8mq61aju3q4ms5h.o=
> rg NSEC3: no valid signature found
>
> And am wondering what they are really telling me. Are they all
> different flavours of "zone is not signed" or are they more like
> "zone is supposed to be signed but there are problems with it"?
>
> Cheers,
> b.

The zones are signed. Possible reason are:

* a firewall blocking EDNS queries.
* using a non DNSSEC enabled forwarder so you don't get signatures.
* a firewall blocking fragmented UDP and named falling back to
plain DNS.
* other packet loss causing named to fallback to plain DNS.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Brian J. Murrell

unread,
May 6, 2012, 10:13:49 AM5/6/12
to bind-...@isc.org, bind9...@isc.org
On 12-05-02 09:29 AM, Mark Andrews wrote:
>
>
> The zones are signed. Possible reason are:
>
> * a firewall blocking EDNS queries.

This shouldn't be the case. Outgoing traffic from the bind9 server
being used here should be completely unfettered.

> * using a non DNSSEC enabled forwarder so you don't get signatures.

I believe my forwarder (bind9 server) is DNSSEC enabled:

options {
...
// enable DNSSEC
dnssec-enable yes;
dnssec-validation yes;
// as of 9.7, use "auto" instead
// dnssec-lookaside . trust-anchor dlv.isc.org.;
dnssec-lookaside auto;

};

> * a firewall blocking fragmented UDP and named falling back to
> plain DNS.

Again, the firewall should be allowing bind9 to do whatever it wants.

> * other packet loss causing named to fallback to plain DNS.

I'm not seeing any evidence of that here otherwise.

Can you prescribe any tests that I can do to [dis-]prove any of the
above theories?

Cheers and much thanks,
b.



signature.asc

Brian J. Murrell

unread,
May 15, 2012, 8:22:57 AM5/15/12
to bind-...@isc.org, bind9...@isc.org
On 12-05-02 09:29 AM, Mark Andrews wrote:
>
> * a firewall blocking EDNS queries.
> * using a non DNSSEC enabled forwarder so you don't get signatures.
> * a firewall blocking fragmented UDP and named falling back to
> plain DNS.
> * other packet loss causing named to fallback to plain DNS.

Given that I have confirmed EDNS works with:

dig edns-v4-ok.isc.org TXT
dig edns-v6-ok.isc.org TXT

and that I don't have a firewall that would/should be dropping
(properly) fragmented UDP[1] and I have no other indications of packet
loss, are we looking at a bug in BIND9 to explain this (mis-)behavior?

Cheers,
b.

[1] I'd be happy to test and provide evidence if anyone has a test that
will do so. Perhaps a dig command targeted at one of the many failures
that my logs are constantly showing?

signature.asc

Phil Mayers

unread,
May 15, 2012, 9:01:42 AM5/15/12
to bind-...@lists.isc.org
On 15/05/12 13:22, Brian J. Murrell wrote:
> On 12-05-02 09:29 AM, Mark Andrews wrote:
>>
>> * a firewall blocking EDNS queries.
>> * using a non DNSSEC enabled forwarder so you don't get signatures.
>> * a firewall blocking fragmented UDP and named falling back to
>> plain DNS.
>> * other packet loss causing named to fallback to plain DNS.
>
> Given that I have confirmed EDNS works with:
>
> dig edns-v4-ok.isc.org TXT
> dig edns-v6-ok.isc.org TXT
>
> and that I don't have a firewall that would/should be dropping
> (properly) fragmented UDP[1] and I have no other indications of packet
> loss, are we looking at a bug in BIND9 to explain this (mis-)behavior?

Isn't it more likely it's a local problem?

Which version of bind are you running? Does *any* zone validate e.g. try:

dig +dnssec @localhost www.ic.ac.uk

...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".

Brian J. Murrell

unread,
Jul 20, 2012, 8:34:45 AM7/20/12
to bind-...@isc.org
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.

signature.asc

Brian J. Murrell

unread,
Jul 20, 2012, 9:03:16 AM7/20/12
to bind-...@isc.org
On 12-07-20 08:34 AM, Brian J. Murrell wrote:
>
> The problem here seems to be fragmented UDP.

I seem to have misdiagnosed this due to tcpdump peculiarities. I only
initially saw/suspected the problem since my capture for port 53
packets was including (only the first) ipv4 fragments. When adding a
capture specifically to get all ipv4 fragments in addition to my port
53 packets, I do see all of the fragments.

So back to the drawing board.

In my previous posting, I was able to demonstrate that I do get some
queries authenticated, but others (corresponding to the errors in my
logs) are not. For example:

Jul 20 08:59:37 linux named[17472]: validating @0xf48d01b0: 119.in-addr.arpa SOA: no valid signature found

and sure enough:

# dig +dnssec @localhost 119.in-addr.arpa SOA

; <<>> DiG 9.9.1-P1 <<>> +dnssec @localhost 119.in-addr.arpa SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49713
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 14

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;119.in-addr.arpa. IN SOA

;; ANSWER SECTION:
119.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 3006082431 7200 1800 604800 172800
119.in-addr.arpa. 172800 IN RRSIG SOA 5 3 172800 20120819055026 20120720045026 31291 119.in-addr.arpa. DxSB8J+SsHzLRv/qiFdQOLQ4eYEgCm6lUGr5/qoMje7iY9OIaaXmH/WM GwbTDdT7YNXfkZ7ZfpEnE5N9OeNW6Wghi8Wcerpy3OmEYMTWc1ZNgH70 KC8Rhth23mCkv+IdCEsirVKdgTgLYsRlPFMbp6WQveMQRyJwvGJQm4QI Ejk=

;; AUTHORITY SECTION:
119.in-addr.arpa. 78212 IN NS ns1.apnic.net.
119.in-addr.arpa. 78212 IN NS sec1.authdns.ripe.net.
119.in-addr.arpa. 78212 IN NS ns2.lacnic.net.
119.in-addr.arpa. 78212 IN NS ns4.apnic.net.
119.in-addr.arpa. 78212 IN NS ns3.apnic.net.
119.in-addr.arpa. 78212 IN NS apnic1.dnsnode.net.
119.in-addr.arpa. 78212 IN NS tinnie.arin.net.

;; ADDITIONAL SECTION:
ns1.apnic.net. 167 IN A 202.12.29.25
ns1.apnic.net. 164129 IN AAAA 2001:dc0:2001:0:4608::25
ns2.lacnic.net. 82967 IN A 200.3.13.11
ns2.lacnic.net. 164257 IN AAAA 2001:13c7:7002:3000::11
ns3.apnic.net. 167 IN A 202.12.28.131
ns3.apnic.net. 164129 IN AAAA 2001:dc0:1:0:4777::131
ns4.apnic.net. 167 IN A 202.12.31.140
ns4.apnic.net. 164129 IN AAAA 2001:dc0:4001:1:0:1836:0:140
sec1.authdns.ripe.net. 167 IN A 193.0.9.3
apnic1.dnsnode.net. 3767 IN A 194.146.106.106
tinnie.arin.net. 35918 IN A 199.212.0.53
tinnie.arin.net. 35918 IN AAAA 2001:500:13::c7d4:35
sec1.authdns.ripe.net. 167 IN RRSIG A 5 4 3600 20120819100246 20120720090246 16848 ripe.net. PnInozslOygv30AuohnYIzlCkeShxybKYeZ4114kpClfsMB/t3liXNmw in7Ha8Mh1mOZFtv2lvYDNlnrZgO65xXkUwsH2iz1jCMFU6ZjwGhqVhaX PpN6T6BXDHSohpFkVlx0yu9J7BcPMuCD6FJB5yLF4V0UUkJoPOXFAKBa mto=

;; Query time: 239 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul 20 09:02:18 2012
;; MSG SIZE rcvd: 892

no "ad" bit set.

But why?

Cheers,
b.

signature.asc

Phil Mayers

unread,
Jul 20, 2012, 9:11:29 AM7/20/12
to bind-...@lists.isc.org
On 20/07/12 14:03, Brian J. Murrell wrote:

> # dig +dnssec @localhost 119.in-addr.arpa SOA
>
> ; <<>> DiG 9.9.1-P1 <<>> +dnssec @localhost 119.in-addr.arpa SOA
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49713
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 14

What do you see if you:

1. Clear the cache
2. Start tcpdump
3. Do this query

Presumably there is a failing DNS query somewhere underlying this.

Or, what happens if you start bind up in debug mode and run the query?
There will be a lot of output, but I've found most problems to be fairly
obvious if you read through it.

Mark Andrews

unread,
Jul 20, 2012, 9:42:15 AM7/20/12
to Brian J. Murrell, bind-...@isc.org

In message <50095065...@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-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> --===============7167988486076323267==--

Casey Deccio

unread,
Jul 20, 2012, 10:12:38 AM7/20/12
to Brian J. Murrell, bind-...@isc.org

On Fri, Jul 20, 2012 at 6:03 AM, Brian J. Murrell <br...@interlinx.bc.ca> wrote:
On 12-07-20 08:34 AM, Brian J. Murrell wrote:
>
> The problem here seems to be fragmented UDP.

I seem to have misdiagnosed this due to tcpdump peculiarities.  I only
initially saw/suspected the problem since my capture for port 53
packets was including (only the first) ipv4 fragments.  When adding a
capture specifically to get all ipv4 fragments in addition to my port
53 packets, I do see all of the fragments.


Just because you see the fragments on the wire doesn't mean they're getting past the local firewall and being reassembled.  For example, if you're using ip6tables on a Linux kernel <= 2.6.20 IPv6 fragments aren't allowed through properly [1].  What OS/kernel are you using?

Casey

[1] See https://dnssec.surfnet.nl/?p=464

Brian J. Murrell

unread,
Jul 20, 2012, 10:33:15 AM7/20/12
to bind-...@isc.org
On 12-07-20 09:11 AM, Phil Mayers wrote:
>
> Or, what happens if you start bind up in debug mode and run the query?
> There will be a lot of output, but I've found most problems to be fairly
> obvious if you read through it.

Yeah, there is a lot of output. Too big of a haystack for me to find
the needle I'm afraid. I probably had way too much debug enabled. I'd
be happy to trim it back if desired. Just tell me which categories
you'd want to see and what severity to set.

In any case, the log is at
http://brian.interlinx.bc.ca/119.in-addr.arpa.debug and the query I did was:

dig +dnssec @localhost 119.in-addr.arpa SOA

The log should be as brief as it can be as I started named, did the
query and waited for the response and then stopped bind.

Just for good measure, since I think I have posted this before, but here
are the options I have set in my bind configuration with regard to dnssec:

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

Cheers,
b.

signature.asc

Mark Andrews

unread,
Jul 20, 2012, 10:42:21 AM7/20/12
to Brian J. Murrell, bind-...@isc.org

In message <jubkum$qve$1...@dough.gmane.org>, "Brian J. Murrell" writes:
> On 12-07-20 08:34 AM, Brian J. Murrell wrote:
> >=20
> > The problem here seems to be fragmented UDP.
>
> I seem to have misdiagnosed this due to tcpdump peculiarities. I only
> initially saw/suspected the problem since my capture for port 53
> packets was including (only the first) ipv4 fragments. When adding a
> capture specifically to get all ipv4 fragments in addition to my port
> 53 packets, I do see all of the fragments.
>
> So back to the drawing board.
>
> In my previous posting, I was able to demonstrate that I do get some
> queries authenticated, but others (corresponding to the errors in my
> logs) are not. For example:
>
> Jul 20 08:59:37 linux named[17472]: validating @0xf48d01b0: 119.in-addr=
> =2Earpa SOA: no valid signature found
>
> and sure enough:
>
> # dig +dnssec @localhost 119.in-addr.arpa SOA
>
> ; <<>> DiG 9.9.1-P1 <<>> +dnssec @localhost 119.in-addr.arpa SOA
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49713
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 14
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;119.in-addr.arpa. IN SOA
>
> ;; ANSWER SECTION:
> 119.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-txt-r=
> ecord-of-zone-first-dns-admin.apnic.net. 3006082431 7200 1800 604800 1728=
> 00
> 119.in-addr.arpa. 172800 IN RRSIG SOA 5 3 172800 2012081905=
> 5026 20120720045026 31291 119.in-addr.arpa. DxSB8J+SsHzLRv/qiFdQOLQ4eYEgC=
> m6lUGr5/qoMje7iY9OIaaXmH/WM GwbTDdT7YNXfkZ7ZfpEnE5N9OeNW6Wghi8Wcerpy3OmEY=
> MTWc1ZNgH70 KC8Rhth23mCkv+IdCEsirVKdgTgLYsRlPFMbp6WQveMQRyJwvGJQm4QI Ejk=3D=
>
>
> ;; AUTHORITY SECTION:
> 119.in-addr.arpa. 78212 IN NS ns1.apnic.net.
> 119.in-addr.arpa. 78212 IN NS sec1.authdns.ripe.net.
> 119.in-addr.arpa. 78212 IN NS ns2.lacnic.net.
> 119.in-addr.arpa. 78212 IN NS ns4.apnic.net.
> 119.in-addr.arpa. 78212 IN NS ns3.apnic.net.
> 119.in-addr.arpa. 78212 IN NS apnic1.dnsnode.net.
> 119.in-addr.arpa. 78212 IN NS tinnie.arin.net.
>
> ;; ADDITIONAL SECTION:
> ns1.apnic.net. 167 IN A 202.12.29.25
> ns1.apnic.net. 164129 IN AAAA 2001:dc0:2001:0:4608::25
> ns2.lacnic.net. 82967 IN A 200.3.13.11
> ns2.lacnic.net. 164257 IN AAAA 2001:13c7:7002:3000::11
> ns3.apnic.net. 167 IN A 202.12.28.131
> ns3.apnic.net. 164129 IN AAAA 2001:dc0:1:0:4777::131
> ns4.apnic.net. 167 IN A 202.12.31.140
> ns4.apnic.net. 164129 IN AAAA 2001:dc0:4001:1:0:1836:0:=
> 140
> sec1.authdns.ripe.net. 167 IN A 193.0.9.3
> apnic1.dnsnode.net. 3767 IN A 194.146.106.106
> tinnie.arin.net. 35918 IN A 199.212.0.53
> tinnie.arin.net. 35918 IN AAAA 2001:500:13::c7d4:35
> sec1.authdns.ripe.net. 167 IN RRSIG A 5 4 3600 20120819100246=
> 20120720090246 16848 ripe.net. PnInozslOygv30AuohnYIzlCkeShxybKYeZ4114kp=
> ClfsMB/t3liXNmw in7Ha8Mh1mOZFtv2lvYDNlnrZgO65xXkUwsH2iz1jCMFU6ZjwGhqVhaX =
> PpN6T6BXDHSohpFkVlx0yu9J7BcPMuCD6FJB5yLF4V0UUkJoPOXFAKBa mto=3D
>
> ;; Query time: 239 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Jul 20 09:02:18 2012
> ;; MSG SIZE rcvd: 892
>
> no "ad" bit set.
>
> But why?

The NS RRset is the delegation records and as such has no RRSIGs.
If you turn on minimal-responses the NS rrset won't be added and
AD won't be cleared. AD is only set to 1 if all the records in the
answer and authority sections are marked as secure.

> Cheers,
> b.

Brian J. Murrell

unread,
Jul 20, 2012, 10:55:41 AM7/20/12
to bind-...@isc.org
On 12-07-20 10:42 AM, Mark Andrews wrote:
>
> The NS RRset is the delegation records and as such has no RRSIGs.
> If you turn on minimal-responses the NS rrset won't be added and
> AD won't be cleared. AD is only set to 1 if all the records in the
> answer and authority sections are marked as secure.

OK. So I added:

minimal-responses yes;

and the dig response does indeed look much more "minimal", but the
ad bit is still not being set:

# dig +dnssec @localhost 119.in-addr.arpa SOA

; <<>> DiG 9.9.1-P1 <<>> +dnssec @localhost 119.in-addr.arpa SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45253
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;119.in-addr.arpa. IN SOA

;; ANSWER SECTION:
119.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 3006082431 7200 1800 604800 172800
119.in-addr.arpa. 172800 IN RRSIG SOA 5 3 172800 20120819055026 20120720045026 31291 119.in-addr.arpa. DxSB8J+SsHzLRv/qiFdQOLQ4eYEgCm6lUGr5/qoMje7iY9OIaaXmH/WM GwbTDdT7YNXfkZ7ZfpEnE5N9OeNW6Wghi8Wcerpy3OmEYMTWc1ZNgH70 KC8Rhth23mCkv+IdCEsirVKdgTgLYsRlPFMbp6WQveMQRyJwvGJQm4QI Ejk=

;; Query time: 720 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul 20 10:50:21 2012
;; MSG SIZE rcvd: 310

Strangely I didn't get an error logged about there being no valid
signature for 119.in-addr.arpa SOA though.

Cheers,
b.

signature.asc

Phil Mayers

unread,
Jul 20, 2012, 11:14:21 AM7/20/12
to Brian J. Murrell, bind-...@lists.isc.org
On 20/07/12 15:33, Brian J. Murrell wrote:
> On 12-07-20 09:11 AM, Phil Mayers wrote:
>>
>> Or, what happens if you start bind up in debug mode and run the query?
>> There will be a lot of output, but I've found most problems to be fairly
>> obvious if you read through it.
>
> Yeah, there is a lot of output. Too big of a haystack for me to find
> the needle I'm afraid. I probably had way too much debug enabled. I'd
> be happy to trim it back if desired. Just tell me which categories
> you'd want to see and what severity to set.
>
> In any case, the log is at
> http://brian.interlinx.bc.ca/119.in-addr.arpa.debug and the query I did was:
>


A quick skim suggests that you aren't able to validate the root, but are
able to validate DLV, which is why a subset of sites are working - those
still with DLV entries.

If you can validate www.ic.ac.uk but not www.cam.ac.uk (who have now
left DLV) then this might confirm it.

No idea why the root isn't valid for you, given you are running a recent
bind - presumably the managed-keys config is messed up somehow.

Have you tried a clean install; blow away the entire /var/named and
config hierarchy and start again?

Mark Andrews

unread,
Jul 20, 2012, 11:21:41 AM7/20/12
to Brian J. Murrell, bind-...@isc.org

In message <50096C2B...@interlinx.bc.ca>, "Brian J. Murrell" writes:
> Just for good measure, since I think I have posted this before, but here
> are the options I have set in my bind configuration with regard to dnssec=
> :
>
> dnssec-enable yes;
> dnssec-validation yes;
> dnssec-lookaside auto;

Turn on validation using the root's DNSKEY.

auto-dnssec maintian;

or

managed-keys {
. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";
};

Currently you are only using DLV and 119.in-addr.arpa and parent zones
are not in the DLV registry.

>
> Cheers,
> b.
>
>
> --------------enig5965E6494F1E722963B87E50
> 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/
>
> iEYEARECAAYFAlAJbCwACgkQl3EQlGLyuXBbywCcDYbboiJuyhXfP9AuztJjJana
> ZhcAoNgNAIdBwEbR9ZjpHTl7S9xlZrSB
> =CrUS
> -----END PGP SIGNATURE-----
>
> --------------enig5965E6494F1E722963B87E50--
>
>
> --===============7481589219356167105==
> 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-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> --===============7481589219356167105==--

Phil Mayers

unread,
Jul 20, 2012, 11:26:29 AM7/20/12
to bind-...@lists.isc.org
On 20/07/12 16:21, Mark Andrews wrote:
>
> In message <50096C2B...@interlinx.bc.ca>, "Brian J. Murrell" writes:
>> Just for good measure, since I think I have posted this before, but here
>> are the options I have set in my bind configuration with regard to dnssec=
>> :
>>
>> dnssec-enable yes;
>> dnssec-validation yes;
>> dnssec-lookaside auto;

FWIW, on 9.8 the only other line we have (for reasons of permissions) is:

managed-keys-directory "/var/named/data/dynamic";

I don't see why those 3 lines aren't sufficient for him?

>
> Turn on validation using the root's DNSKEY.
>
> auto-dnssec maintian;

I thought that was for master zones, not recursion/validation? Or am I
missing something?

Mark Andrews

unread,
Jul 20, 2012, 11:40:33 AM7/20/12
to Phil Mayers, bind-...@isc.org
My bad. "dnssec-validation auto;" is what I was thinking about.

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Brian J. Murrell

unread,
Jul 20, 2012, 12:22:24 PM7/20/12
to bind-...@isc.org
On 12-07-20 11:40 AM, Mark Andrews wrote:
>
> In message <500978A5...@imperial.ac.uk>, Phil Mayers writes:
>> On 20/07/12 16:21, Mark Andrews wrote:
>>>
>>> In message <50096C2B...@interlinx.bc.ca>, "Brian J. Murrell" writes:
>>>> Just for good measure, since I think I have posted this before, but here
>>>> are the options I have set in my bind configuration with regard to dnssec=
>>>> :
>>>>
>>>> dnssec-enable yes;
>>>> dnssec-validation yes;
>>>> dnssec-lookaside auto;
>
> My bad. "dnssec-validation auto;" is what I was thinking about.

Interesting. Is "auto" for that value different/better than "yes",
which I have configured already?

Cheers,
b.


signature.asc

Mark Andrews

unread,
Jul 20, 2012, 7:16:26 PM7/20/12
to Brian J. Murrell, bind-...@isc.org

In message <500985C0...@interlinx.bc.ca>, "Brian J. Murrell" writes:
> On 12-07-20 11:40 AM, Mark Andrews wrote:
> >=20
> > In message <500978A5...@imperial.ac.uk>, Phil Mayers writes:
> >> On 20/07/12 16:21, Mark Andrews wrote:
> >>>
> >>> In message <50096C2B...@interlinx.bc.ca>, "Brian J. Murrell" wri=
> tes:
> >>>> Just for good measure, since I think I have posted this before, but =
> here
> >>>> are the options I have set in my bind configuration with regard to d=
> nssec=3D
> >>>> :
> >>>>
> >>>> dnssec-enable yes;
> >>>> dnssec-validation yes;
> >>>> dnssec-lookaside auto;
> >=20
> > My bad. "dnssec-validation auto;" is what I was thinking about.
>
> Interesting. Is "auto" for that value different/better than "yes",
> which I have configured already?
>
> Cheers,
> b.

"dnssec-validation auto;" tells named to use the compiled
in root key in addition to enabling validation. Depending
on the version this is a plain trusted-key or a managed-key.

If NS_SYSCONFDIR/bind.keys exists and is readable its contents
override the built in contents.

The root key(s) and dlv.isc.org key(s) are loaded from this
file for dnssec-validation auto; and dnssec-lookaside auto;
respectively.

Mark

Brian J. Murrell

unread,
Jul 21, 2012, 10:38:26 AM7/21/12
to bind-...@isc.org
On 12-07-20 07:16 PM, Mark Andrews wrote:
>
> "dnssec-validation auto;"

Well, this seems to have done the trick. Changing it from yes to auto
has eliminated most (almost all in fact) of the validation
warnings/errors I was getting in my logs.

> tells named to use the compiled
> in root key in addition to enabling validation.

Ahhhh. So "yes" just enables validation but doesn't use any compiled in
root key? If so, this is an annoying (all due respect) and small but
important distinction.

I'm not sure about anyone else, but a yes/no/auto selector to me means
either an explicit yes or explicit no with auto meaning some kind of "do
what you think is right" in terms of making it yes or no. I don't
typically think of it as no or yes plus some additional functionality.

Anyway, you have my since appreciation for persevering with me in my
efforts to figure this out.

b.

signature.asc
0 new messages