[dns-operations] cool idea regarding root zone inviolability

[George Michaelson]

If somebody said to me:

 "lets have a canonicalize() function which makes a deterministic
byte-stream of the state of a zone, and then calculate a checksum over it"

I'd struggle to say that was a bad idea.

If you have a transform which takes updates in any kind, AXFR or IXFR and
can then re-canonicalize and test the zone state against a known published
record of the zone state, whats the downside?

I understand there is an element of redundency in the scheme, against what
DNSSEC can alteady do at the RR level, but I think from whats been said,
and what is being said about schemes to provide for re-distribution of the
root, this makes a lot of sense.

The history only informs the present, it doesn't have to determine it. The
statement about 'learning from history, doomed to repeat it' is not meant
to say you cannot re-try things previously considered and rejected. It
means you need to be aware of them.

-G

On 28 November 2014 at 07:18, Edward Lewis <edward.lewis at icann.org> wrote:

>  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> wrote:
>>
>>
>>
>>   <postbox-contact.jpg>
>>  Warren Kumari
>> 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
>> 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/17904545/attachment.html>