[dns-operations] cool idea regarding root zone inviolability

[Edward Lewis]

After reading on…

I think the rationale of killing SIG(AXFR) was that DNSSEC is there to
protect the relying party and not the manager of the zone.  I.e., a relying
party only cared about the data it received pertinent to the query it
issued.  This made the building the chain of trust as efficiently as
possible paramount.  Forking into zone replication was a design distraction.

That’s not the reason SIG(AXFR) failed, that’s the reason we didn’t try
harder to accomplish it.  DNSSEC did not exist to make managing DNS
better[0] (I.e., protect against zone truncation), so taking time to do that
was hindering the primary purpose of answering questions with proof of
authenticity and integrity.

[0] Joke and snicker if you must.  Yes DNSSEC today makes running today’s
DNS harder, keep in mind that the state of the system in the 90’s was so bad
that it would not have survived with the major rewrites DNSSEC development
caused.  DNSSEC didn’t have a real good foundation to build upon.

On 11/27/14, 17:48, "Warren Kumari" <warren at kumari.net> wrote:

> 
> 
> On Thursday, November 27, 2014, Francisco Obispo <fobispo at uniregistry.link>
> wrote:
>> +1
>> 
>> And if someone is already serving the root zone, they can always modify the
>> server to return AA.
>> 
>> I'm also wondering about the use case.
> 
> See above - this has *nothing* to do with setting or not setting AA. This
> simply allows the entity serving a zone to confirm that they have a complete,
> uncorrupt, and untampered copy of the zone. Think of it as a cryptographic
> checksum if you like.
> Before serving a zone (as a master or slave) I'd like to know it is correct...
> 
> W
>  
>> 
>> Francisco Obispo
>> 
>> On Nov 27, 2014, at 1:55 PM, Paul Vixie <paul at redbarn.org
>> <javascript:_e(%7B%7D,'cvml','paul at redbarn.org');> > wrote:
>> 
>>> 
>>> 
>>>> <postbox-contact.jpg>
>>>> Warren Kumari <javascript:_e(%7B%7D,'cvml','warren at kumari.net');>
>>>> Thursday, November 27, 2014 1:11 PM
>>>> ... and Mark Andrews, Paul Hofmann, Paul Wouters, myself and a few others
>>>> (who I embarrassing enough have forgotten) are planning on writing a "zone
>>>> signature" draft (I have an initial version in an edit buffet). The 50,000
>>>> meter view is:
>>>> Sort all the records in canonical order (including glue)
>>>> Cryptographicly sign this
>>>> Stuff the signature in a record
>>>> 
>>>> This allows you to verify that you have the full and complete zone (.de...)
>>>> and that it didn't get corrupted in transfer.
>>>> This solves a different, but related issue.
>>> 
>>> would this draft change the setting of the AA bit on an secondary server's
>>> responses, or make it unwilling to answer under some conditions? right now
>>> there is no dependency, AA is always set. but if we're going to make it
>>> conditional, then it should be conditioned on the signatures matching all
>>> the way up-chain to a trust anchor, which would require an authority server
>>> to also contain a validator and be able to make iterative queries. so, i
>>> wonder about the use case for your draft.
>>> 
>>> -- 
>>> Paul Vixie
>>> _______________________________________________
>>> dns-operations mailing list
>>> dns-operations at lists.dns-oarc.net
>>> <javascript:_e(%7B%7D,'cvml','dns-operations at lists.dns-oarc.net');>
>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>> dns-jobs mailing list
>>> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad idea in
> the first place.
> This is like putting rabid weasels in your pants, and later expressing regret
> at having chosen those particular rabid weasels and that pair of pants.
>    ---maf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141128/375720d4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141128/375720d4/attachment.bin>