[dns-operations] Implementation of negative trust anchors?

[Joe Abley]

On 2013-08-27, at 08:49, Antoin Verschuren <antoin.verschuren at sidn.nl> wrote:

> How about this solution:
> 
> A truly DNSSEC aware authoritative server should not publish a zone,
> not even the unsigned records, when validation fails for that zone.
> That way, if a DNSSEC signed zone is DNSSEC broken, it's also broken
> for a non-validating resolver, there is no competition issue, and the
> zone publisher should fix his zone to get it working at all.
> 
> Who will be the first DNS vendor implementing? :-)

That would help avoid some problems. It wouldn't help avoid all problems, though. The event horizon for end-user problems is extended based on cached records originally served from previous internally-correct zones, and bad interactions between successive, well-signed zones can still cause problems.

I seem to think actually that all the prominent public failures near the root of the namespace have not been due to zones that were signed incorrectly, but rather botched rollovers, parent DS mismatch, accidental use of an old key, etc.

I've long wished for a more general facility where upon successful [AI]XFR I could shell out to an arbitrary local executable and do whatever checks I wanted before signalling with exit status that "this zone is ok to serve". With a bit of state held on disk about previous zones you could include some of those temporal checks and perhaps catch a few more problems.


Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130827/f984df08/attachment.sig>