Single Words In The URL Bar

Posted on by

What do we, and what should we do when people type single words in the URL bar?

ICANN is opening up the registration of new gTLDs (generic TLDs, like .com, .info, .museum etc.). Applications open in 2012, and they expect to create thousands of them over the next few years. In general, I think this is a good thing. It will make many more naming possibilities available, and drive down domain prices. However, there is one policy question we need to consider.

Let’s say I’m the large corporation FooBar Corp, and I apply for and receive the top-level domain .foobar, which I plan to use for websites connected to my company. The New gTLD Applicant Guidebook is 352 pages, so I haven’t read it all, but section 2.2.3.3 gives the permitted DNS record types for that entry in the root zone. It specifically allows SOA, NS, DS and DNSSEC-related records, and then says:

An applicant wishing to place any other record types into its TLD zone should describe in detail its proposal in the registry services section of the application. This will be evaluated and could result in an extended evaluation to determine whether the service would create a risk of a meaningful adverse impact on security or stability of the DNS.

So here’s the big question: could FooBar Corp set up an A record for “foobar”? And, if so, should web browsers take users to that site when “foobar” is typed in the URL bar?

I can see how companies would love it if users who typed e.g. “nike” into their URL bar automatically got taken to an official Nike website, instead of doing a search for “nike” using the user’s default search engine. But I’m not certain that this is what we actually want to happen, particularly for non-trademarks. Do we let someone spend $185,000 (the application fee) and buy all URL bar searches for the word “car”? Or “mortgage”? I think it’s at least questionable whether that is in the best interests of users.

Someone who knows: what exactly do we do now? I think we do a DNS lookup and, if it fails, do a search. So perhaps we would go to the A record for “foobar”. Is that what we want?

If we decide we should change Firefox’s behaviour, we would ideally do it before applications start, so applicants can’t claim they weren’t warned. So it’s important we discuss this now.

30 thoughts on “Single Words In The URL Bar”

  1. I’d argue that we should allow top-level A records. I strongly suspect that someone will decide to create the worlds shortest URL shortener (x/foo, for various values of x). And personally, I’d like to see TLDs with MX records as well, to allow dotless email addresses.

  2. The bigger problem, I suspect: what happens when TLDs conflict with local DNS, which previously expected to use extensions like .lan or .home? What happens when someone registers one of those? How long before they start intercepting private traffic from machines that don’t know any better? Would ICANN allow something stupid like registering .local? What about .localhost or .localdomain? Or, how much traffic will the TLDs “exchange” or “router” or “smtp” or “imap” or “mail” get?

  3. Basically, leave my url bar alone. I want search-by-name on some occasions and normal search on others and that’s it, thank you very much.

  4. I presume none of this will override a keyword I’ve set up to go directly to a bookmark?

  5. We use local DNS records for accessing internal services easily (http://internalutility). A TLD should not be permitted to confuse that operation in any sense, full stop. It would confuse the UX, it would complicate the security posture of that operation… it’s just a bag o’ worms.

    On the more ethical level – why do Firefox consumers want someone who pays a bunch of money to control their application’s uiltimate behaviour? They don’t. The Mozilla Mission is about giving users control, not handing it off to those who pay.

    People are happy with the current system as it behaves now – and if that behaviour is going to change then I don’t see why we wouldn’t change the system to maintain the existing, popular, behaviour without a convincing argument against it.

    The decision seems fairly obvious to me.

  6. “In general, I think this is a good thing. It will make many more naming possibilities available, and drive down domain prices.”

    I disagree. I think more TLDs or domain names in general is a bad thing. I’m not sure how other people are doing it but I usally need a search engine or Wikipedia to find the website I want to visit (if it is not in my browsing history already) because I don’t know if the company/organization is using .com, .org, .info, the countries TLD or whatsoever as TLD. That means for me the system is broken.

    Now when the system is not discoverable anymore (like it is already, in my opinion, since you need to use another tool to make it usable) you could as well ditch the whole system, use a unique identifier (preferably almost hidden from the user) instead of a textual name and replace the name system with a sort of tag or categoy system that for example allows to find websites by different means (e.g. typing “De Berlin Apple” into your browser will retrieve internet presences that were added with these tags and your browser generate a list/overview of them, in the case of my example that might include both the local Apple Store and grocery stores in this area [1]). And when you’ve found what you’re looking for, you can still bookmark the page (since it would still have that unique identifier in the background).
    In the end it would be a tag-system that incorporates a search without need for third party tools (like Google, Bing, Wikipedia) to be usable.

    This was a rant, I admit, but it is what I needed to say when reading the opinion that more TLDs would be a good thing.

    [1] Even though I’ve mostly used geographic categories here, this should be much broader, e.g. having opensource, company, .. categories that would allow to find.

  7. Perhaps I’m misunderstanding what you described, but it used to be that when you typed one or more words in the URL bar and hit enter that we’d send it to Google and if the search result ranking were high enough we would send the user to the (I’m feeling lucky) page, if not, we’d send them to Google search results.
    We changed the behavior to only send users to the search results. The avoided sending the user to unexpected or undesirable web sites.
    I’d say the current behavior makes good sense and should be kept.

  9. I’m not convinced x/foo would be a good shortened URL, because you’d need to include the http:// to make sure lots of URL recognizers actually picked it up…

  10. I suspect IANA will not allow registration of the really obvious ones – .local, .localhost etc. There’s probably a reserved list somewhere. But you make a good point about imap/mail etc.

  11. That’s not what your URL bar does now, AIUI…

    Could you expand on what you mean by “on some occasions” and “on others” – do you decide? If so, how do you tell Firefox? Or does Firefox decide? If so, how?

    Gerv

  13. A tag system which incorporates a search but without the need for a search engine? That makes no sense.

    Regardless, we have to work with the system we have, not whatever system we wish we had. :-)

    Gerv

  14. I’m pretty sure we have never made decisions based on search ranking. A long time ago, a URL bar ‘search’ was an I’m Feeling Lucky search. Now, it’s a normal search. But it was never both at once, depending on the search result.

    Gerv

  15. I’m fairly sure that’s not an accurate description of our current browser behaviour :-) But I’m hoping someone who knows will come along and tell me what is.

    Gerv

  16. For a while we used Google’s “browse by name” (a variant of “I’m feeling lucky”), which sent users directly to the top result if Google’s confidence was high, but otherwise sent them to the search results page. We’ve since switched back to just using the normal search functionality (bug 565966).

  17. If single words can have A records in the global DNS, that opens up a class of exploits on intranets, because there’s an intrinsic conflict with the DNS suffix-completion mechanism. As you may already know, most DNS libraries have a configurable list of suffixes; if a lookup for “foo” returns no results, they’ll retry tacking each of the suffixes on the end. This means that intranet builders can use URLs like http://accounting/whatever and have them resolve as if they had written http://accounting.company.com/whatever. But if someone manages to register an A record for “accounting” in the global root DNS zone, that server will steal all the traffic from the intended internal server. WINS server names have no dots in them, so there’s a similar conflict there too.

    (It’s important to realize that this is *not* just about the URL bar; all DNS lookups are affected. Incomplete domain names in URLs in hyperlinks are probably a bigger attack surface.)

    (The suffix-completion mechanism used to apply to *all* failed lookups, even if they had dots in them, but I don’t know if that’s still the case.)

    Because of this, I think Mozilla should come out strongly against A records for TLDs or TLD-equivalents (anything in the public suffix list, to first order) and should probably also enforce that in code. Not breaking lots of intranets while doing so will be a trick, though. Maybe we can convince the DNS resolver to go straight to suffix-appending when we have a no-dots name to look up? We need our own DNS resolver anyway so we can do DNSSEC, so we should be in a position to work around system resolvers that can’t do that.

  18. In general, like others, I believe that ICANN opening up the domain space for additional gTLDs is bad.

    However, that is the system we are now going to have.

    In this case, I’d rather that *new* domains had slightly different rules.

    If it isn’t on the existing domain list (prior to opening for any gTLDs), then that top-level itself (i.e. NEWDOMAIN) should have no records apart from NS (and associated security records) and SRVs.

    This means that if there is a website for NEWDOMAIN, then by following _www._tcp.NEWDOMAIN we can find the location for it WITHOUT attempting an A record lookup of NEWDOMAIN.

    Cheers,
    Anand

  19. Regardless of current state, I will agree that I’d much prefer to see single words be treated as keywords unless accompanied by a scheme identifier like http://… but then I’m also still waiting for Google and Mozilla to adequately justify their silly decision to hide the http:// on non-mobile browsers.

    (So far, all Google did was close comments on the bug where everyone was asking for an about:config-analogue to restore http:// and for the Google devs to share their reasoning. Thankfully, Firefox has an about:config I immediately toggled.)

  21. If we’re going to do _http[s]._tcp SRV lookups at all, we have to do them consistently, and that means if _http._tcp.foo doesn’t resolve we have to try _http._tcp.foo.company.com, and *that* means it has the same security problem as allowing A records at top level.

    So, no. Nothing but delegations at the top level or the pseudo-top level (e.g. .ac.uk.) That also has the advantage of being a clear bright line that we oughta be able to get the IETF behind.

  23. You make good points. ICANN does seem concerned with the stability of the DNS (which hopefully means more than just the global DNS) and so the effect on intranets. They have spent a lot of time thinking about this and so perhaps they have no intention of approving A or MX records in the root zone. But if so, it would be good to get a statement out of them about it.

    Gerv

  24. On the one hand, I am generally against adding any new top-level domains. The ones that have already been added are either barren wastelands with scarcely anything in them at all (*cough* .museum *cough*) or worthless cesspools used more or less exclusively by shysters and miscreants (I’m looking at you, .info). I am also significantly dissatisfied with the fact that non-government entities can now register in the .us namespace. These changes have eroded the (already rather lax) semantics of DNS. Just when we had just about got to the point where a few people other than IT professionals were aware that there were TLDs besides .com and what that meant, now we’re going to throw what remaining meaning the system had right out the window.

    On the other hand, I have argued for years that nothing typed in the URL bar should be looked up in any source except DNS. If it doesn’t resolve, the result should be a “no such address” error page. Consulting non-authoritative sources like search engines in a misguided attempt at DWIM causes significantly more problems than it solves, and the fact that browsers have been doing this for years now has resulted in an intolerable amount of user confusion about what an address is anyhow. If the addition of new TLDs forces this issue, perhaps some good will come out of the whole .yournamehere fiasco.

  25. Agreed. I’d push for an even stronger rule, though: there should be a short whitelist of records allowed at the top level, and this whitelist should be maintained on the principle that only delegations may appear at the top level. Currently that means SOA, NS, DS, DNSKEY, RRSIG, and NSEC* records are okay.

  27. I previously worked at a startup company that tried to use the free market to cause people who typed the wrong domain into the URL bar to end up at whatever site was most valuable to them. It worked by renting domains from squatters, then auctioning redirects from those domains to people who wanted to buy traffic. It was a much cheaper way to buy traffic than ads.

  28. Many people here seem to be assuming that the only way you get resolution is via DNS. That is of course not true. There are other namespaces too, including local hostnames and mDNS and llmnr type namespaces.

    Part of the problem with these “bareword” names is that they look just like pre-DNS hostnames, and they also look like things that ought to have the search path appended to them for lookup. Therefore, no matter what anyone does with these things, there is a good chance that they won’t work as expected for some people.

  29. There is no “clear bright line” once you start talking about things like “pseudo top-level domains”. The very idea is nonsense. You cannot tell the behaviour of a zone by looking at its place in the tree.

  30. There is a thing called the public suffix list, and that is the closest available approximation to the notion we want here. I do realize that any such list is permanently out of date. Do you have a better idea?

Leave a Reply

Your email address will not be published. Required fields are marked *