DNSSEC Validating Resolver and Views

[John Marshall]

On Wed, 17 Mar 2010, 11:11 +1100, Mark Andrews wrote:
> In message <20100316234500.GA99617 at rwpc12.mby.riverwillow.net.au>, John Marshal
> l writes:
> > > In message <slrnhpummo.2ter.john at rwpc12.mby.riverwillow.net.au>, John Marsh
> > all 
> > > writes:
> > > > If I grant the guest clients access to the internal view, all is well.
> > > > Things seem to go wobbly, unless checking is disabled, when we forward
> > > > the guest view queries to the internal view.
> > 
> > So, this seems to be where it's breaking.  Perhaps my design is just
> > wrong and it "just happened to work" until either 9.7.0 or...?  It still
> > works if the guest view client queries with checking disabled.  It works
> > properly for internal view clients.  Does a second level of indirection
> > mean that the resolver loses sight of the trust anchor?
> 
> It should work.  You don't have any other trusted-keys configured?

The only other key is for the (internal) zone in which the name servers
live: that's the only zone we're signing at present.

> My next step would be to ask from a internal, not a guest address,
> for DS 168.192.in-addr.arpa.  This eliminates one step in the chain.

I got either named or myself confused when I started modifying the
logging configuration, so I re-started named and now everything works.
Hmmm.  I pointed at another server and noted the same broken behaviour
there as well.  I set up logging (carefully) on that server and pointed
an "internal" client at it.

; <<>> DiG 9.7.0 <<>> @172.25.24.17 168.192.in-addr.arpa. ds
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3079
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;168.192.in-addr.arpa.		IN	DS

;; Query time: 1388 msec
;; SERVER: 172.25.24.17#53(172.25.24.17)
;; WHEN: Wed Mar 17 14:02:00 2010
;; MSG SIZE  rcvd: 38

This is what was logged for the above query...

[queries log]
17-Mar-2010 14:04:11.140 queries: client 172.25.24.18#42640: view internal: query: 168.192.in-addr.arpa IN DS + (172.25.24.17)

[dnssec log] (7 iterations of the following)
17-Mar-2010 14:04:11.324 dnssec: debug 3: validating @0x2878c000: 192.in-addr.arpa NS: starting
17-Mar-2010 14:04:11.324 dnssec: debug 3: validating @0x2878c000: 192.in-addr.arpa NS: looking for DLV
17-Mar-2010 14:04:11.324 dnssec: debug 3: validating @0x2878c000: 192.in-addr.arpa NS: plain DNSSEC returns unsecure (.): looking for DLV
17-Mar-2010 14:04:11.324 dnssec: debug 3: validating @0x2878c000: 192.in-addr.arpa NS: looking for DLV 192.in-addr.arpa.dlv.isc.org
17-Mar-2010 14:04:11.324 dnssec: debug 3: validating @0x2878c000: 192.in-addr.arpa NS: DLV not validated
17-Mar-2010 14:04:11.324 dnssec: debug 3: validating @0x2878c000: 192.in-addr.arpa NS: DLV lookup: no valid RRSIG
17-Mar-2010 14:04:11.324 dnssec: debug 3: validator @0x2878c000: dns_validator_destroy

[query_errors log]
17-Mar-2010 14:04:12.527 query-errors: debug 1: client 172.25.24.18#42640: view internal: query failed (SERVFAIL) for 168.192.in-addr.arpa/IN/DS at query.c:4631
17-Mar-2010 14:04:12.527 query-errors: debug 2: fetch completed at resolver.c:6117 for 168.192.in-addr.arpa/DS in 1.386784: SERVFAIL/success [domain:168.192.in-addr.arpa,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:1,adberr:0,findfail:0,valfail:0]

I wondered if flushing the cache would clear this.  It did.  At the very
moment when I had applied sufficient pressure on the Enter key to commit
the "rndc flush" it occurred to me that I ought to dump the cache first.
Sorry.

I'll upgrade these servers to 9.7.0-P1 this afternoon and keep an eye
out for this behaviour recurring.

Thank you for your help.

-- 
John Marshall