Hacker News Reader

Comment by jrockway | Hacker News Reader

If there’s one truly strange argument in DJB’s presentation, it’s on Page 39. Here, he complains that in DNSSEC, .org being signed doesn’t sign all the records underneath .org, like wikipedia.org.

I'm not sure this is an argument against DNSSEC, it's more of an argument against DNSSEC's marketing. The DNSSEC folks like to say that DNSSEC is deployed to .org. Well, that's technically true, but since no .org domains are signed themselves, this claim is useless. DNSSEC provides no real security currently.

I watched DJB's talk and I thought the first half was mostly for entertainment, rather than detailed discussion of the weaknesses of DNSSEC.

View on HN

I think Kaminsky is misleading when he says “Wikipedia.org is a delegation, an unsigned one at that” and “Wikipedia’s IP addresses are not actually hosted by the .org server.” The IP addresses of Wikipedia’s nameservers are actually hosted by the .org server in the form of glue records. In this particular case, at least, wikipedia.org is not just a delegation, so there would be some benefit from the .org servers signing that information.

(I know that glueless delegations are common, I even use them myself. But Wikipedia’s delegation is not glueless. DJB does not like them: http://cr.yp.to/djbdns/notes.html)

  ; <<>> DiG 9.6.0-APPLE-P2 <<>> @a0.org.afilias-nst.info. wikipedia.org. ns +norecurs
  ; (1 server found)
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51490
  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
  
  ;; QUESTION SECTION:
  ;wikipedia.org.			IN	NS
  
  ;; AUTHORITY SECTION:
  wikipedia.org.		86400	IN	NS	ns2.wikimedia.org.
  wikipedia.org.		86400	IN	NS	ns0.wikimedia.org.
  wikipedia.org.		86400	IN	NS	ns1.wikimedia.org.
  
  ;; ADDITIONAL SECTION:
  ns0.wikimedia.org.	86400	IN	A	208.80.152.130
  ns1.wikimedia.org.	86400	IN	A	208.80.152.142
  ns2.wikimedia.org.	86400	IN	A	91.198.174.4
  
  ;; Query time: 46 msec
  ;; SERVER: 199.19.56.1#53(199.19.56.1)
  ;; WHEN: Thu Jan  6 10:05:40 2011
  ;; MSG SIZE  rcvd: 143

If you'll notice, that's glue for ns0, ns1, and ns2. This information from the parent is just there to say "here's where to go to resolve information from the child".

It's not the actual IP addresses for all the child data, like www.wikimedia.org.

DJB's basically saying "how can you say .org is signed when not every child in .org is signed". No delegated solution could ever offer that feature. If DJBCurve doesn't support signed and unsigned children, it's a thoroughly irrelevant technology that should be laughed out of the room.

Bashing DNSSEC for supporting a basic reality of delegated trust is flat out unfair.

Here’s what I think DJB is saying: It’s the IP addresses for ns0, ns1, ns2, and it’s published by the .org servers. Why not sign that information, even if the Wikipedia folks haven’t implemented DNSSEC themselves? I don’t think he expects the .org servers to sign information not published by them.

Did you mean to say that "no" org domains are signed? As far as I understood it, some are, but the vast majority aren't?

I'm not an expert in this stuff, but I thought that getting "org" it's self signed was a massive achievement because it now means that domains beneath "org" can be signed?

If I do an A record lookup of "baddata-a.test.dnssec-tools.org" it returns NXDOMAIN on my system which supports DNSSEC, and 75.119.216.30 on my system which doesn't...

Yes, in order to validate the chain of trust the TLD must be signed but sibling 2LDs have nothing to do with whether a particular 2LD can be signed. If wikipedia.org wants to sign, they can do so, because their parent (.org) is signed, but it doesn't matter whether widgets.org is signed.

Reply on news.ycombinator.com