[dns-operations] cool idea regarding root zone inviolability

[Paul Vixie]

summary: no worries, this isn't what i thought it was. details below.

> Warren Kumari <mailto:warren at kumari.net>
> Thursday, November 27, 2014 2:20 PM
>
> This allows a slave (or anyone else who wants to validate a zone, e.g
> a master loading from disk) to know that they have a full and correct
> zone. This covers things like accidental zone truncation (which has
> bitten some folk),

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.

> zone file corruption, etc. if someone hands me a zone somehow (e.g
> AXFR) and asks me to serve it I'd like a way to make sure it hasn't
> been accidentally (or intentionally) changed.

for a dnssec signed zone the only way to do that is to zone-walk and
validate. belt-and-suspenders isn't a good model for axfr/ixfr, because
complexity, and because the zone signature would have to be
incrementally maleable and so not one-way or crypto-authentic, because
update.

> I'm assuming I'd want my name server software to refuse to load the
> zone and try retransfer, throw an error, or similar.
> The signature could be (and the way I'd envisioned it) DNSSEC, so up
> to a TA, or a manually configured key specific to the zone.

if this is proposed and adopted, my discussion input will be along the
lines of "no authority server can every be required to query for
anything as part of its operations". just letting you know where "DNSSEC
... signature" leads to.

importantly, you're envisioning this as a new way to fail, but not a new
criteria for success. that is, this new signature mechanism is to you a
reason to reject an AXFR or IXFR, which would then lead to zone timeout
and SERVFAIL unless corrected. that's not a problem. i was worried that
this would be used in some way to permit/deny zone data to be used by a
mixed-mode server in response to RD=1 queries. that would be a larger
kettle of different fish.

furthermore:

> Mark Andrews
> Thursday, November 27, 2014 2:45 PM
>
> Just having a cryptographically strong zone self consistancy check
> is a big win with IXFR. If that fails you AXFR the zone and try
> again.

if you're trying to make a case for public key TSIG, i'd agree with you,
and say, SIG(0) [RFC 2931]. i'd support an rfc 2931-bis effort, as a
reviewer and as a contributor.

> For the root zone you don't need a iterative validator as you would
> have the root as a trust anchor and in general a authoritative
> server needs a interative resolver for NOTIFY.

if you're arguing that NOTIFY should support DNSSEC by including
RRSIG(SOA), i'd agree. but right now there is no TA on root zone slaves,
they never query for anything, they never validate anything, they don't
speak RFC 5011. and that's a deliberate design decision, not an accident
or oversight.

> 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.

vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141127/61dc1b0e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1223 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141127/61dc1b0e/attachment.jpg>