> On Jul 8, 2018, at 5:28 PM, Olafur Gudmundsson <o...@ogud.com> wrote:
> 
> 
> +1 
> I spent lots of time earlier this century along with Johan Ihren trying to 
> figure out how to 
> secure the transfer of a particular zone (the root) to any resolver. 
> The only sane way is to not transfer the zone over AXFR as any intermediary 
> can mess with the zone contents mostly in the case of “glue” records,
> thus transferring the zone over HTTPS or RSYNC with a PGP signature over the 
> zone file is the only viable solution going forward. 

I respectfully disagree. 

I dislike PGP (and S/MIME) for a couple of reasons.  For one, I think it limits 
the use cases to non-AXFR.  You would have to either keep the original file 
in-tact (not just ordering, but character-per-character) if to be 
redistributed, or you would have to define a sorting for the data.  Any 
reformatting of the data (whitespace etc) invalidates it.  Additionally, you'd 
have to choose between detached signatures (which I think are a bad idea) or 
use a PGP attached signature format, in which case you are no longer 
distributing a file that could be directly loaded into a name server. 

Regarding HTTPS/RSYNC, that would be irrelevant.  If the data is secured then 
the transport doesn't matter at all.


>  
> 
> Historical background: SIG(AXFR) was rejected because it required putting the 
> zone into canonical order and calculating the signature, 

Thanks for that.  This little tidbit was lost in the process of editing those 
RFCs.

> in the case of dynamic update this is a real expensive operation, thus we got 
> rid of it.
> 

I agree that dynamic updates complicate zone digests.  It could be made to work 
without sorting the whole zone, but some sorting would be required.  But in 
general I don't think the complexity of digests for dynamic zones is worth it.  

DW



Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to