DNSSEC Validating Resolver and Views
Mark Andrews
marka at isc.org
Wed Mar 17 00:14:22 UTC 2010
Mark Andrews writes:
>
> In message <20100316234500.GA99617 at rwpc12.mby.riverwillow.net.au>, John Marsh
> al
> l writes:
> > On Wed, 17 Mar 2010, 09:03 +1100, Mark Andrews wrote:
> > > In message <slrnhpummo.2ter.john at rwpc12.mby.riverwillow.net.au>, John Mar
> sh
> > all
> > > 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 th
> e
> > > 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
>
> It should work. You don't have any other trusted-keys configured?
>
> 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.
>
> You should get something like this. Note "ad" is set in flags so this
> has passed validation using dlv.isc.org as the trust anchor.
>
> ; <<>> DiG 9.7.0 <<>> +dnssec ds 168.192.in-addr.arpa
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12909
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;168.192.in-addr.arpa. IN DS
>
> ;; AUTHORITY SECTION:
> 168.192.in-addr.arpa. 7434 IN RRSIG NSEC 5 4 10800 20100326192205 2
> 0100316192205 44093 192.in-addr.arpa. MhwZmez+ZUdVRFKyhzlKjiyj08rbs2gjxpCV/ya
> cJDjXthZoDtYtq6Ml MUsr/Ac4qbnjIOjGcfr3QHndDblco/GFGDXgscypspyoJ2yRl+i8n+p4 Vp
> 4nnpVkwaQObtQRZQWSOB2sqAzmGdiYqEnAK3rUj6nufzsBJOrzYjvX bzQ=
> 168.192.in-addr.arpa. 7434 IN NSEC 0.169.192.in-addr.arpa. NS RRSI
> G NSEC
> 192.in-addr.arpa. 7434 IN SOA chia.arin.net. dns-ops.arin.net
> . 2010031617 1800 900 691200 10800
> 192.in-addr.arpa. 7434 IN RRSIG SOA 5 3 86400 20100326192205 20
> 100316192205 44093 192.in-addr.arpa. PsLYw1RyLT2xUm41c78zq89219xxrm1WI0QSIrtn
> akHsWkqBsXn9DXG4 v2KbrjdCJglIVHEcJhrZ/GBNsq0ZIXT/GeskMRy/EfHFi8yVwGx/FCs5 H1F
> UtYs+1DOjeGQnv2UOiQfYMxp1yyxEHah9zzV6QqYpoCUVL7J3E025 eZc=
>
> ;; Query time: 2 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Wed Mar 17 10:56:12 2010
> ;; MSG SIZE rcvd: 502
>
> If it doesn't work I would ask for NS 192.in-addr.arpa, then DNSKEY
> 192.in-addr.arpa, then DLV 192.in-addr.arpa.dlv.isc.org, then DNSKEY
> dlv.isc.org until you find the break point.
>
> Also ask the same queries from a guest address.
>
> Can you turn on query logging also while testing. The queries from the guest
> view to the external view should have DO set which will be logged as "D".
s/external/internal/
>
> Something like this
>
> 17-Mar-2010 10:56:12.263 client 127.0.0.1#61281: view default: query: 168.192
> .in-addr.arpa IN DS +ED (127.0.0.1)
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users
mailing list