- 112comments
- 2comments
- 42comments
- 163comments
- 176comments
- 2comments
- —discuss
- 25comments
- 58comments
- —discuss
- 391comments
- 85comments
- 38comments
- 21comments
- 53comments
- 158comments
- 3comments
- 635comments
- 262comments
- 98comments
- 176comments
- 85comments
- 10comments
- 239comments
- 55comments
- 158comments
- —discuss
- 168comments
- 24comments
- 31comments
So, biggest question... how is this different from Namecoin [1], and how does it improve upon it? Both are in the same 'decentralized identity/DNS' space.
Also, from a cursory glance, how does this prevent spam? There seems to be no cost to register a new name. What prevents someone from taking every possible name?
[1] https://www.namecoin.org/
Or from the GNU naming system: https://www.gnunet.org/gns
It's more similar to Blockstack: https://blockstack.org
Well after reading this post the obvious difference is that namecoin exists and this is just a idea that the author is still trying to work out.
In this scheme, there is still a central registrar with full control over the TLD. For example to register a .com domain you would still go through verisign (and pay them). This proposal would just mean that verisign would provide a public, blockchain-verified history of their DNS zone file.
That's fundamentally different from namecoin which wants to cut the registrar (verisign, etc.) of the equation.
Seems somewhat similar to Certificate Transparency project, where issued certificates are recorded in a public (merkle tree) log.
Is this resistant to domains being taken down for "copyright" reasons, which has shown that one does not really own the domain and is at a whim of a registrar.
Old dns entries would be recorded in the ledger forever. You would just have to write a client that ignores revocations/reassignments/updates for a chosen domain.
But in principle the registrar can still do with its domain whatever it likes for any or no reason.
Well great, now could someone come up with DNS improved by Machine Learning trough Deep Convolutional Neural Networks? That's the only missing thing for a BS-Bingo on my card.
Is anyone more familiar with it able to discuss how the identity part of this compares and contrasts with DANE?
This seem to bring up the zone enumeration issue. Except for now, approaches like used in NSEC3 won't help at all.
"Private" DNS entries matter, when one wouldn't want to remember IPs (one'd rather remember "correct-horse-battery-staple.int.example.org"), but also wouldn't want to disclose the addresses used internally and aren't exposed to the end-users (because DDoS).
Will this scale to the pending explosion of DNS as IPv6 is deployed? The existing DNS infrastructure is already experiencing growing pains, especially wrt PTR records.
The site doesn't specify directly, but would the communication between Bob (the end-user) and Trent (the trusted entity) be encrypted? If not, why not?
It's always annoyed me how much of a mess DNS is when it comes to confidentiality. Why should my ISP or employer be able to deduce which sites I'm visiting by simply inspecting my UDP datagrams (filtering to port 53) and looking at the plaintext queries? Why was this thought to be a good idea?
In the wider scheme of things, there's far too much trust with many internet services/protocols. I like that NeoDNS provides a public key for the queried service - maybe with a scheme like this we can stop sending hostnames for SNI in plaintext as part of the TLS handshake too. We shouldn't accept these sorts of information leaks anymore, it's been demonstrated too many times in the past that sending things in plaintext is a bad idea.
(1) Your ISP and employer know which sites you're visting (modulo virtual hosting) by inspecting your IP packets and doing a reverse DNS lookup. It's the price you pay for someone routing your traffic: they have to know where to send it.
(You can use a proxy/VPN tunnel. Your ISP knows knows you're sending traffic to the proxy, and your proxy knows where you're sending traffic.)
(2) DNS encryption is certainly possible. DNSCurve and DNSCrypt are the ones I know of. But there's just not a lot of motivation. IP packets have an address on them already; the only additional thing DNS or SNI reveals is which of several (usually enumerable) hostnames they are interested at that IP. So...interesting, but generally not compelling.
You have a point, but as a webmaster there's surely no requirement for me to create a PTR record, right? As long as there's an A record somewhere, surely things will work? This is perhaps what you were getting at with "(modulo virtual hosting)" I guess (though to me that would suggest SNI-based certificate serving from one IP)?