Mark,
I must be opaque; I don't see how to make this approach work in any
reasonable way.
I tried this:
(DLV is enabled, and my external keys for example.com are there.)
view "r-internal" in {
match-clients { !any_external; all_internal; };
match-recursive-only yes;
transfer-source 192.168.self;
query-source address 192.168.self; // This should make resolution match
"internal"
recursion yes;
allow-recursion { all_internal; };
allow-query-cache { all_internal; };
include "internal_trusted_keys.conf"; // contains trusted-keys {}; for
the internal zone apexes
// example.net,
10.in-addr.arpa, 168.192.in-addr.arpa, etc
};
view "internal" in {
(as before)
key-directory "/xx../internal-keys";
match-clients { !any_external; all_internal; };
zone "example.net" {
auto-dnssec maintain;
type master;
...
};
zone "168.192.IN-ADDR.ARPA" in {
auto-dnssec maintain;
type master;
...
};
zone "xx.example.net" in {...}
zone "xx.168.192.IN-ADDR.ARPA" in {...}
}
// This has to do with interfaces that have internal addresses, but
// see the DNS as if they were outside. Management tools...
view "r-external" in {
match-clients { any_external; };
match-recursive-only yes;
transfer-source 192.168.self-x;
query-source address 192.168.self-x;
recursion yes;
allow-recursion { any_external; };
allow-query-cache { any_external; };
// external trust comes thru the DNS (dlv)
};
view "external" in {
...
}
The number of active zones reported by rndc status doubled from 56 to 90!
I expected the r-internal view to see that it was serving no zones & to
recursively resolve all the client requests with RR=0. Then the internal
view would catch them. But that seems to be wrong.
I did get AD set on the first few queries to example.net. But after a while
I started seeing SRVFAILs and claims that no trusted key matched rrsets.
Once I started querying the in-addr.arpa zone, things definitely fell apart.
It seems that the resolver was going outside - in fact, I saw trust chain
broken messages in the logs, where the address of the server was one of the
1918 blackhole servers and the query was to an internal 1918 address's PTR
record in a zone of the interal view. I also got these for example.net...
So it looks like the new (r-internal) view is starting at the root when it
resolves -- ignoring what it has data for locally. It sorta works for
example.net names because it happens that the internal and external views
use the same (nsx.example.net) names for their nameservers - but of course
the addresses are different! And NAT gets in the way. in-addr.arpa will
work for non-1918 addresses - mostly. But for private addresses, this won't
work at all...
It's all logical - but not productive. Even if the scheme works, it's
certainly going to put a lot of redundant data into memory. (Which is
limited on my embedded servers.)
I still think that BIND should look at RD on queries that it resolves from
an authoritative zone, and if set it should validate from the trust root to
the key it used to sign the zone. I can be persuaded that there's not much
point in actually verifying the signatures on the data in the response -
authoritative does mean that the file can be trusted about as much as that
BIND isn't lying about having validated...
Other ideas?
-----Original Message-----
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Thursday, September 09, 2010 22:06
To: Phil Mayers
Cc: bind-us...@isc.org
Subject: Re: DNSSEC, views & trusted keys...
In message <4c891404.3000...@imperial.ac.uk>, Phil Mayers writes:
> On 09/09/2010 03:45 PM, Timothe Litt wrote:
>
> >
> > There is other advice in the ARM that says to put 'your
> > organization's public keys in the trusted-keys list'. That doesn't
> > help - and in fact, confuses me even more since example.net has TWO
> > different public keys - one for each view. And trusted-keys is a global
server option...
> >
> > I must be missing something.
>
> I don't think so. Currently AFAICT bind will not set AD on
> authoritative zones, with any combination of options.
> _______________________________________________
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
Add a match-recursion-only view;
view secure {
match-clients { internal; };
match-recursion-only yes;
recursion yes;
};
view internal {
match-clients { internal; };
recursion no;
};
view external {
match-clients { !internal; any };
recursion no;
};
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
