It is a little difficult to figure out what you are trying to say when the bulk of your comment is "invoke other people's words." Initially it seems that you are a proponent of DNSCurve but you directed my attention to a link that highlights a fault of DNSSEC and DNSCurve. You linked to a page[^1] pointing out that:

  > Libya(!) controls .ly. If DANE had been successful a few years
  > ago, Ghaddafi's government would have controlled bit.ly's certs.

Yes this is a problem for DNSSEC but it is also a problem for DNSCurve. Let's refer to one of djb's slides[^2] and substitute bit.ly for ubuntu.com:

  > How does DNSCurve client retrieve server’s public key?

  > DNS architecture: DNS client learns IP address of .bit.ly DNS
  > server from .ly DNS server.

  > The .ly server says: “The bit.ly DNS server is named petard and
  > has IP address 666.1.0.3.”

  > The name petard was selected by the bit.ly admin and given to .ly.

  > To announce his DNSCurve server’s public key, the bit.ly admin
  > changes the name petard to an encoding of the public key.

  > The DNSCurve client sees the public key, begins cryptographically
  > protecting communication with that server.

It seems that the Gaddafi problem is bad for DNSSEC and DNSCurve. The zone pinning via DLV in dfc's fuster clucked DNS (dfcDNS) neutralizes the Gaddafi problem at the cost of an absolute ops nightmare. It is worth noting that dfcDNS would pick a better name for the nightmare distribution service than itar.iana.org. Why someone thought it was a good idea to remind people of the cryptowars is beyond me. Maybe ITAR was a bad joke by someone at IANA?

[^1]: I recognize the author, but that is irrelevant. In fact I am not sure that the author would want to bring up this problem in the context of this discussion.

[^2]: High-speed cryptography and DNSCurve, pg 26-27. http://cr.yp.to/talks/2009.06.27/slides.pdf