[dns-operations] cool idea regarding root zone inviolability

[Paul Vixie]

> Mark Andrews <mailto:marka at isc.org>
> Thursday, November 27, 2014 7:22 PM
>> if your master server sends you a final (matching) SOA not having
>> stuffed its end of the tcp session with all the right records in
>> between, or if your TCP is allowing end-to-end badness without its CRC32
>> detecting same at the tcp segment level, then you have bigger worries.
>
> Given named does sanity checks when apply ixfr deltas and they
> actually have been known to trigger, knowing that you have a complete
> zone after applying a ixfr would be a good thing.
> ...
> ... Whether is is TSIG or these records you are using a
> cryptographic hash + a key to ensure that all the glue is correct
> and you are trusting the generator of that hash and signer to be
> doing the correct thing.  And the key is tied back to a trust anchor
> directly or indirectly.

is there some reason why an updated sig(0) is not a solution to this?
>
>>> As to whether you iterate or not also depends on the trust anchors
>>> installed, whether the keys are RFC 5011 managed or similar. Having
>>> a managed trust anchor for every zone isn't a be deal.
>> adding RFC 5011 support to a non-mixed-mode (authority only) server
>> would be a very big deal. so, that's an area of strong disagreement if
>> we discuss it further.
>
> and the whole trigger for this discussion was a mixed mode server with
> a local copy of the root zone.

is there a specification for how mixed-mode servers will validate data
they don't fetch? as in, you really are making a recommendation for
zone-level validation that would then permit zone-local data to be used
in forming responses to recursive queries in a mixed-mode server? i'd
like to hear the details of that, because while DNSSEC talks about how
to validate data you receive in queries, it does not talk about how to
validate data you've received in zone transfers. i argue that it's not a
trivial exercise, even if an updated sig(0) could be used to validate
zone transfers. (i remember more than olafur claims to, concerning why
we don't have zone-level signatures today. it's related to why glue is
not signed and does not need to be signed, and it comes from security
theory not dns theory.)
>
> As for adding RFC 5011 support for the zones it serves, a authorative
> server has all the data it needs to do that as part of its normal
> roll of being a authoritative server.  It's only a matter or reading
> what it is serving to others.

i don't think this is true. rfc 5011 assumes that you're starting with a
known-good TA and that you'll use this to validate subsequent changes to
that TA. those starting conditions are not in effect on any
authoritative-only server i have administered.

-- 
Paul Vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141127/7a67d069/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141127/7a67d069/attachment.jpg>