P2P DNS | Hacker News Reader

P2P DNS

github.com

69 pointsmikemoka21 comments

Open articleView on HN

Some historical context from 2010: http://arstechnica.com/tech-policy/2010/11/fed-up-with-icann...

Codebase has not seen significant recent activity.

So it predates Namecoin.

Decentralized naming is an interesting problem.

There are several problems with this design though:

1) Cheap, permanent domain squatting is possible

2) Legitimate domain owners can't recover from key loss

3) Onerous storage requirements for every node

> 2) Legitimate domain owners can't recover from key loss

That doesn't seem like an insurmountable obstacle to me. You could devise a scheme where there's the option of a majority of multiple offline backup keys can be used to invalidate and replace the current online key.

Then it's up to the legitimate owner whether the domain is valuable enough to do that kind of key management and backup.

This is a problem of interest to me because I've just started working on a P2P project in Erlang that would benefit a lot from having DNS that isn't as easily squattable. Do you know of any solutions to that, or attempted solutions?

* Namecoin https://namecoin.info/

* cjdns https://github.com/cjdelisle/cjdns

Cjdns is a p2p IPv6 network and doesn't do DNS -- I see how the name can be confusing though :)

(I'm one of the developers)

Thanks for clarifying that - I remember hearing about the project a while ago. I looked at the most recent documentation and it did seem more like a P2P network, although I just assumed there was also some concept of decentralized DNS within the project as well.

Not that I'm criticising the work, but DNS is already P2P; it is -by design- a federated system. However, -as Mononofu's project's README notes- it is not highly tamper resistant. [0]

I know that one could see this as a petty quibble, but just because something isn't tamper resistant doesn't mean it's not a P2P system. :)

[0] I make liberal use of this lack of tamper resistance to provide various levels of ad and tracking blocking for all systems on my LAN. BIND's RPZs (and mechanisms similar to them) are pretty great.

What about DNSSEC? Does this not add tamper proofing?

I'm not going to talk about DNSSEC [0], but I will make the argument that DNSSEC isn't DNS, but rather a DNS extension.

[0] Mostly because being able to intelligently talk about it is currently way above my pay grade.

That’s slightly like arguing that TCP is not IP but an extension of IP.

It does, to a lesser or greater extent. The problem is that the root node/TLD provides trust for everything below it. This means that like HTTPS trust is also centralised (but also federated, which is even worse.)

However I'm not an expert in DNSSEC so there could be nuances that I'm missing

Just yesterday I was reading and trying to setup dnscrypt. I don't understand how it differs with DNSSEC yet (if it does).

dnscrypt protects the traffic between you and your resolver.

DNSSEC makes sure that the records presented by your domain have not been tampered with (though in fact it only makes sure that the records have not been tampered with by anyone but the registry or the government the registry is controlled by)

I don't think DNS is P2P in the sense that all actors in the system are homogenous and equipotent. Although modern P2P systems have supernodes, they usually serve the purpose of rendezvous, and not typical operationl

DNS is a more of a hierarchical system, where the roots are at the center, and they delegate trust and responsibility as necessary.

This is a more accurate description IMO. However DNS does not have to be that way. Before DNS there used to be file sharing of all the data via a single file in the simple "HOSTS file" format. Then there was a feature in DNS for sharing all the data of each nameserver, in a "zone file" format. With network bandwidth as it is today, sharing of data in bulk could be quite useful to make DNS more peer-to-peer like. People still share data, e.g., block lists. But, practically speaking, everyone running a nameserver connected to the public internet disables axfr.

Also, in my view peer-to-peer supernodes do not monitor or forward all data, they only maintain address information of the peers (rendezvous as you say). DNS, as it is implemented on the public internet, is ripe with passive monitoring as all data flows through centralised points in the tree. Leaves, at the network's edge, are expected to be "dumb", needing to make hundreds single requests for the same information, 365 days per year, even when the majority of it is relatively static.

Every query and response packet containing a seemingly useless "Query" field that never varies from "1". There's no pipelining (when using TCP) or packets containing more than one query.

From what I understand there was interest in so-called "P2P DNS" in reaction to various incidents of censorship via the centralised points in the tree. If the leaves were truly connected as "peers", and sharing the database data directly "peer to peer", then we might have better protections against censorship.

Incidentally, "DNSSEC", as advertised, appears to anticipate centralisation and usage as a CA-like system where peers at the network edge are not only dumb but incapable or verifying messages themselves without involvement of third parties.

In contrast, encrypting DNS packets requires no third party assistance. It can be done by peers all by themselves. A client can encrypt queries and a nameserver can encrypt replies. Well suited to peer-to-peer style usage of DNS. Bulk DNS data can be rysnc'd between peers over SSH, or perhaps mrysnc'd among groups of peers.

There is "DNS" as implemented so far and then there is "what's possible" using DNS. Peer to peer sharing of the data is hardly far-fetched. But it does not yet seem to have caught on outside of small groups doing passive monitoring, blocking and other manipulation.

> I don't think DNS is P2P in the sense that all actors in the system are homogenous and equipotent. ... DNS is a more of a hierarchical system, where the roots are at the center, and they delegate trust and responsibility as necessary.

So, on the one hand I see where you're coming from and your comments are totally valid.

On the other hand, there is no actual centralized authority to which one must appeal to to get data into DNS. Want to have porn site blocking? OpenDNS has you covered! [0] Want to attach Namecoin's .bit TLD into your DNS tree? That's available on my LAN and -when last I checked- through a few Internet-accessible DNS servers. Ad/malvertizing blocking for every client attached to your network? Again, just point to (or stand up) a DNS server that's appropriately configured.

In DNS, the "edges" have just as much power as the nodes in the "center", but their sphere of influence is often much smaller.

[0] https://support.opendns.com/entries/46060260-FamilyShield-Ro...

So how do I register foobar.com in such a way that everyone using DNS can access it without paying an organisation registered (directly or indirectly) with ICANN?

Filtering can be done - certain very-small-scale extensions can be done - and local DNS networks can be done - but if you take the goal of DNS-as-a-global-service as "provide globally unique, globally available name resolution", it very much is centralised.

A federated system does not necessarily imply that it is a P2P system. A P2P system, however, is definitely federated.

The link to the .mu site is, slightly ironically, not resolving. Anyone got a different URL/

Reply on news.ycombinator.com