DNSSEC Validating Resolver and Views

John Marshall john.marshall at riverwillow.com.au
Tue Mar 16 23:45:00 UTC 2010


On Wed, 17 Mar 2010, 09:03 +1100, Mark Andrews wrote:
> In message <slrnhpummo.2ter.john at rwpc12.mby.riverwillow.net.au>, John Marshall 
> writes:
> > I don't understand this.  If the client needs an answer from
> > 25.168.192.in-addr.arpa. and we are hosting that zone and its parent
> > zone (both unsigned, both in our internal view), why are we looking
> > higher for DS records?
> 
> Because you have a trust anchor configured at or above the query name and
> the validator need to see a DS or non existance proof (NSEC/NSEC3) for the
> DS which indicates a secure to insecure transition.
> 
> Are your trust anchors up to date?

I haven't changed my dlv.isc.org anchor since I configured DNSSEC on the
server about 18 months ago: it matches the one published on the ISC web
site (2008/09/21) and everything works fine for my internal view.

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

options {
        ...
        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside . trust-anchor dlv.isc.org.;
};

trusted-keys {
        dlv.isc.org. 257 3 5
        ...
};

view "internal" IN {
        match-clients {
                IntNET;
                ! ExtStealth;
                ! ExtDNS;
                ExtNET;
                localhost;
        };
        allow-query {
                localhost;
                IntNET;
                ExtNET;
        };
        recursion yes;
        ...
        zone "168.192.in-addr.arpa" {
                type master;
                file "db/master/192.168";
        };

        zone "25.168.192.in-addr.arpa" {
                type master;
                file "db/master/192.168.25";
                allow-update {
                        key dhcp-rw.;
                };
        };
};

view "guest" IN {
        match-clients {
                GstNET;
        };
        allow-query {
                GstNET;
        };
        recursion yes;
        ...
        forward only;
        forwarders {
                        172.25.24.16;           # self (internal)
        };

        zone <some.others> {
                type forward;
                forward only;
                forwarders {
                        203.58.93.34;           # self (external)
                };
        };
};

view "external" IN {
        match-clients {
                any;
        };
        recursion no;
        additional-from-cache no;
        ...
        zone <some.others> {
                type master;
                ...
        };
};

-- 
John Marshall



More information about the bind-users mailing list