Hacker News Reader

Comment by dxuh | Hacker News Reader

My story is not nearly as cool, but one day I could not visit my bank's website via "<bank-name>.tld" and I thought something was broken. After a few days I called and they said that it works fine for them and there was no recent problem and they told me to just type "www.<bank-name>.tld" into my browser, which.. worked. The person on the other end of the phone call clearly thought I did not know how to use a computer (arguably I actually don't, because I did not try out prepending "www." myself). I explained to them that it worked without "www." in the past and this likely was a mistake and they should inform someone, if possible. For a while I called them every couple of months and after about 2 years I finally got someone on the phone that did not think I am being an idiot and calling for something silly and a few days later it was fixed :)

View on HN

I bitched and whined about Google Flight service being useless for searching for long business class flights with a change in them, because it would assume you were fine with the shorter leg being in economy -- even if the shorter leg ended up being 7 hours long. I did eventually get one of their PMs on LinkedIn to apparently take it seriously, but I note it's still very broken on their site putting in a Vancouver to Bangkok flight (10hr in J YVR-NRT, 7hr in Y NRT-BKK)

Agree that Google Flights isn't perfect, though I do find it better than any other flight search engine. Especially the 'explore' option is so good for finding very cheap flights across Europe.

> I did eventually get one of their PMs on LinkedIn to apparently take it seriously, but I note it's still very broken on their site putting in a Vancouver to Bangkok flight (10hr in J YVR-NRT, 7hr in Y NRT-BKK)

How long did his LinkedIn say he was still at Google afterwards? I have to imagine that sometimes being reasonable in the face of infallible bureaucracy would either drive you crazy enough to leave or drive your coworkers crazy enough to get someone to make you leave.

If you're really old-school, you know that it makes sense to require the "www" prefix. Why should the machine pointed to by the bare domain be the web server, instead of for instance the FTP server or the Gopher server? It's not necessarily the same machine which provides all these protocols, and putting the web server there is privileging one protocol over another.

Of course, that ship has long sailed; everyone uses HTTP now, even for things where it doesn't make sense, and one should at least have a tiny web server pointed to by the bare domain which redirects to the correct "www"-prefixed address. The fate of bare domains was sealed when browsers started prefixing "www." and suffixing ".com" whenever one typed a bare word in the address bar.

So what protocol should the bare domain point to in order to not privilege one protocol over the others? Or should it not resolve at all?

> Or should it not resolve at all?

Exactly.

To put it simply, in that old-school thinking, the bare domain should have only SOA and NS (these two being required for the domain to work), MX and SRV (these two being protocol-specific), things like TXT for SPF, and the DNSSEC stuff, but not A or AAAA or CNAME (and AFAIK using CNAME in a bare domain can cause problems, since it's not supposed to be used together with anything else, and a bare domain always has at least SOA and NS).

This is inaccurate. There's never been a reason to not assign an A record to @.

The historic structure of DNS is that names were given to systems within a domain. So you might have pikachu.company.com, squirtle.company.com, etc. It wouldn't make sense to just assign an address to the domain itself because we simply didn't have the technology to drive sophisticated consolidated sites on one system. You might need to get some files off one host, and some off another. We didn't have load balancers, and we often didn't have drive space to hold everything in one place.

MX doesn't have this problem of scale, as MX specifies multiple systems per SMTP spec.

Sometimes people would create www.pikachu.company.com, and sometimes they wouldn't. The www prefix was sometimes a handy default, but certainly wasn't ubiquitous.

The real change here is the rise of single endpoints for a domain. This began by assigning "www" as place to look for web content for the entire domain and almost in unison people began to also add A records to the domain itself. After all, why wouldn't we?

CNAME is different, of course, because CNAME aliases all record types - not just A records.

Domains do not point to protocols. They point to addresses, to systems.

Any protocol can be used to talk to a system. They are all equal.

If you're opening a connection to TCP/80 it's a safe assumption that you want the web server.

That said, I think it's a shame SRV hasn't been more widely adopted.

> If you're opening a connection to TCP/80 it's a safe assumption that you want the web server.

Yes, and if you're opening a connection to TCP/21, it's a safe assumption that you want the FTP server. But what if these two are different machines, possibly even in separate and distant networks?

There's nothing stopping your routers from looking at the TCP port number to decide which network/host to route packets to. ;-)

What if we called these routers with L4 decision making "load balancers"? ;)

"it makes sense to require the "www" prefix."

Not at all. It makes sense to allow it, but never makes sense to require it.

"Why should the machine pointed to by the bare domain be the web server, instead of for instance the FTP server or the Gopher server?"

We use ports to distinguish protocols. A more salient question is: Why should there only be one web server in a domain?

In fact, it used to be common to have dozens of web servers on differently named hosts in a domain, all of which might be running several internet servers like http, ftp, etc. If you're actually old-school you'll remember knowing the names of individual machines at a site and visiting urls like http://foo.building.company.com

There are some technical reasons why you might not want your web server's A record in the @ for a zone, but they mostly no longer apply.

www has never, ever been required.

> instance the FTP server or the Gopher server?

Lol, I see your point, but if a bank has an un-firewalled FTP or Gopher server on their domain there might be a couple of bigger issues to contemplate

I recall getting the "no-www" button for my weblog footer table.

> browsers started prefixing "www." and suffixing ".com" whenever one typed a bare word in the address bar

Your browser does that? Mine opens a (hard to change) default search engine.

This does work if you press Control+Enter instead of just Enter.

Nowadays they do that, but in the past (think of the old Netscape and MSIE days) they used to just prefix "www." and suffix ".com"; there was no "default search engine" back then.

Actually, what makes sense is to put the most important server people may access from your systems at the shortest possible host name. If you're mainly doing FTP file hosting, it makes sense for your FTP server to be domain.net, while your less used web server can live at www.domain.net. Bonus, if you can, run your FTP and your HTTP servers on the same physical system, and allow the L4 port to determine which to talk to.

Of course, it's even better if you can use an L4 load balancer, put that on the root domain, and tell it what internal machines to access based on port.

I always wanted user agents and DNS to do a little bit more coordination here. The user agent should ask the DNS server "how do I get to http for example.com", and then DNS should reply with an IP address and a port number (so if you can't bind 443, you don't have to). Additionally, these records should have extra information, perhaps related to location (so that the entire world has a consistent view of A records associated with the host, but can still find the CDN edge node closest to them), and health checking (so if you have 1.2.3.4, 1.2.3.5, and 1.2.3.6 as options, and 1.2.3.6 is being rebooted, the browser could test them all and use the one that is supposedly working). Oh, and maybe we could go totally crazy and add some information about authentication, so the user agent could get a token from its identity provider of choice and send that with the initial request (if the user's preferences allow it), and save engineers from ever having to implement sign up / sign in / account recovery / etc.

As it stands now, we have conventions for port numbers, and load balancers / VIPs for mapping the address in the DNS response to an actual computer running the desired services. We could kill a lot of complexity by letting user agents do the work of the load balancer here.

(The port number is a personal pet peeve of mine. I want to run HTTP/3 for my website, but my cloud provider's load balancer can't represent a configuration where port 443/TCP and port 443/UDP are both managed by the same load balancer. Interestingly, browsers are configured to do HTTP/3 with an Alt-Svc on an HTTP/2 or HTTP/1.1 response, which includes the port number. Chrome refuses to use anything other than port 443, while Firefox is happy with something like 30443. As a result, I have to reconfigure my network, or my cloud provider has to fix their bugs... and there is just no need. The browser could do this for me for free!)

You need a layer 4 load balancer instead of a layer 7 balancer in that case.

It's worse than that. It seems to be a Kubernetes defect around merge keys; using the port number and not the protocol + port number. https://github.com/kubernetes/kubernetes/issues/39188 But it is possible to create Kubernetes services that work correctly serving UDP and TCP on the same port; look at any old kube-dns/coredns service, for example. Indeed, I can easily create such a service for my HTTP proxy (sending TCP 443, TCP 80, and UDP 443 to my L7 proxy), but the cloud provider's software explicitly rejects it because it can't possibly work. (Meanwhile, going into their UI and modifying their object behind the k8s reconciler's back works fine, but not well enough that I trust it to announce HTTP/3 support.) I think they got spooked by a bug, but didn't realize it's a corner case and not something that happens 100% of the time. I hope it will be fixed, because I'm pretty sure they added UDP support to load balancers specifically for HTTP/3.

you are kind of describing DNS SRV records. but browsers don't use it

DNS SRV records were designed for that. SIP makes heavy use of them; for example:

    _sip._tls.example.com SRV 5 100 5060 sip.example.com.

That means that TLS-protected SIP is on port 5060 on sip.example.com. In theory you can do this for http/https as well, but in practice, unfortunately, browsers don't do SRV lookups.

I don't think this is a good idea at all. Most importantly, you can't rely on the client for doing load balancing! Load balancing is about making sure that one user can't affect the service quality for other users. Exposing all backend servers directly to users and asking them to choose which to use is a recipe for denial of service attacks and floods. Not to mention that LBs can help with auto-scaling based on health checks, but you can't rely on client health checks for that, and DNS would be entirely out of the loop.

DNS as used most commonly by far on the internet is a non-authenticated non-encrypted protocol. Everyone with access to the network can see what DNS requests you are making, so putting even more information in them is not great.

Further, DNS is already a single point of failure, but it at least has the advantage of relatively long cache times - so clients who already resolved the IP they need can keep working. Relying on the DNS Server instead of a separate LB seems like it would greatly increase the risk that you'd constantly be updating DNS records (for example, when your service auto-scales, you have to add/remove DNS records now) meaning you'd want very very short caches etc.

Finally, fixed port numbers are a critical part of having a low attack footprint. Even if you convinced browsers to talk to your service on port 30443 automatically, you'd soon discover that many corporate customers can't reach your service, because their network/firewall blocks outbound traffic to unknown ports. Having dynamic port numbers for protocols would be an anti-feature in most cases.

DNS is already doing the most that it should do. Bloating it with even more responsibility should be avoided, not encouraged.

Make the common case easy and the other cases possible.

you wanna know a secret? well when indian income tax department announced a new web portal, they made a big deal out of it but guess what, they still haven't gotten the memo how incompetent they are and that they know it and don't care.

case in point, www.incometax.gov.in works but incometax.gov.in does not.

haven't you learned in domain setup tutorials to set your A records straight? i guess they didn't and its been like 1.5/2 years and its still a problem. go figure

Talking about incompetence, Why are most Indian government websites look like they were designed in the 90's?

Because they were either designed in 90s or are being approved by people who are stuck in 90s. Like you still can’t use back/forward buttons, paste text on many indian gov websites

at least on the banking side, i do suppose that is a good thing.

looking at all the scammer payback videos, most of the scammers take your remote tool, make you open the banking website and then they edit the source, reload and here is your money. Indian banks don't let you do that, they make you give an OTP for every transaction, if you reload, you get logged out, you can't paste or open inspect element which actually makes these scams very very difficult on indian netbanking customers....

that makes me wonder,why don't american banks have reload security for one? like if you reload a page it should log you out?

> Indian banks don't let you do that, they make you give an OTP for every transaction, if you reload, you get logged out, you can't paste or open inspect element [...]

I don't see how these four things are related. Banks in the Netherlands require 2FA (i.e. smartphone or dedicated 2FA device) for every transaction, but this does not prohibit you from pasting an account number or reloading the page.

In particular, I don't see how opening the developer tools and reloading the page are related. If you reload a page, changes you made using the developer tools are lost.

> like if you reload a page it should log you out?

why would you do that? reloading is a normal process, what if you are on a bad connection and sometimes files don't load? you hit reload and now everything works...

one of my least favourite things about the GCC countries is an apparent enduring fascination with disabling paste on password fields

wanna know more about this incometax.gov.in url that doesn't even work without www.incometax.gov.in ?

apparently the government spent like INR 4500 Crores or almost $ 500 Million US building this.

it regularly crashes, has weird bugs, half the website doesn't work most of the time....

It's changing slowly tbh.

Some stuff still uses the LCB look ASP.net, but the newer .nic websites seem to be much better done.

Until a year or so ago 'nasa.gov' didn't work; you had to use 'www.nasa.gov'.

https://blogs.nasa.gov/nasadotgov/2011/05/31/post_1306860816...

FWIW I don't understand why forwarding the bare domain to the www subdomain would increase traffic so much so that they'd need to provision extra servers...

... but hey, I'm not working for NASA, so I can't say.

I'm 98% sure whoever wrote this had no idea what they were talking about.

Premierleague.com only fixed this issue around 2015-2016. I first noticed it in the early 2000s

Reply on news.ycombinator.com