Please explain how DNSChain is "backwards compatible with traditional DNS"

[Ajedi32]

I noticed DNSChain's README states that it is "backwards compatible with traditional DNS". I find that to be an interesting detail, but I can't seem to find any more information on that in the documentation.

In what sense is DNSChain backwards compatible with traditional DNS? If I wanted to host a domain with DNSChain, would a significant percentage of users who know nothing about DNSChain and don't particularly care about it still be able to access my site?

[wemeetagain]

DNSChain is 'backwards-compatible' with DNS in the sense that it serves domain data from ICANN-allocated domain names (ie, traditional domains that everyone uses, like .com) as well as blockchain-allocated domain names. Using a DNSChain server as your default nameserver would allow you to resolve domains from both traditional domains, like .com, and blockchain-specific domains, like .bit. By having this backwards-compatibility, you can use DNSChain as your sole nameserver for all domain name requests.

In order to host a site using these blockchain-specific namespaces, like namecoin's .bit, you would need to register with the specific blockchain which controls that TLD. What DNSChain does is serve this blockchain and ICANN data over a connection that computers are already configured to use for accesssing domain name information -- DNS over port 53.

For users to be able to access these blockchain-specific sites, they will need to change their system DNS settings by adding a DNSChain server as a nameserver. (On linux, for example, this is done, naively, by appending nameserver DNSCHAIN_IP to /etc/resolv.conf, where DNSCHAIN_IP is the DNSChain's public IP address.) Once they do that, they will be able to access all blockchain-hosted domain names just as they do .coms and .orgs currently.

[Ajedi32]

Thanks, that answers my question. I knew that DNSChain worked by setting up a regular DNS server that also handles queries to .bit domains, but I didn't realize that that was what "backwards compatible with traditional DNS" was referring to.

Feel free to close this issue, or if you think it would be a beneficial to add an explanation along those lines to the README you can leave this open as a reminder.

[Ajedi32]

On a side note, I think it's somewhat unfortunate that .bit domains aren't accessible without the client having to install something first. I understand the technical reasons why that's necessary, but it's still going to make it difficult for DNSChain to hit critical mass.

It's a bit of a chicken and egg problem. Why would average users (read: not P2P enthusiasts or security experts) install extra software on their computer when they can already access all websites without it, and why would site owners obtain a .bit domain when that domain isn't going to be accessible by >99% of their users without them first having to install some extra software on their computer?

I wonder if it would be possible to set up some kind of fallback domain using the existing DNS system (like *.b.it or something) which would automatically expose all .bit domains. Then websites could adopt DNSChain without having to force users to download special software before using their website, and users who wanted to increase security could install the DNSChain software which would then make all DNS queries to *.b.it domains using DNSChain instead of the less secure, traditional DNS system.

(Oh and yes, I realize DNSChain isn't actually software that gets installed on a user's PC, it just gets installed on a server controlled by the user which the user then uses as their primary DNS. From the user's perspective though, it's basically software. Well, that's my understanding of it anyway.)

[taoeffect]

@Ajedi32 I think someone actually did setup a proxy that worked how you describe, but it's not exactly an ideal solution, as that (completely centralized) proxy would be responsible for passing through all that traffic, which it would be able to also record, monitor, and tamper with.

If you install a DNSChain server in an ISP, your home, your place of work, everyone suddenly gets access to .bit domains without having to lift a finger (at the same level of security as today's domains). If you wanted to make full use of DNSChain's capabilities (i.e. the MITM-proofing aspect), more steps would be required.

[taoeffect]

BTW, you are most welcome to make suggestions as to how we can improve our documentation. Closing this for now since @WeMeetAgain did a great job of answering your question.

[rstormsf]

Centralized solution like @Ajedi32 described would be just one of the ways to make some money. :-) But I totally agree with @taoeffect is that it creates single point of failure and you will have to trust that domain which serves .bit.

[Ajedi32]

Well, from a privacy/security perspective that wouldn't be any worse than the existing DNS system, would it?

The idea would be to provide site operators with the ability to host their site on a domain which is accessible by non-DNSChain users, while still allowing DNSChain users to access the site in a more secure, privacy-preserving, MITM-proof way without having to use a different URL. If that approach becomes popular, ISPs and router manufacturers could then begin implementing DNSChain directly, which would greatly benifit users of *.b.it domains in terms of privacy and security.

There's still a bit of a chicken and egg problem with this approach, in that sites have little incentive to host their domain in a place which supports DNSChain as long as there aren't many users who use that DNS system, but at least with this approach there's no strong disincentive to hosting a domain that way.

[taoeffect]

Well, from a privacy/security perspective that wouldn't be any worse than the existing DNS system, would it?

It would, because all those domains would be going through a single server.

[Ajedi32]

A single server? How so? Maybe my understanding of DNS is a little fuzzy, but are you saying that, for example, all DNS lookups of sites under *.co.uk go through a single server? (As opposed to *.com, *.org, etc.) If so, I find that rather surprising. And if not, why couldn't *.b.it (or similar) be set up the same way?

[taoeffect]

A single server? How so? Maybe my understanding of DNS is a little fuzzy, but are you saying that, for example, all DNS lookups of sites under *.co.uk go through a single server?

My understanding is .it is a TLD, so b.it would be a domain that points to a server, and blah.b.it would be a subdomain, owned by whoever runs b.it.

[Ajedi32]

Typically that is how it works, but based on my rather limited knowledge of DNS, I don't think it has to be that way. For example http://co.uk// is not a website, but https://www.google.co.uk/ is, and so is http://www.amazon.co.uk/. So yes, the blah in blah.b.it is a subdomain, but I think that's technically true of all domains. Even TLDs are just subdomains of the DNS root zone. (Oh, and I only know that because http://xkcd.com/903/)

[taoeffect]

For example http://co.uk// is not a website, but https://www.google.co.uk/ is, and so is http://www.amazon.co.uk/

That's because (pretty sure) .uk is not a TLD, but .co.uk is. You can see it on the list of existing TLDs.

[Ajedi32]

Interesting, is that list authoritative? The filename is "effective_tld_names.dat", makes me wonder whether that list is saying that domains like .co.uk are only "effectively" a TLD, by virtue of the way they are being used by the owner of .uk, as opposed to them actually being top level, like .com, .org, etc, are. I'm not sure though.

Actually, just found this: http://en.wikipedia.org/wiki/Public_Suffix_List

That article says:

A "public suffix" is also known by the older term effective top-level domain (eTLD).

And according to Mozilla:

A "public suffix" is one under which Internet users can (or historically could) directly register names. Some examples of public suffixes are .com, .co.uk and pvt.k12.ma.us. The Public Suffix List is a list of all known public suffixes.

It sounds like browsers currently use the list as an extra measure for preventing site owners from setting cookies on higher-level domains. Honestly though I'm not sure why that's necessary or what exactly it entails, given that subdomains should already be disallowed from setting cookies on their parent and sibling domains.

Is there any distinction between a TLD and any other domain from the perspective of the DNS system though? Again, Wikipedia says:

Most top-level domain name registry operators offer their name spaces to the public or to entities with mandated geographic or otherwise scoped purpose for registration of second-level domains. Similarly an organization in charge of a lower level domain may operate its name space similarly and subdivide its space.

To me, that's saying .b.it could certainly be a thing if we wanted it to. I'm not sure how to set something like that up though...

[wemeetagain]

Just going to drop this here for context: http://en.wikipedia.org/wiki/.uk

IFAIK, the .b.it thing could be done, we would just want to be able to trust the operator of b.it as much as, say, the company which operates .uk. b.it need not represent a single server, and, if the owner was so inclined, b.it could be configured to act like a TLD with subdomains mirroring the namecoin d/ namespace.

It seems that what differentiates a TLD from non-TLDs, besides not having the domain residing in the "root zone", is the infrastructure and operation of the domain, and social momentum. They have had some software and systems in place that haven't really changed at all in the past 20 years, so we see what they do as somehow special or different, when in fact, it is not on a technical level. If I owned b.it could just as well decide that I only wanted to grant access to my subdomains to certain people who pay me (registrars) just like real TLDs do.

Now, would people take me seriously as a TLD? probably not.

[taoeffect]

Thanks @WeMeetAgain! Yeah, I realized after posting that I might've been mistaken about .uk not being a TLD, but I went off and did things and forgot to look further into it, so thank you for doing that!

The primary issue with .b.it is that it undermines the entire concept of a blockchain-based domain.

We don't need it, and we already have .b.it-type solution that everyone already uses: traditional TLDs. You'll note that you can access our website either via okturtles.com or okturtles.bit.

The focus should be on getting browser support for blockchain-based authentication for blockchain TLDs, as that is where the value comes from.

[wemeetagain]

@taoeffect agreed.

I think the traditional DNS system, as connected to the global DNS system, is pretty flawed from a security, privacy and freedom standpoint. It has no authentication, cleartext requests, and we must deign to requesting to daddy-registrar & friends for permission to lease our domains.

However, 'everyone' uses this system, and that makes this a very useful network for now, even if it eventually is displaced by something better. So DNSChain supports it, and it can be exceedingly useful, even if not ideal. (try getting to a .bit domain otherwise)

But you're right, now that we have this fallback in place, it would be very beneficial to flesh out the tools needed to take better advantage of the blockchain's verifiability, and is actually built to ensure this from blockchain to end-user. In any case, a user will need to modify their behavior in some way to access this crypto-world of names and values, it might as be a modification that doesn't just replicate the same old problems we're running from.

[Ajedi32]

The advantage of a fallback like *.b.it over the approach of operators making their site accessible from two different URLs (e.g. .com and .bit) would be that users of DNSChain wouldn't have to care whether a site they visit on the normal web has an alternate DNSChain-based domain available for them to use, domains hosted on .b.it would automatically be looked up through DNSChain. Additionally, they wouldn't have to worry about links to DNSChain-secured sites not working for those who don't use DNSChain, as those users would transparently access the domain using the existing (though less secure) DNS system.

Just an idea...

[taoeffect]

@Ajedi32 OK, well it's not clear to me how your idea would work. How would it "automatically" expose .bit domains? For it to do that, it would need some custom DNS server. If it needs a custom DNS server, it makes no sense to use .b.it instead of .bit directly. Perhaps I'm misunderstanding what you're getting at.

[Ajedi32]

I'm not sure understand exactly what you mean, but the high-level idea would be for whoever controls the .b.it domain (whether that be a person or an organization; preferably the latter) to periodically grab the list of existing *.bit DNS names, and expose them over traditional DNS under *.b.it. That would allow those who don't use DNSChain to access those sites.

Then for those who do use DNSChain, the user's DNSChain server (which should be handling all of that user's DNS queries, right?) would intercept any DNS lookup requests for *.b.it domains, and serve a response based entirely on data from DNSChain, not from the traditional DNS system. So for DNSChain users *.b.it domains would be entirely equivalent to their *.bit counterparts, both in terms of response data and in terms of privacy and security, while at the same time those who don't use DNSChain could still access the site using the same URL, but without any of the added privacy or security advantages that DNSChain provides.

[taoeffect]

Well, there is nothing stopping someone from doing that. It would cost many thousands of dollars and permission from ICANN most likely. But other than that... :P

It would be a real tragedy if someone did that though, as the amount of money needed to do that would probably be sufficient to perfect DNSChain, write several libraries for it, modify several browsers, create several RFCs...

[Ajedi32]

Honestly I have no idea what it would take to pull something like that off. Like I said though, just an idea...

[SGrondin]

Please allow me to pitch in..

.it is Italy's TLD, it has the following restrictions:

Must be a resident of an EU country to register.
Domain name must be at least three characters long.
For entities connected with Italy.

Restriction 1 is no problem. 2 and 3 kill it.

Anyone, including the okTurtles Foundation, could register some domain name and serve the entire .bit space under that domain. So for example mydomain.bit.myotherdomain.com. It would do a lookup to dnschain on the fly for everything before myotherdomain.com.

[Ajedi32]

Yeah, .b.it was just a name I pulled out of thin air (well, I knew that .it was Italy's TLD, but not much else). I was just using it as an example to make the whole idea easier to talk about. As you said, any other domain would work just as well.

I am still kind of disappointed to hear that wouldn't work though, I was starting to like that name! :disappointed: