Error with DLV and slave zone

Frank Behrens frank at harz.behrens.de
Fri Aug 8 05:50:30 UTC 2008


Mark Andrews <Mark_Andrews at isc.org> wrote on 8 Aug 2008 9:36:

> 	Named does not validate zone data.

Sorry, that i used a misleading subject, but the problem is: I want 
to validate recursive queries for "outside" data. The validation is 
done with DLV data and when I fetch the DLV records from the remote 
server all is working well. But when I create a slave zone for the 
DLV data (to be faster), the resolver returns SERVFAIL for names, 
where no DLV record exists.  

See below for some more comments.

> > I discovered a problem with my DLV setup - validation of non signed 
> > domain names fails. The special case is, that I tried to use the DLV 
> > zone information as slave to avoid additional network traffic during 
> > name resolution. For my tests I configured
> >  dnssec-lookaside "." trust-anchor "dnssec.iks-jena.de."; and
> > zone "dnssec.iks-jena.de" {
> >         type slave;
> > 	...
> > Zone transfer for this zone and lookups for zone data are working 
> > well. I use bind 9.4.2-P1.
> > 
> > When I try to lookup a domain name from germany, e.g. www.stern.de I 
> > get:
> > ; <<>> DiG 9.4.2 <<>> www.stern.de a
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50671
> > 
> > Interestingly for a domain in hungary:
> > ; <<>> DiG 9.4.2 <<>> www.vam.hu a
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9004
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
> > www.vam.hu.             86400 IN A 84.206.40.8
> > 
> > What happened you see in the log:
> > validating @0x91f7800: www.stern.de A: starting
> > validating @0x91f7800: www.stern.de A: looking for DLV
> > validating @0x91f7800: www.stern.de A: plain DNSSEC returns unsecure (.): loo
> > king for DLV
> > validating @0x91f7800: www.stern.de A: looking for DLV www.stern.de.dnssec.ik
> > s-jena.de
> > validating @0x91f7800: www.stern.de A: looking for DLV stern.de.dnssec.iks-je
> > na.de
> > validating @0x91f7800: www.stern.de A: looking for DLV de.dnssec.iks-jena.de
> > validating @0x91f7800: www.stern.de A: DLV lookup: empty name
> > validator @0x91f7800: dns_validator_destroy
> > validating @0x91f7800: www.stern.de A: starting
> > validating @0x91f7800: www.stern.de A: looking for DLV
> > validating @0x91f7800: www.stern.de A: plain DNSSEC returns unsecure (.): loo
> > king for DLV
> > validating @0x91f7800: www.stern.de A: looking for DLV www.stern.de.dnssec.ik
> > s-jena.de
> > validating @0x91f7800: www.stern.de A: looking for DLV stern.de.dnssec.iks-je
> > na.de
> > validating @0x91f7800: www.stern.de A: looking for DLV de.dnssec.iks-jena.de
> > validating @0x91f7800: www.stern.de A: DLV lookup: empty name
> > validator @0x91f7800: dns_validator_destroy
> > validating @0x91f7800: www.stern.de A: starting
> > validating @0x91f7800: www.stern.de A: looking for DLV
> > validating @0x91f7800: www.stern.de A: plain DNSSEC returns unsecure (.): loo
> > king for DLV
> > validating @0x91f7800: www.stern.de A: looking for DLV www.stern.de.dnssec.ik
> > s-jena.de
> > validating @0x91f7800: www.stern.de A: looking for DLV stern.de.dnssec.iks-je
> > na.de
> > validating @0x91f7800: www.stern.de A: looking for DLV de.dnssec.iks-jena.de
> > validating @0x91f7800: www.stern.de A: DLV lookup: empty name
> > validator @0x91f7800: dns_validator_destroy

[ long log cutted ] 

Meanwhile I found a workaround (idea is from Lutz Donnerhacke, IKS 
Jena): Use not a slave zone for DLV data in the same view, instead 
slave the DLV data into a view, which is not used for recursive 
queries and make a forward from the recursive view to the other view. 

> > My interpretation:
> > When the data from internal slave zone are read, the return value may 
> > be DNS_R_EMPTYNAME, but the validator does not expect this.

I still believe here is the error.

> > Additional Note:
> > During my tests I discovered the different result codes for non 
> > existent DLV records. It depends if other entries exists or not. This 
> > can also be seen on ISC server:
> >....
> > Is the NOERROR response without answer record the expected value?

Yes, it seems to be the expected value, because there are entries for 
subdomains.

> > Now I'll ask my final question: It this an error in my configuration 
> > or does it look like a problem in bind itself?

Regards,
   Frank

-- 
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.



More information about the bind-users mailing list