On Wed, 17 Mar 2010, 11:11 +1100, Mark Andrews wrote: > In message <20100316234500.ga99...@rwpc12.mby.riverwillow.net.au>, John > Marshal > l writes: > > > In message <slrnhpummo.2ter.j...@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 _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
