DNSSEC Validating Resolver and Views

[Mark Andrews]

In message <20100316234500.GA99617 at rwpc12.mby.riverwillow.net.au>, John Marshal
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 Marsh
> 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 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

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 20100316192205 44093 192.in-addr.arpa. MhwZmez+ZUdVRFKyhzlKjiyj08rbs2gjxpCV/yacJDjXthZoDtYtq6Ml MUsr/Ac4qbnjIOjGcfr3QHndDblco/GFGDXgscypspyoJ2yRl+i8n+p4 Vp4nnpVkwaQObtQRZQWSOB2sqAzmGdiYqEnAK3rUj6nufzsBJOrzYjvX bzQ=
168.192.in-addr.arpa.	7434	IN	NSEC	0.169.192.in-addr.arpa. NS RRSIG 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 20100316192205 44093 192.in-addr.arpa. PsLYw1RyLT2xUm41c78zq89219xxrm1WI0QSIrtnakHsWkqBsXn9DXG4 v2KbrjdCJglIVHEcJhrZ/GBNsq0ZIXT/GeskMRy/EfHFi8yVwGx/FCs5 H1FUtYs+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".

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