[dns-operations] cool idea regarding root zone inviolability

[Paul Vixie]

> Doug Barton <mailto:dougb at dougbarton.us>
> Sunday, November 30, 2014 1:21 PM
> ...
>
> We still need a way to verify the entire contents of the zone however.
> This goes beyond just transfers, it would be nice to be able to verify
> that a zone downloaded using a method other than transfers is both
> accurate and complete.

why? (your use case is not obvious from what you've written.) are you
trying to ensure that errors that creep by TCP's error checking or that
result from silent sending-side failures where both the starting and
ending SOA are present but the middle is corrupt? or are you trying to
ensure that a tertiary server can't be lied to by its secondary server?
>
> I'm sensitive to your expectation that non-transfer methods should
> provide their own security, and your argument that every new line of
> code adds more fragility. However I do see the appeal of a
> standardized way of demonstrating that a given zone is what it should be.

i'm not going to say whether i "see appeal". rather, i'll ask you, what
feature you want to add, how will it make the domain name system better
in some measurable way like performance, resilience, uptime, or
correctness, and why is it better than at least one and preferably two
alternatives you can think of, and also enough better than the status
quo to be worth the cost of its additional systemic complexity? in other
words can you do some engineering economics here rather than asserting
and then periodically re-asserting that some feature "would be nice" or
that you "see appeal"?

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