(If you want to put focus on the domain, then display the host-part with less contrast, i.e. grey, but don't hide any potentially vital information. Otherwise, put out a RFC, defining "www" as a substitute for "*", or a zero-value atom, in order to guarantee consistent behavior.)

Edit: There are also legal concerns with catch-all domains in some countries. Blending the lines certainly doesn't help.

The domain name system has been around for decades and it's a clever and proven system. It can – and should be – taught in school and, arguably, knowledge of it is, while not difficult to obtain, essential in our times. Additional ambiguity in this is probably not what we want.

Arguably, the most sincere problems arise from mixed alphabets with Unicode domains and look-alike characters/glyphs. This could be addressed by a) going back to codepages (Unicode subranges) and defining a valid subset for each range, and b) enforcing a domain name (hostname and domain) to be in a single codepage. Clients should derive the codepage by the Unicode range and generate a codepage-identifier, which may be displayed as a badge, identifying the respective range. And, of course, any mixed domains should be regarded illegal and invalid. (We may even want to make this codepage-identifier a mandatory particle of any URI, preceding the hostname.)

No way. The most sincere problem is that hostnames do not enforce any binding to a real world identity that users can understand (nobody inspects certs) and that the most trustworthy component of a hostname is the second to the last section (right before ".com"). Humans tend to look at the front of the URL, making "www.bank.evil.com" a mind bogglingly effective phishing technique.

Homoglyphs are almost always a sign of bad behavior and can just be banned to a large degree. The fact that "foo.com" or "foo.evil.com" are not necessarily owned by company foo is much worse.

Regarding lacking binding of identity: On the other hand, this has been one of the most important features of the web, from the very beginning. Also, there is no way to setup a system, which will attribute to a single person in a readable and intuitive way. (E.g., names fail to do so.) Arguably, this should be left to (optional) extensions.

I'd argue, the knowledge required to parse a URI safely may be conveyed in couple of minutes. Why not enforce this knowledge? Why not have a URL-parsing note on the start screen of any browser? Why dumb down the system and introduce ambiguity – and by this even more insecurity – instead of educating users? URL-parsing is a vital skill, which can be acquired in less time than memorizing a basic table of partial addition results. Why do we still try to teach addition, if we can't teach URLs?

foo.com is owned by "foo" foo.evil.com is owned by "evil" foo.co.uk is NOT owned by "co"

> Looking back on 15 years or so of development of the Web is there anything you would do differently given the chance? > "I would have skipped on the double slash - there’s no need for it. Also I would have put the domain name in the reverse order - in order of size so, for example, the BCS address would read: http:/uk.org.bcs/members. The last two terms of this example could both be servers if necessary."

From http://www.impactlab.net/2006/03/25/interview-with-tim-berne...

First start at the slash and work your way left: "com -> noodles -> tasty -> mobile" - then jump back to the slash and work your way right: "italian -> fettuccine".

This is counterintuitive and I doubt most users understand it. "com.noodles.tasty.mobile/italian/fettuccine" makes more sense to me.

Also, I think TLDs like "com" and "edu" and now "io" and "cool", etc, are misguided. I wish we had "country.language" as the only TLDs. For instance, "us.en.apple.www/mac". I see several advantages.

One, if "us.en.apple" and "uk.en.apple" were different entities, it would make legal sense, whereas "apple.com" and "apple.cool" being different entities makes no sense. Two, a use would likely notice if they ventured outside their usual TLD(s), and be less surprised by the different entity. Three, these TLDs could have rules about allowed characters; eg, only ASCII in "us.en". This would make homoglpyh attacks much more difficult.

* https://en.wikipedia.org/wiki/JANET_NRS

Who's without interest may throw the first stone, er, browser extension.

Recently a friend of mine didn't see the lower dot on the 'e' in a URL [0], and promptly ended up inadvertently broadcasting messages to everyone on her WhatsApp contacts list.

[0] www [dot] hẹb [dot] com/coupon/

If you have 1000 distinct images, but a given domain has 5 letters that could each be replaced with any of 3 visually identical Unicode characters, then, well, the chances are very high that there exists a plausible impostor domain with the same image. I don't think this is a very workable approach.

An identicon is a hash value represented as an icon. "facebook.com", for instance, may hash to a red image with a yellow line through it. While you wouldn't remember the icon initially, over time you would – or at least your subconsious would. If you ever visisted a fake-Facebook, you'd immediately notice that something was wrong if the icon suddenly was green with a blue dot in it, for instance.

However, teach users to read domain names! If users do not grasp the general concept, e.g., if the supposed identity is just "example" (possibly with some decoration considered insignificant) and not "example.com", how are they supposed to survive? Domains have been around for more than a quarter of a century, the Internet is actually part of our lives… There is no excuse, and there is no sense in pretending that there was no harm in not understanding the basics. That said, there are real ambiguities that have to be addressed.

FFS, if users cant see that somedomainname.com is different than somedomanname.com how does a randomized image of the domain name based on a hash solve this.

I know of at least one site which users a user selected image in the login screen to thwart phishing attempts. Because its user selected its memorable, I think more so than a password for example. It would be hard for a scammer to spoof as well because they don't know the image the user selected when they created the account.

Unfortunately this would probably be less notable and thus memorable if everyone did it.

Here is the discussion on HN: https://news.ycombinator.com/item?id=17947467

this is essentially what is already implemented in most browsers. You can't mix characters from different scripts in a domain name, except for special cases (e.g. japanese and latin are frequently used together and have little potential for confusion)

Google is trying to get users to go through their doorway pages, which is exactly the kind of thing for which they penalize publishers.

Pay attention to when you enter direct addresses, let's say from a device/media subscription authorization page. The autosuggestion feature will often recommend Google searches, disguised as URLs, instead of helping you complete the very obvious URL.

If they help you get to the site directly, the opportunity to acquire your page views diminishes.

These behaviors are hostile toward users. I'd like to see further in their playbook to depreciate the URL as we know it.

As a comment reads there, do they want to reintroduce AOL keywords?

Edit: May we expect a non-standard subdomain "google-remote", which is more of a protocol-extension and will be also hidden?

They killed it off in 2014.

GTFOH! HANDS OFF!

They might be changing how they want to display them, but "do away with" is unsupported by the article:

> But this will mean big changes in how and when Chrome displays URLs. We want to challenge how URLs should be displayed and question it as we’re figuring out the right way to convey identity.

https://www.wired.com/story/google-wants-to-kill-the-url/

"The focus right now, they say, is on identifying all the ways people use URLs to try to find an alternative that will enhance security and identity integrity on the web while also adding convenience for everyday tasks like sharing links on mobile devices."

My statement is clearly supported by the article. They paint a rosy picture of it, because this is a submarine piece, but they are definitely making moves against the url.

You're ignoring a direct quote in favor of a Wired reporter paraphrase (one which mentions sharing links, no less). They cite an earlier effort, which was a display change. This issue is for a display change. None of this points to "trying to do away with URLs".

Except for that "trying to identify an alternative" part. But let's ignore that, because doing so makes you comfortable.

"I don’t know what this will look like, because it’s an active discussion in the team right now," says Parisa Tabriz, director of engineering at Chrome. "But I do know that whatever we propose is going to be controversial. That’s one of the challenges with a really old and open and sprawling platform. Change will be controversial whatever form it takes. But it’s important we do something, because everyone is unsatisfied by URLs. They kind of suck."

https://www.wired.com/story/google-wants-to-kill-the-url/

She's says it's important that they do something! GTFOH! Hands of our Internet!

The problem here is that they view Chrome as their platform. They have too much market share ala IE6. Instead of following and helping to shape standards, they are considering highjacking the project. Argh!!!!!

Hidding the url scheme was the first step down this path of utter stupidity and I vividly remember the hostility and hubris of the Chrome team at the time.

We still have Firefox, but many times they just blindly follow suit.

But how are we to expect users to know any better until general technology literacy improves?

Many people can't tell you the difference between a modem, router, OS, browser, or website.

I remember years ago sitting down with my elderly grandmother trying to show her how to use a desktop...

We are too close to our work so everything is familiar and easy.

Even the concept of moving the mouse on a table to represent moving the mouse cursor on the screen is something we take for granted.

Tell someone who's never used a mouse before to double click something to open it. You have to start way back earlier at the concept of which physical button on the mouse to use.

This turned more into a general rant about how we overestimate regular users but I'ts been on my mind for awhile.

They don't care, nor should they. How many people know how many spark plugs are in their car?

You're correct. We, the more tech-literate, take too much for granted; and most experiences and learning curves are too far over the head of the "average" user.

It's not them. It's us.

So in this case:

Not display www. in the address bar is actually a whole lot like not display www. in the address bar.

It's more like looking in the mirror before changing lanes. It's something you need to check in order to stay safe.

Mirrors, like URLs, are just an implementation detail. But since currently driving works with mirrors, you have to learn how to use them.

Where is the cause and effect for a URL or SSL cert? There is no learning experience.

Furthermore as some have claimed, and I've personally witnessed, for some URLS's literally dont exist. Just type whatever site you want into the google box and hope you get lucky.

We have enough historical context to realize that things like parsing URLs by eye is unsafe for the general population, and always will be. The solution is to engineer that need out of existence.

You might want to consider that manufacturers have added blind spot detectors to cars as people are bad at changing lanes safely, even with all the training in the world.

One could say the interface was dumbed down to the minimum.

They absolutely should care. They should be aware that when they store things in "the cloud" they are not stored on their device and are visible to third parties. They should understand what encryption is and how to use it. "I don't know what I'm doing, and I didn't get the result I wanted, but it's not my fault it's the machine" is not an acceptable statement, whether we're talking about cars or computers.

"How do you not know that?"

Why would I need to know this? Why do I need to know what a cylinder is to drive? Is this even a logical question with electric cars now?

You are arguing what should be vs. what is.

* Well, I don't currently drive but I couldn't tell you with 100% accuracy the number of cylinders my last car had.

But you do know how many pedals there are in the car and probably, how many switches there are for the lights, and that the wiper has different steps of speed etc. You even manage to control these few elements, because they are the user facing elements your dealing with, the interface. There's no need to unify the pedals into a single one and to have the car to decide, whether it means accelerate, break, or clutch. Doing so would alienate you from the very task of driving, from what it means and what risks are involved. Taking these few controls away from you in favor of an ambiguous I-know-it-all-so-you-should't-care interface of ultimate convenience would probably not increase the security of operations.

On the other hand, we may expect you, as a driver, to know that there is a engine, that this is why the car moves, that it needs gas/petrol in order to run, that deacceleration is proportional to speed, etc.

Why is it so different with anything involving a computer? Is it, because we're telling them so?

I bring up in a previous reply that mirrors, and now lights, pedals, and other controls, that these are directly user-facing and must be interacted with in order to get anything done. Even knowing there is an engine that might need engine-y things like water and oil.

But where is the requirement a user knows about URLS in order to use the web?

Way back when we had AOL keywords. Now we have Google and apps and other tools that make URLS unnecessary.

My grandmother that I I mentioned before. She browses solely through bookmarks and via Google results. That a URL exists is not only an implementation detail but completely unneeded and unused in her case.

Then something like an SSL cert? Where it will work just fine without? I don't even want to imagine trying to explain that to my grandmother before sending her off to her decades old AOL mail inbox.

Only recently with Chrome displaying "Not Secure" have I even noticed any concern or interest amongst non-technical friends and aquaintances.

Also, I consider some of this very US centric. In many parts of the world, AOL wasn't a big thing. In many languages, people are used to the fact that important parts of a sentence come at the very end, e.g., the verb, at least in some tenses. Moreover, most important identifiers go from the minor, less important part to the bigger, most significant ones. Why can't we tell users that domains work just like their post address? (As in "street-city-country". And there are even funny ones, like "street-city-state-country" and even funnier ones, like "c/o", meaning it's not the usual addressee. Why are people able to deal with this?) If you're living in a western country, even your own name works probably like this. Why this, oh, it's magic, don't care?

I'd say, it is mostly, because we encourage them not to care. Because we say, "Yes, that's really difficult", where we ought to say, "No, it's really simple and you ought to know." The user is still the person in charge. Pampering and flattering the person in charge into incompetence isn't apt to end well.

I'd say, there's a chance to convey simple things, like, the cloud is not on your local machine, or how a URL is principally constructed. Or that a file is saved only, when you safe a file.

Edit: Returning to the obligatory-car-simile, when I did my driver's test, I had to know the intrinsics of an engine, of the braking mechanism, of the steering. I was tested for knowledge of ad-hoc technical repair. It was assumed reasonable for a driver to grasp, to memorize the details, to minutely describe them, and it was even mandatory to do so in order to obtain a license. However, it was less important to drive a car then (you could do well without this in most occupations) than it is to operate a computer nowadays.

Edit 2: And, to level up a bit, how comes that academics are able to correctly cite a book and page, but are unable to parse a URL – and are even flattered for the latter?

So, it's entirely unfair to suppose that since people got used to having tap water and so we are surprised if a person can't operate a tap, therefore they should be used to the entire complexity of computation by now.

You definitely _should not_ count machines that aren't actually computers ("digital accounting machines with storage") since those aren't Church-Turing, they're just another trivial machine like a calculator. Instead, compare the other working example we have of full-blown Church-Turing: Humans. Why aren't people somehow used to everything about people yet? People have been around a long time too. Why isn't everyone prepared for every idiosyncratic or even nonsensical behaviour from other people, they've surely had long enough right?

Anti-intellectualism runs deep in our society.

We're talking about users not understanding the technology they use daily.

jwalton, in trying to give an example with spark plugs, allowed a more knowledgeable user or practitioner, mirimir, to give a more technically-correct description.

It seems to echo the main problem we are discussing in which users of a technology are not the same as those who design or know the nitty-gritty details of that technology.

Assumptions learned from day to day use in that technology (all cylinders have one plug, the google box is the only box I need) can so easily be proven incorrect when speaking to an actual expert in that field.

But it's arguably not such a great example, because details of engine design are generally trivial for drivers. Maybe a better example is the low oil pressure indicator. Maybe most people don't know what that actually means, but not having one can lead to severe engine damage. Years ago, I had a car with an oil radiator, and the oil line failed. So I knew to stop immediately.

What's easier to tell apart for nontechnical users? URL bar from Google search field or ads from Google results?

Wow, really? Could you expand a little? I tried to search but all I got was catch-all mail addresses and no legal issues. Thanks!

What it was about: Say, there was a review or best-price-search site (here, "service.at"), using catch-all and mapping subdomain requests to product searches. So "acme.service.at" would be remapped to, say, "service.at/search?q=acme". Now Acme sued, claiming anything containing the name "acme" on the web ought to point to their site, including the subdomain "acme.search.at", since they were the owner of the name "Acme". To almost everybody's surprise the court decided that this was true, according to naming rights, and that a subdomain containing this name, even if just implemented virtually by a catch-all mechanism, was an infringement. This also implies that "acme.example.at", which is included in the set of "*.example.at", mapped to the very same as just "example.at" is a possible infringement. – Strange, but this is as it is. And, yes, it's particularly about search engines, like Google.

(I really don't remember the particulars, since this has been some years ago by now, but we may assume that the results returned by the service weren't exactly favorable and that the particular search enjoyed a higher Page rank than the site of this vendor, or at least a rank, which brought it up near the site of the vendor in search results.)

Thanks for the explanation. I honestly would not have imagined anything like that.

"www." was used as a way of delineating what was a web address. Hence the fashion of putting that there so people knew you had to do it in the browser. Before then people used to also put the "http://" on there, and the combination of the two on vehicles/signs was ridiculous.

We're now in a web world. People know what a URL is. "domain.com" isn't ambiguous, it's obvious to man, beast or child that you type it in the browser. Most decent websites revert "www." or without to whichever is the canonical version; the one without should be that tbf.

The 'm.' is ridiculous too and ruins shareability. If the link was the bare domain, and the frontend does any switch that's needed, we'd all be better off.

https://serverfault.com/questions/613829/why-cant-a-cname-re...

My original point still stands though - we used to use 'http://' and 'http://www.' as a signal that this was a web address. I cannot believe this will still stand in 5 years time. The default is now the domain name, not the phone number.

To associate a base domain with a company identity happens to be true MOST of the time, but isnt actually true. Plus, foo.example.com follows different security rules than bar.example.com (CORS, certs, etc)

The problem here is that the precise domain has a technical meaning...but consumers are using it for a different meaning. Once that is also useful BUT NOT THE SAME.

Pretending the url matches this new meaning (and altering the display to match) serves both groups poorly.

I see no reason now to associate www. with the web version of your service. If I receive a request on port 80 or 443 for the bare domain, what's a better option than service the 99% of people who want a webpage?

You are splitting hairs on this one.

You're missing some history here (or we're talking past one another) Back then ( source: lived through it) subdomains for particular protocols were pretty common (www.example.com, ftp.example.com, gopher.example.com, mail.example.com) were pretty common, though not a requirement at all. Almost all the users were technical, so this helped users AND admins. Plus, machines were FAR less powerful back then, so anything exposed to the "public" probably didn't want to handle multiple purposes anyway.

Then non-technical users came in, saw "www.example.com" being used many places, and assumed it was part of the system. New domains either created a "www" subdomain or lost traffic (until browsers started trying to compensate). Note that what we're discussing is a switch in behavior. Prior to what the article is discussing, a browser would try the domain as typed, and if it failed would try prepending "www" AND ADD IT.

> I see no reason now to associate www. with the web version of your service

First, you still have people that type the "www" automatically because they never learned that was technically incorrect.

Second, what if you're reselling subdomains? The concept of "base domain == identity" is relatively recent and possibly temporary.

Third, what if you don't HAVE a single "web version of your service"?

The internet (and the web) has succeeded (granted, half by accident) by providing loose rules so practices can evolve inside those rules. If we start encoding the current practices in the rules, the rules no longer handle evolution well (or possibly at all).

I'm splitting hairs because hairs sometimes matter.

One takes you to the website about the project, the other goes to a random ntp server."

I do totally agree about m., but it's not Google's place to dictate that, rather it's a decision for each entity to make for themselves.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=881410...

I guarantee you, most non-tech people don't know what a URL is. People know what links are, to the extent that they can click/tap on them to get to some thing, or copy them and share/email them. That's not the same as knowing what they are.

You're making a dangerous assumption about what people know, including yourself.

But that's because it's .com. Now, there are too many gTLDs, and companies will build their brand around their use of .io, .me, .cs, .es, etc. Just the other day I saw a link that caught my eye to studio.zeldman, and I had to take a moment to hover over the link to see if that was some new branded gTLD.

The idea of the commenter I replied to that you 'had to' have a separate host or interface for each service is flat out false.

When people split it, it was over capacity or manageability concerns, but often we also set up separate hostnames for different services just because it was what people expected; often it pointed to the same hosts.

Still separated physically.

That time wasn't even that long ago.

In the initial rollout, all services were served from a single physical host with just one listening IP, which the bare 'example.net' resolved to. (Was this naive of us? You bet.) Other service hostnames (www., smtp., etc) were all just either CNAMEs to that hostname, or A records to that IP.

When our SMTP usage started to exceed the capacity of that single host, we tried to move 'smtp.example.net' to a different host. This is when we we discovered that many users were configured to use 'example.net' for SMTP instead. We had to update all of those users' configs before we could turn down SMTP on the original host. (We couldn't afford big-iron load balancers, and they were less common then - we just used DNS round-robin for load distribution).

At that point, we realized that customers were using bare "example.net" for everything - homepage, SMTP, POP3, IMAP, FTP, DNS, shell access - you name it. It was easy to remember - and it worked. So it was hard-coded everywhere - FTP scripts, non-dynamic DNS settings, etc. And this was looong before email clients had automatic configuration detection, so that was all hard-coded, too.

So we had to painfully track down all the users who were still hitting 'example.net' for SMTP, and help them update their configs before we could turn down SMTP on the original ancient host. The other services had to go through a similar painful transition.

We concluded that the only way to prevent this from happening again was to make sure that the bare hostname never offered any services at all - except for a single HTTP service whose sole purpose was to redirect 'example.net' to 'www.example.net'.

From then on, each new vISP domain had the same non-overlapping service namespace ... so that the otherwise inevitable configuration drift would be impossible.

Later, with the rise of things like email autoconfiguration, load balancers, and POP/IMAP multiplexors (like 'smunge'), we had more options. But at the time, avoiding services on 'example.net' was the only way to go (for us). Having a bare 'example.com' as the sole hostname in the browser bar was a sign of brokenness. :)

E.g. a commenter using Wikipedia's mobile site posts a link to said page and desktop viewers are unexpectedly taken to the mobile, not desktop, page.

People know what a URL is. But this issue demonstrates misunderstandings of URLs, as "www.x.y" is not necessarily an official "x.y" page.

"www" == "web address", or "m. is ridiculous" which are annoying fashions (agreed there!), but that has literally zero impact on the security characteristics, implying yet again that people do not understand URLs.

---

No. This comment is a perfect example of why this is not safe to do. It's throwing open the door to abuse.

If you're serving email from example.com, for reputation reasons you should have the bare domain's A record pointed at your primary MX.

I understand that here on HN we're focused around web-based companies, but for every other corporation, there is a plethora of other services served out of a domain -- of which web/www traffic is maybe 10%, if not less. Everything from email to voip to directory services to vpns to crazy internal apps all rely on the corp's domain/domains, and you definitely should not be pointing your bare domain at your web server (which, chances are, is some contractor-built page living on GoDaddy completely outside your own infrastructure).

In a typical company, you'd have some server serving example.com doing some or all of the above. It would then be running a light http server which accepts requests on 80/443 and permanent-redirects them to www.example.com.

This is why www matters.

Grandma: I'm typing domain.com into my browse on [random device] and it doesn't work.

Nerd grandchild: well that's because it doesn't exist.

Grandma: But it works on my other computer.

Nerd grandchild: that's because the browser tries lots of domains like www.domain, domain.org and so on when you enter domain.

Grandma: yes, I noticed that. When I enter www.domain.com, it automatically corrects it to domain.com. So that's must be the right one, surely?

Nerd grandchild: Nope. domain.com is the correct domain. It's just trying not to confuse you.

Grandma: ?

Things change. We've had something like 30-odd years of URLs. The people who can't deal with this are vanishingly small, and those that can't are likely not your target market; or they're the sort that'll just consider Facebook to be the web.

I'm not disagreeing with your point btw that some people can't deal with this - all I disagree is the extent.

24 from the RFC, 26 from the discussion that led to it, per Wikipedia.

We're going to see more and more changes that the "old folks of the internet" are going to hate. Some, or even many, of these changes will actually be good changes. We shouldn't prejudice on age.

Again, to be clear, I think this particular change is horribly broken.

PS: consider how you would guide an older person over the phone when he/she is accessing Citibank website (for which www.citibank is different website), with Chrome will "intelligently" hide essential part of the address.

And I am quite sure removing 'www' on the address bar's domains is as confusing.

I want to know that I'm receiving a degraded version of a website and that maybe dropping the m. will restore it.

Admittedly, it's not just "m", but If I _must_ use Facebook the only bearable version is mbasic.facebook.com

I want to know I'm on a faster version of a website.

(Seriously, mbasic.facebook.com allows chat, whereas m.facebook.com reminds you to install the Facebook app.)

You're the second person recently to lament mobile sites on HN. I think they're great. Responsive isn't there yet.

(This might be a result of my using a content blocker to block mobile ads, but the fact that it’s even possible infuriates me as a user. I mean, it’s text! Just show me the text!)

I agree with you 100% that responsive design isn’t there yet.

Everytime they want to use Facebook, they type 'facebook' or maybe 'facebook login' in the location/search bar.

And to get to their gmail account they might type their own email address in the location bar.

We (the HN crowd) can easily get caught in a 'bubble' where because we known the details, and those with whom we typically associate also know the details, that we extrapolate those observations to conclude that "most people" know the details.

But until one's been in a situation of providing support or training for a diverse user group, one does not see just how little technical knowledge the "average joe" (a set of which we the HN crowd are very much not a member of) has of these things. The "average joe"'s level of technical knowledge is astonishingly low compared to the HN crowd's level of the same.

They may not make up a huge proportion of users, but they still make up a huge number of people in actual terms.

Can you link to a site where these two are different?

For example, with Active Directory, the DNS A record for your foo.com domain must resolve to your domain controllers. Your www.foo.com will resolve to a separate non-domain controller web server.

I think a lot of the commenters here are thinking solely in terms of commercial web services such as twitter.com and such, but there's so much more to the wider landscape.

My $dayjob has our AD root domain the same as our public root domain. Because we implemented AD in the year 2000, and this was Microsoft’s recommendation for domain naming way back then.

And if you use Exchange, you can’t rename your AD domain, you have to rebuild your forest and migrate piecemeal. So we’re stuck with it.

The practice of using Corp.example.com did not evolve until many years after Windows 2000 and Exchange 2000 were in the wild.

So we run http redirectors on each of our domain controllers to send traffic to www.

I trained on Active Directory (AD) with a group of veteran sysadmins in 1999. I don't have access to the "Microsoft Official Curriculum" book from my class in '99 (long-since thrown away), but I have a distinct memory of a lively conversation in class re: the pitfalls of using a public domain name as an AD domain name (or, worse yet, a Forest Root domain name) during the class. It was very evident to our group of veteran sysadmins that using a public domain name in AD would create silly make-work scenarios (like installing IIS on every DC just to run redirect visitors to "www.example.com"-- just as you describe, albeit IIS didn't natively support sending redirects at the time).

I'd go further and suggest that anybody with a modicum of familiarity with DNS knows having multiple roots-of-authority for a single domain name is a bad idea. Microsoft not supporting split-horizon in their DNS server (like BIND does with 'views') compounded the difficulties with such a scenario in an all-Windows environment.

I certainly wouldn't argue that Microsoft has given exclusively good recommendations for AD domain names in the past (evidence ".local" in Windows Small Business Server), but I am reasonably certain that their documentation always suggested that using a subdomain of a public domain name was a supported and workable option.

I started deploying AD in 2000. I've deployed roughly 50 forests in different enterprises, and I've never used a public domain name as an AD domain name. I've domain-renamed all my subsequently-acquired Customers for whom it was an option (which it was, so long as they had not yet installed Exchange 2007), and have been rebuilding the Forests of Customers who made the wrong decision in the past, where it makes economical sense.

* http://jdebp.info./FGA/dns-split-horizon.html#SeparateConten...

As an aside: I really enjoy your writing about using SRV lookups. It makes me sad that SRV records aren't being as much as they could / should be.

* http://jdebp.eu./FGA/dns-split-horizon-common-server-names.h...

* http://jdebp.eu./FGA/dns-ms-dcs-overwrite-domain-name.html

* http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html

And the other comment mentioned that this was a known issue 20 years ago because the old versions of IIS did not support redirecting.

Having a disjoint DNS namespace (and the needless make-work that it creates) is the issue, more than running HTTP servers on all your DCs to do redirects. There is absolutely no practical advantage to running an Active Directory domain with a public DNS name. It's all downside. It has always been all downside, and anybody who had any experience with DNS could see that all the way back in the beta and RC releases of the product in 1999 and 2000.

http://www.pool.ntp.org vs http://pool.ntp.org

One takes you to the website about the project, the other goes to a random ntp server.

[1]: https://i.imgur.com/cEukhNu.jpg

http://www.pool.ntp.org/ redirects me to https://www.ntppool.org/en/.

http://pool.ntp.org/ takes me to an "It works!" default Apache 2 page for an Ubuntu installation. As the comment in the issue describes, http://pool.ntp.org/ takes you to a random ntp server.

If you want another example, try google.com using Google's own DNS:

  PS U:\> nslookup - 8.8.8.8
  Default Server:  google-public-dns-a.google.com
  Address:  8.8.8.8
  
  > google.com
  Server:  google-public-dns-a.google.com
  Address:  8.8.8.8
  
  Non-authoritative answer:
  Name:    google.com
  Addresses:  2607:f8b0:4009:810::200e
            172.217.8.206
  
  > www.google.com
  Server:  google-public-dns-a.google.com
  Address:  8.8.8.8
  
  Non-authoritative answer:
  Name:    forcesafesearch.google.com
  Addresses:  216.239.38.120
            216.239.38.120
  Aliases:  www.google.com

Either way, the ask was for a difference in www.example.com vs example.com. Not a difference in www.pool.example.com vs pool.example.com. In the latter case, the different subdomains will still be shown (AFAIK).

>Even if you ultimately end up at the same site through redirects, you're clearly not going to the same site initially.

Which is nothing that an end user is going to care about and doesn't provide an example to the asked question.

http://www.pool.example.com displays as http://pool.example.com

Here's a gif: https://vgy.me/61I0DA.gif

For fun I'm going to set up a www.www.www.www.www.www.www.www.www record.

http://www.www.www.www.www.www.www.www.www.www.example.com shows as example.com

E: I'll add it to my certs later but I did it: https://www.www.www.www.www.www.www.www.www.www.www.www.aish...

E2: http://www.example.www.example.org shows up as example.example.org - this is fun.

I just found the same thing. How exactly is this a feature? What an insane decision.

How would I differentiate between loadbalancer1.www.intranet and loadbalancer1.intranet? THOSE ARE NOT THE SAME.

http://www.pool.ntp.org/ http://pool.ntp.org/

https://www.citibank.com.sg/ https://citibank.com.sg/

Plus, this actually removes any www part of the domain.

So subdomain.www.example.com shows as subdomain.example.com

Why even open that can of worms?

B) Consider subdomains for test-purpose like "www.test.www.example.com" (now displayed as "test.example.com", which is actually not even the root of the specific subdomain).

C) Users unsure, if they are on the full-featured or a reduced mobile site, when "m" is hidden.

D) I may actually want to have a service agnostic default host at the root and subdomains for dedicated servers (like "www", "ftp", "mail", "stun", "voip", etc). Maybe this one just returns a short text message by design, if accessed on port 80. Not every domain is just about the WWW. (Edit: While we may assume that such a server would forward in practice, this may be assuming too much.)

> Can you link to a site where these two are different?

There are 3rd level domains where everyone can register "www.{TLD}". E.g., .com.kg, .net.kg, .org.kg. Look at the www.com.kg. It's also available as www.www.com.kg. Or www.org.kg that's in fact www.www.org.kg. If you display just the last part (com.kg, org.kg), does that mean that you're viewing the root website? Nope, that doesn't. That means that chrome is fucked up.

One of my school's websites: I can't remember what it was and this was before I understood what the difference is, but www worked much better than without iirc.

This also applies to m.*, so literally any web-app with a mobile version.

https://devcenter.heroku.com/articles/custom-domains

I haven’t tested it but it will most likely show up as domain.com in the address bar and will result in an error show to the customer.

If chrome wants to strip www as it’s essentially the same domain.com they can submit an RFC and not just decide for everyone. Honestly I hope they start making more stupid decisions like this so ppl move to Firefox so we have more competition.

Yup, that's on the developers. Hopefully this fix will make it so that it will be easier to setup DNS with just one domain instead of 2. Props to Chrome.

Will they? I find it very unlikely that many users would even check the URL in the first place, let alone understand that m.foo and foo route to different places.