FWIW, this message was spurred by this comic strip [yes, today as I write]:
http://dilbert.com/strip/2018-08-09.
"Will the time taken to generate and verify this record add to the security of
a zone transfer?"
I understand that there is no protection for cut point or glue records now, nor
any guarantee for the occluded records and there's a desire to cover them. It
would be great to have the whole zone (as a data structure) be subject to
source integrity and authenticity protections.
But there are already mechanisms for this at the data set level. (This is a
"belts and suspenders" style argument.) What if -err- when, in a zone's
distribution, the glue records are either forged or simply fat-fingered?
That's covered, in a way that is more efficient - in a lazy evaluation way.
Mangled glue never referenced needs not be checked, when it is needed there's
backup in the authoritative version. If all else fails, DNSSEC will flag
whatever response as suspect.
I don't know if this is documented, but at one time, prototype authoritative
servers would validate all the signatures in a zone upon load (before setting
the AD bit). This was discarded as it made zone loading (and reloading) take
f-o-r-e-v-e-r. (I recall this mostly because I was on the losing end of the
argument.) Today, we assume the server can set the AD as it can trust what it
gets from disk or from AXFR {which had better be done with channel security!}.
One concern is what or who makes the decision to enable ZONEMD for a zone. We
are marching toward more automation in NOCs, so this will be a buried
parameter. What happens if a zone grows astronomically over time, in the
beginning the ZONEMD is on? (Similarly, zone have had to transition from NSEC
to NSEC3 with optout.) File this under "fear, uncertainty or doubt" but it
stems from how I see the operations of the DNS evolving.
In general, the proposal is more or less fine. I don't know if it is feasible
(speed of execution). I don't know that it adds to the safety of the system
(DNSSEC already protects at the data set level in the same manner this protects
at zone load time). I don't know if the added configuration knob is justified
by the benefit (forgotten settings, "trusted-keys"-mania ?).
And ... returning to the comic strip ... "Your plan is dumb because it reminds
me of something different that didn't work out." ;) "History repeats." And
today I am wearing a blue shirt (but it's a Knot DNS shirt!).
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
