Log in

No account? Create an account


New TLDs and RFC 1535

« previous entry | next entry »
24th Sep 2012 | 21:33

There has been a lengthy discussion on the DNS operations list about new GDLDs with A, AAAA, or MX records at the zone apex, which allows dotless fully-qualified hostnames and mail domains, such as dk and va. This brings back the old spectre of RFC 1535 and unpredictable name resolution.

One particular example that I care about is local unqualified mail domains. We use Exim's widen_domains feature, which (in our configuration) tries appending cam.ac.uk and ac.uk to the mail domain in turn if DNS resolution fails. This means that local mail domains such as @careers, @farm, @foundation, @law, @wiki and so forth are newly vulnerable to breakage by changes elsewhere in the DNS. This is not really a new problem (there were amusing problems with @uk.ac.cam.cl in the past) but the scale will become much larger.

So I'm wondering what to do. I could change widen_domains to work a bit more like qualify_single (except without depending on the behaviour of the resolver library), that is to try local names in preference to global ones when there are no dots in the mail domain. Or I could make a break with tradition and drop support for unqualified names - but I would have to wean a few dozen people (including myself) off the habit.


| Leave a comment | Share

Comments {7}


from: nonameyet
date: 24th Sep 2012 21:00 (UTC)

I can just about see the justification for pope@va but if Dorling Kindersley can have a web page at dk then you can't reasonably stop everyone from having a global dotless domain.

I would support you in trying local names in preference to global ones when there are no dots in the mail domain.

Reply | Thread

Tony Finch

from: fanf
date: 24th Sep 2012 21:08 (UTC)

If the dk link took you to dk.com rather than dk-hostmaster.dk then your browser is providing a good example of the problems these things lead to! I wonder if links on internal web pages are at all likely to work with a browser that prefers heuristics rather than actually looking at the DNS...

Reply | Parent | Thread

Ewen McNeill

Site local resolution

from: edm
date: 24th Sep 2012 22:57 (UTC)

In general it's an unsolvable problem: if you allow the same name elements to be present at multiple levels and you try to allow unqualified versions of names at different levels with "DWIM" automation, then the aliasing is going to hide some meanings that you want. (Many years ago the .nz policy forbid various CCTLDs/gTLDs as 3-rd level names, to avoid some of this aliasing -- particularly back when people remembered the big-endian domain ordering, viz uk.ac.* -- but I think everyone gave up caring long ago, and IIRC very little is forbidden now.)

From observation (and memory) browsers will try unqualified names as if they were site-local (ie, appending the local domain; possibly trying all suffixes in the resolver search path), and if that fails then they'll start assuming that the user is lazy and "probably meant .com". The BIND-style "ends with a dot" does appear to still work to defeat that handling (eg, dk. does go to the top level domain at least in Firefox). But the heuristic "just add .com if it doesn't work" has been around the reinforcement spiral (people get ".com" names because of it, so people leave ".com" off, so ...) too many times for it to be likely to go away.

At best we perhaps acquire more heuristics ("these are popular TLDs used as single names now we've completely abandoned DNS hierarchy in favour of lots of money"). Or perhaps bare TLDs just don't prove very popular because the "just add .com" horse has long bolted from the stables; it's not like we need two "flat" namespaces with the same names in both. (I think the chances of teaching everyone to type the "." at the end is pretty minimal.)


Reply | Parent | Thread

Tony Finch

Re: Site local resolution

from: fanf
date: 24th Sep 2012 23:10 (UTC)

I think I'm inclined to agree with those who argue it is best to reserve single component names for local and otherwise non-standard DWIMmery, and I don't feel sorry for the new GTLD supporters who get upset by this.

The trailing dot syntax doesn't work in some cases such as email, where the grammar forbids it.

Reply | Parent | Thread

Ewen McNeill

Re: Site local resolution

from: edm
date: 24th Sep 2012 23:43 (UTC)

Personally I think there should be more hierarchy rather than less (it would, eg, lead to fewer stupid variations on "${FOO}movie", "${FOO}-movie", "${FOO}-themovie", "movie-${FOO}, etc). So I too have very little sympathy for any problems encountered by those trying to turn "bare TLD" into a marketing tool. (However I mostly gave up trying to convince people we need more hierarchy years ago, as it was obvious the tide had turned against it -- "hierarchy is hard, let's go shopping".)

In general I mostly see fully qualified names in email, at least by the MTA (most MUAs do, eg, address book expansions of local/known names). But that's possibly in part because most organisations I've dealt with gave up on the "hierarchy is hard" fight long ago, and have a flat namespace for email even if they don't have a flat namespace for DNS. (A flat namespace for email creates its own problems, but mostly people are already dealing with those problems elsewhere, such as single signon user accounts.)

For sites that still have local email hierarchy and common usage of, eg, ${USER}@${SCHOOL} within the umbrella organisation making it outside the MUI (ie, the MTA has to deal with it), I suspect it'd be reasonable to make a policy decision of "local first, global last". I fully expect the "bare TLD" vanity domains craze will be very unlikely to go beyond the web browser. (Much like the "intercept no-such-record" hacks barely thought about anything else.)


Reply | Parent | Thread


from: ewx
date: 25th Sep 2012 07:41 (UTC)

My squid won’t talk to http://dk/ (but it can cope with dk.).

Reply | Thread


Ambiguity is bad

from: mas90
date: 4th Oct 2012 04:29 (UTC)

This problem surely isn't unique to dotless FQDNs. What about mail to, for example, "foo@merton.ox"? There could in the future be a TLD "ox" which isn't the University of The Other Place, and a FQDN "merton.ox", and now your use of widen_domains won't get as far as appending ac.uk as the user might have come to expect.

Also consider that there may be genuine email addresses at the new TLDs (e.g. "foo@careers" being a fully-qualified address); if you allow mail to unqualified domains, there may be two equally-valid resolutions of the same address with no way of knowing which one the user intended.

What's even worse is that the user has no way of specifying how this ambiguity should be resolved.

I feel, therefore, that it's unsafe to allow ambiguity in email addresses and that mail to unqualified domains should be deprecated before this becomes a problem.

(Arguably, all use of unqualified names should be deprecated: I have a machine called "io" and sometimes find myself accidentally connecting to "io."—already a valid dotless FQDN!—when I'm missing the right search domain.)

Reply | Thread