[dns-operations] cool idea regarding root zone inviolability

[Paul Vixie]

> Mark Andrews <mailto:marka at isc.org>
> Friday, November 28, 2014 12:57 AM
> In message <54781F2A.4050009 at redbarn.org>, Paul Vixie writes:
>>> 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?
>
> SIG(0) is hop by hop. 

i was responding to your examples. if you want end to end zone
signatures so that a tertiary server can know that the secondary isn't
lying to it, then of course SIG(0) (and TSIG) aren't useful.

>> 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.
>
> Well the early DNSSEC RFC did have the concept of validating the
> zone transfer.

i think it's gone from current RFC's for a very good reason.

> As for local zone data being returned to recursive
> queries the nameserver is broken if it doesn't do so.

in this scenario, it's possible that noone is validating the signatures
(or the NSEC's.) this sounds unspecified. can you explain (with
reference to 4034 or 4035, or later work) what you mean by "broken"? i
do not know that the current DNSSEC spec explains what a mixed-mode
server should do about validation. if you do, i hope you will point it out.

>>> 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.
>
> So what?  Do you think a adminstrator is incapable of adding a
> trusted key along with the masters to transfer from when configuring
> a slave?
>
> zone "." {
> 	type slave;
> 	managed-trusted-key ....;
> 	.....
> };

i thought you said "has all the data it needs", not "it could be given
all the data it needs".let's talk about how the transition to
"managed-trusted-key" would work.

since we're talking about RFC 5011 here, which covers any zone's TA not
just the root zone's TA, the initial key would have to either be entered
as configuration data, or fetched and validated against an ancestor TA.
in the later case, the authority server would be acting as a validating
stub resolver for the purpose of fetching and validating its way
down-chain from the TA it has (presumably the root pubkey) to the TA
it's establishing.

i don't view those as trivial steps, but i agree with what i think you
said, which was that if we could maintain each secondary zone's TA
reliably, and we could validate every AXFR and IXFR we receive, then we
could mix local authority data into RD=1 responses in a mixed mode
server. i fear that this would make DNSSEC more fragile for the public
internet, but it sounds like it could at least be made to work in the lab.

-- 
Paul Vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141128/9edd22e2/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/20141128/9edd22e2/attachment.jpg>