Subject: [DNSOP] *.DNS metaTLD [ref: additional special names]

From: okTurtles <[email-masked]>
Date: Sat, 1 Mar 2014 18:45:09 -0600

Hi list,

Just saw Stephane Bortzmeyer's email to the list:

On Mar 1, 2014, at 9:07 AM, Stephane Bortzmeyer <[email-masked]> wrote:

> There is even better now, there is a .DNS :-)
> 
> http://blog.okturtles.com/2014/02/introducing-the-dotdns-metatld/
> 
> Because it is very recent, it has no installed user base. This may be
> a good opportunity to get in touch with the author(s) and ask them if
> they would be willing to accept a dns.alt or something like that. Any
> volunteer for outreach?

That blog post was written, in part, so that it could serve as reference for related emails on this list. :-)

Some background for those who haven't read it:

I'm working on a blockchain-based DNS resolver and (and proxy-to-blockchain) called DNSChain. It is mostly implemented, and it works (I'm using it right now in fact, along with dnscrypt-proxy).

It introduces a meta-TLD called *.dns (dotDNS, with or without the hyphen). Details here:

<http://blog.okturtles.com/2014/02/introducing-the-dotdns-metatld/>

The term "meta-TLD" (with or w/out hyphen) is used in place of "pseudo-TLD" to emphasize the fact that pseudo-TLDs have more in common with standard TLDs than they do with meta-TLDs.

metaTLDs are different from *.onion, *.bit, and other special TLDs, in that:

- They are not intended to globally resolve to a specific IP, but rather to the DNS server that you've chosen to connect to (in this case, DNSChain).
- They cannot be registered, because they already belong to you.

The blog post goes into detail about why they are useful, and what we use them for. Specifically, it shows how metaTLDs can be used in concert with a secure, distributed and decentralized database (read: blockchain) to protect online communications against TLS MITM attacks.

A related use is a secure method of public key distribution for GPG keys, see the GitHub page for an example of this:

<https://github.com/okTurtles/dnschain#Use>

The same friend who suggested I post here about this project also suggested that I mention that this project may be of interest to the folks at STRINT 2014.

> ask them if they would be willing to accept a dns.alt or something like that.

*.dns is a metaTLD, whereas I don't believe *.alt has been designated as such? As far as I was able to tell, *.dns has also not been used for anything else, so it's an ideal choice, as it creates an HTTP(S) interface to arbitrary name-resolution systems for JavaScript apps, including today's DNS.

Currently implemented is the namecoin.dns domain, but you can imagine web apps querying today's DNS system over something like `canonical.dns` (something that wasn't possible previously due to browser limitations).

Would an internet-draft or RFC-type specification be of interest?

Constructive feedback is very much appreciated.

Cheers,
Greg Slepak

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

---

From: Joe Abley <[email-masked]>
Date: Sat, 1 Mar 2014 22:13:23 -0500

Hi Greg,

On 1 Mar 2014, at 19:45, okTurtles <[email-masked]> wrote:

> *.dns is a metaTLD, whereas I don't believe *.alt has been designated as such?

You're right, ALT (the TLD) doesn't exist today, might one day exist, and is not special in any way right now, although a draft proposal exists to make it special and avoid its future delegation from the root zone.

If we suppose that it's possible, due to software defects or user error, that DNS queries will one day be sent to the Internet for names ending in .DNS, how about choosing a parent domain that you control, and whose traffic can be managed separately, instead?

Leaked traffic for names ending in .DNS is going to hit the root servers today. If a new gTLD called "DNS" exists in the future, you'll hit their servers (and there will be confusion between which name was intended, and potentially leakage of query data between the two namespaces). If you use a name ending in .ALT, and the ALT proposal is adopted, your traffic is back hitting the root servers again, but at least you're not colliding with other names.

If you use your own domain that you have registered and control, you can direct any leaking traffic wherever you want. You can sink it in AS112+ servers (assuming this wg likes that proposal) using an apex DNAME. You have options.

I think considering the possibility that queries will leak towards the DNS is important when you start to develop a new, non-DNS namespace (so, it's great that you're here). Not thinking about it has the potential to leak users information in unexpected directions, and cause operational mayhem with other peoples' nameservers.

It's hard to see a better option than today than anchoring your new namespace to a domain that you register and pay for in the DNS. Your options in that regard include TLDs if your namespace is sufficiently sensitive to label length that you're prepared to pay the $500k+ for the process to register it; to my mind, your local TLD registrar can probably give you a better deal.

Joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 2 Mar 2014 23:02:43 +0000

On Sat, Mar 01, 2014 at 10:13:23PM -0500,
 Joe Abley <[email-masked]> wrote 
 a message of 93 lines which said:

> It's hard to see a better option than today than anchoring your new
> namespace to a domain that you register and pay for in the DNS. Your
> options in that regard include TLDs if your namespace is
> sufficiently sensitive to label length that you're prepared to pay
> the $500k+ for the process to register it; to my mind, your local
> TLD registrar can probably give you a better deal.

Bad idea. In most (all?) TLDs, you do not have sufficient security (I
don't mean technical security, I mean security against seizure or
things like that) so you risk losing your domain. And you have to
abide by the rules of a given TLD (not to mention you depend on yet
another actor, the registrar).

Of course, during the normal course of operations, it does not matter
since the normal requests are handled by another protocol, not the
DNS. But it has an importance when it comes to leaks (requests that
accidentally go to the DNS).

---

From: Joe Abley <[email-masked]>
Date: Mon, 3 Mar 2014 13:09:24 +0000

On 2 Mar 2014, at 23:02, Stephane Bortzmeyer <[email-masked]> wrote:

> things like that) so you risk losing your domain.

I think that's hyperbole.

It's clear that it's possible to arrange very stable registration of domains, sufficient at least for some very valuable web properties to base their businesses on.

It's also clear that it's possible to do this badly.

I suggest that it's entirely plausible for someone to choose a DNS-namespace anchor for their non-DNS namespace that is as stable as they want, depending on their needs.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Mar 2014 13:12:38 +0000

> I suggest that it's entirely plausible for someone to choose a DNS-namespace anchor for their non-DNS namespace that is as stable as they want, depending on their needs.

This is clearly not the case for an open protocol spec, though, since there is no one entity that could be responsible for maintaining the registration.

---

From: Joe Abley <[email-masked]>
Date: Mon, 3 Mar 2014 13:20:02 +0000

> This is clearly not the case for an open protocol spec, though, since there is no one entity that could be responsible for maintaining the registration.

Certainly there could be cases where that is true. I can't think of an example from the candidates we've identified in this (and other threads) to date, though.

(e.g. tor -> eff.org; dns -> okturtles.com).

There's inevitably *someone* who needs to take a lead on coordinating any codebase, if the codebase is to produce anything useful. I'm suggesting that that person could easily register a domain.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Mar 2014 13:31:11 +0000

> There's inevitably *someone* who needs to take a lead on coordinating any codebase, if the codebase is to produce anything useful. I'm suggesting that that person could easily register a domain.

What happens when eff.org gets bought by the church that must not be named?   Or whatever.   Protocol specs outlive organizations.   Obviously I hope eff lives as long as it's needed, but I think that a non-registry answer is more robust and really much more appropriate for this use case.   It feels like a bit of a stretch to argue that EFF should register .tor.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Mar 2014 14:50:36 +0000

On Mon, Mar 03, 2014 at 01:09:24PM +0000,
 Joe Abley <[email-masked]> wrote 
 a message of 32 lines which said:

> It's clear that it's possible to arrange very stable registration of
> domains, sufficient at least for some very valuable web properties
> to base their businesses on.

When you are a big company like amazon.com or google.com with money,
lawyers and so on. Not when you are a free software project ran by
volunteers.

> I suggest that it's entirely plausible for someone to choose a
> DNS-namespace anchor for their non-DNS namespace that is as stable
> as they want, depending on their needs.

Many people who lost their domain name would like to know how to do
that.

---

From: Christian Grothoff <[email-masked]>
Date: Wed, 05 Mar 2014 16:04:33 +0100

> Many people who lost their domain name would like to know how to do

Yes, and while you're at it, please tell the people from
thepiratebay.org --- their ability to keep a stable DNS namespace anchor
has been abysmal recently.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 5 Mar 2014 15:22:17 +0000

> (e.g. tor -> eff.org; dns -> okturtles.com).

because I don't want my leaked query for www.nakedfurries.foo to hit
the wimble.example.com nameservers? Even if I currently trust them not
to be logging that.

Putting .foo under .alt and making it a locally served zone (return
NXDOMAIN for all queries) means that my leaked queries only hit my
local resursive. And not everyone's leaked queries get aggregated
somewhere. The ALT doc also suggests that stubs could drop queries,
and then they wouldn't even hit the recursive ( I suspect that this is
not likely, but...)

W

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop