[dns-operations] cool idea regarding root zone inviolability

[Mark Andrews]

In message <5477DCC2.8050802 at redbarn.org>, Paul Vixie writes:
> 
> 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.

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.

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

You can do increment signatures on ranges of names for big zones.
This reduces the amount of data that has to be process on a update.
Think NSEC with a hash rather than a bitmap. One every hundred /
thousands names or so and a final signature over the hash of these.

This is similar to how TSIG works on multiple messages.

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

And the roots use TSIG to validate that they are talking to the
server they think they are when performing a zone transfer.  That
doesn't preclude having the data added to the zone so others
transfering from the root servers can verify that the contents are
complete because validating all the validatable rrsets doesn't do
the job.  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.

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

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.

> vixie
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org