[dns-wg] Just another lookaside zone

* Alexander Gall wrote:
> Why do you include DLV Records for Zones that are below a secure entry
> point (those you call "chained")?  They will never be used unless the
> parent zones become insecure.

My tests show, that some resolvers only go one step back to the origin to
check the lookaside data. So if you query for host.sub.do.main, these
resolvers do only query for host.sub.do.main.trust.an.chor and
sub.do.main.trust.an.chor.

I have to dig this problem much deeper, to see iff this is a configuration
or software issue.

In order to keep the lookaside zone useful, I included the subzones.

OTOH it's possible, that the parent zone becomes unsigned. In this case the
sub zones become new SEPs. If would be the only reason, I'll move the DLV
entries to TXT entries in order to keep them as a backup.

Furthermore, I regulary check the validity of the DNSKEYs with the DS parent
entries to detect errors in chaining (i.e. after rollover errors).

> What exactly does "DNSKEY unchecked, DSSET given" mean?  I suppose
> that you have received the DSSET by the maintainer of the zone through
> an authenticated channel (if not, you shouldn't add the DLV record at
> all).  Why doesn't that make it a secure entry point and why should
> you "check" the DNSKEY?

This entry means: Somebody added a zone. This process generates the DS entry
from the queried DNSKEY. If possible the DNSKEY is queried using DNSSEC
authenication, so you can't add a sub zone of a signed parent zone without
correct chaining. I should add the validation step for the person, who adds
this zone, of course. Thanks for this suggestion.

The daily maintainance check "drops" all entries an requeries them using the
old lookaside zone. Only authenicated responses are used to rebuild the zone.
In this step the parent chaining is checked, too. And sub zones are added, if
possible using AXFR or (on dlv.verisignlabs.com) by NSEC traversing.

For new SEPs there exists currently no trustly off-band validation. Because
everybody can set up a signed zone, any attacker can sign any zone unter his
control and provide any typical validation. I only check, that the real zone
is really signed. I do not trust other name servers than the ICANN root (and
myself).

Of course it is possible to attack to my infrastructure in order to fool my
name servers.

> Why do you include DLV records for zones that you know are broken?

The check is done from my point of view. I do not assume permanent access to
every zone in the internet. Some broken zones might be truly operational in
other networks. I assume that ct.nl and fnl.nl are operational on nlnetlabs.
I also assume that demo.netsec.tislabs.com is operational on tislabs.

It might be helpful for operators to have an outside view to this zone.
There might be an TCP/53 block between AS15725 and the authorized name
servers.

The name servers might be offline or the zone is expired on the secondaries.
There even might be an routing loop like this one:
traceroute to dnssec1.jprs.co.jp (2001:200:132::2)
	 from 2001:4bd8:0:666:280:adff:fe1e:79ba
...huge IPv6 delay on C&W backbone in USA...
12  pc8.otemachi.wide.ad.jp (2001:200:0:4401::11)  299.067 ms
13  otemachi.dnslab.jp 	    (2001:200:132:4::2)    299.889 ms
14  fuundo.dnslab.jp 	    (2001:200:132:5::1)    301.206 ms
15  otemachi.dnslab.jp 	    (2001:200:132:4::2)    301.584 ms

> Obviously, this classification has no meaning for a resolver that does
> lookaside validation.  All DLV Records in this zone must have been
> authenticated by you (and we all trust you, of course :-), or the
> scheme is useless.

Exactly. At the moment there is a large gap between trusting the unknown
and stay unusable because there are no entries at all. My way might be to
risky for you. That's ok. Any suggestion is welcome.

> Or am I missing the point and this zone should be used as a repository
> for secure entry points from which one creates local trusted keys
> rather than use it as a true lookaside zone?

It serves both issues, but the main subject it to generate trust.

> Personally, I have come to the conclusion that I don't like it at all
> that my cache considers the entire DNS bogus when the DLV zone becomes
> unreachable or corrupted.

You are free to set up a secondary. You will get notifies automatically. Of
course invalid signatures are really bad. Because I switched almost all name
server I admin to this zone, such a mistake will be noticed very quickly ;-)

> I'll stick to my locally configured trusted
> keys and wait for the root to be signed.

Of course. Do you configure the trusted keys to every of your name servers?
How do to keep them in sync?

You you really believe to see a signed root this life?

> BTW, there are some nasty bugs in the DLV implementation in BIND up to
> 9.3.2 (e.g. see what happens when you corrupt the trusted key of your
> DLV zone, but don't do it on your production server :-)  I've been
> told that it has been improved a lot for 9.4 and these changes will be
> backported to 9.3.3.

Thanx. The problems with the Windows DNS server software are much harder to
solve. Is there any rewrite out there? Or do we have to write one yourself?

> In case you still need secondaries, I can offer two in
> Switzerland with excellent IPv6 connectivity :-)

Thank you. Currently I prefer to complain using your service contracts.