Gervase Markham | 22 Jun 2012 11:39
Picon
Favicon
Gravatar

Re: Implications of new TLDs

On 20/06/12 17:34, Zack Weinberg wrote:
> Ugh, you're right; I forgot about /etc/hosts and WINS names.
> 
> There might be something clever we can do to detect these, but I'm not
> sure what it would be offhand; the operating system APIs I know about
> are deliberately designed to hide the details of where the names come
> from :-(

So our current thought is that we can't technically do anything about
this? But our options may change when we acquire our own DNS resolver?

>> Can we tell those calls not to do their own suffix search before
>> they return their answer?
> 
> Yes, we just stick an extra dot on the end before calling getaddrinfo.

And we'd have to find the source of suffixes on each OS so we could
reimplement this functionality.

> It's certainly possible, e.g. http://example.cc/ where `cc` is both a
> real TLD and an internal subdomain.

I suspect few businesses use existing real TLDs as their external
subdomains. However, I also suspect quite a few use future TLDs! There
are lots of short TLAs, e.g. ".aco", ".ads" - I bet there are many
businesses with 3 or 4-letter initials who use them. And I bet a load
use ".corp" (6 applicants) and ".inc" (11 applicants).

> I confess I see this as another argument for disabling suffix search
> altogether.  It breaks *more*, but we get a substantial reduction in
(Continue reading)

Daniel Veditz | 25 Jun 2012 21:47

Re: Implications of new TLDs

On 6/22/12 2:39 AM, Gervase Markham wrote:
> I suspect few businesses use existing real TLDs as their
> external subdomains. However, I also suspect quite a few use
> future TLDs! [...] And I bet a load use ".corp" (6
> applicants) and ".inc" (11 applicants).

We've already seen confusion with some organizations using .int
(internal) and the gTLD .int (intergovernmental) leading to
inappropriate SSL certificates being issued.

-Dan Veditz

Gmane