Comment by Anunayj | Hacker News Reader

Comment by Anunayj | Hacker News Reader

I looked into GNS a little while ago and what I understood about how it works is:

1. I runs on top of GNUnet, which is a huge DHT that can be used for any purpose you like.

2. So GNS aims to replace DNS with a newer "modern" protocol, it is not a alternative root zone (like Handshake or such), nor does it decentralize the root zone, it just decentralizes "DNS".

3. How it is supposed to work is, instead of OS bootstrapping using root servers, they are preloaded with a root zone public key (possibly belonging to ICANN) or a list of TLDs (with corresponding owner public keys). Then the key owner can publish zones signed with the corresponding keys on the DHT, which recursively contains keys for child subdomains. It's like if torrent and DNSSEC had a baby.

4. To lookup a domain, you do a request with (tld, pubkey) and verify the response, do this recursively for each label until you have the record you want.

5. The problems with DNS it solves is: censorship (DNS is very easy to intercept and censor), query privacy (I don't know how this works, they don't seem to use onion routing or something), and secure resolution.

One thing to note here is development on GNS started in the 2001s, this was before DNSSEC and DoT/DoH were a thing, and most of the DNS was unsecured (which albeit even is today), and this could have been a completely viable approach.

I couldn’t find any contact info for you, but if you’d like to do a paid write up on GNS for nslookup.io, please contact me :)

Ha, thanks, however I do not think I know enough about GNS to be able to do a good writeup on it. I tried figuring GNS out few months ago (in an attempt to use Handshake for the bootstrapping root zone), but had trouble running their tooling and promptly gave up, and that's where the research stopped.

However there are a lot of great people on their mailing list which I'd say probably qualify a lot hetter than me.

I do plan to play around with soon however, and would probably make a public writeup, I'll send a link if I do :)

I was under the impression that DNSSEC is vulnerable to downgrade attacks. Is this still the case?

DNSSEC has support for denial of existence (NSEC/NSEC3) proofs, which means resolvers may require the resolver to provide them. This means you can't just MITM a DS record away. However practically most people dont use locally DNSSEC verifying resolvers, instead relying on upstream resolvers to do the job for them, which can be easily manipulated by your ISP.

Aside from that they bloat the size of responses a lot. However if you can sign DNSSEC on the go, you can use Cloudflare's black lies approach and have small enough DNS responses. [1]

1. https://blog.cloudflare.com/black-lies/

To put this in a bit of context, a regular NSEC3 is 1kb of data. Black lies are 350b. The average website is 1600kb. Cloudflare's black lies seems more to target the computational work on cloudflare's part, since a unique lookup at cloudflare require both an expensive database search and a computational expensive signing of the answer.

Cloudflare also outlines the following reason in the linked blog post:

> "The reason this matters so much is that the maximum size of an unsigned UDP packet is typically 512 octets. DNSSEC requires support for at least 1220 octets long messages over UDP, but above that limit, the client may need to upgrade to DNS over TCP. A good practice is to keep enough headroom in order to keep response sizes below fragmentation threshold during zone signing key rollover periods."

Reply on news.ycombinator.com