All fully-qualified domain names end with a dot. The dot is effectively the label for the DNS root. Most tools (e.g. browsers) automatically assume a trailing dot.
[Edit] Interestingly, if I add a dot to this URL, after the domain-name, it works, and I get essentially the same content; but the styling is quite a bit different. I imagine it must be to do with the way stylesheets are referenced from HTML.
[Edit-2] I deprecate the use of the term "DNS root" to refer to the domains .com, .net, .org etc. These are top-level domains, not "roots".
A few years ago there was a big "internet outage" in my country. The people responsible for the national TLD had forgot to put the trailing dot in their zone file somewhere, meaning lookups of example.tld failed -- but due to how search domains were configured by their servers, example.tld.tld did resolve!
Sometimes me and my friends refer to it as "the .tld.tld incident".
One of my first 'learning a language' projects was to write a DNS query in python from scratch. Basically, writing and reading bytes directly. Read the RFCs, made sure the format was right, wrote a parser for the reply and...fail. I remember pouring over every detail for about an hour before realizing the qname was missing the trailing dot. So, apparently at least some number of resolvers really demand it.
You are probably misremembering, as DNS queries and responses don't contain dots (as the article points out). Maybe you were missing the \0 terminator after the last name segment? In which case it's quite clear why the request was failing, as it would have not been unambiguously parseable.
You're probably right, this was nearly 20 years ago. I only remember because my wife remembered my excitement and always used it to call me a nerd, adjusting her nonexistent glasses, snorting, and say 'i was missing a dot.' In good fun.
If I had to guess, I had the function that accepted the query name call a function that split on dots to do the encoding, meaning a missing trailing dot means a missing null terminator.
For example, you could have a project where, by convention, the app servers are just called as http://app/ the db servers are called as db etc. Saves lots of configuration effort. All you have to do is have a local DNS zone that keeps the traffic within its current setup.
That way you don't even need separate app configuration for separate environments, and can transport an application and its configuration without changes into the next environment.
(Sole exception: you likely want to inject different cryptographic keys to deal with (mutual) authentication).
Thanks to Julie for this; but I'm still a bit confused.
Does anyone share a suspicion that these myriad of anachronisms and bits of weirdness creates unnecessary complexity that swim through the system like a goblin in the machine? And that, if with 20/20 hindsight we just simplified things a bit, that many of our systems would be much more resilient and easy to manage?
I feel that we hacked the internet together, and in the impending rush to build more and more on top of it, we just resigned ourselves to the mess.
None of this (well, most of it) should be inherently hard. If we 'did it with foreknowledge' I wonder if all of these IT level networking issues would be pedantic, i.e. something you read a few quick docs and away you go. Everyone an expert pretty quick.
Merely looking at the options for my DSL device, my god man, even after all these years in tech, I'm still a bit bewildered.
Even at the consumer level, if I go over to someone else's house, I can't 'change the channel'. No idea what I'm watching, or the abstractions behind how it got to the TV.
A lot of them, absolutely, but this particular one had for a long time (arguably still has) useful properties. Like if you're inside same network you can just connect to "db" server and don't care what's the rest of the FQDN is. Similarly with typing "ssh app1" vs "ssh app1.example.com"
Starts to matter where your k8s address can be <service>.<namespace>.svc.kube.example.com
> Merely looking at the options for my DSL device, my god man, even after all these years in tech, I'm still a bit bewildered.
A lot of DSL dumbfuckery came from telco. For example, ADSL uses ATM framing which is 64 bytes, with 48 bytes of payload. And it is fixed size packet which means mere TCP ACK, with all header overheads, won't fit and you need to send at least 2 ATM packets for each TCP ACK AND waste some bytes in them too. ATM was first used for voice which is where constant size came from.
The VPI/VCI settings are also directly related to ATM protocol
And why 48/64 byte ? Coz EU wanted 32 byte payload (coz they wanted lower delays) , US wanted 64 byte (coz they wanted lower overhead) and they just split the difference in the middle.
Why the fuck they applied it to inherently point to point ADSL ? Who the fuck knows, you'd think throwing away 25% bandwidth on ATM header would be bad for residential service over shitty wires but they apparently didn't care.
It's not considered a repost unless it has already gotten attention recently. Things like time of day or day of the week or just randomness can affect if a post gets the discussion is deserves, so HN does allow reposts.
From the HN FAQ[1]:
> Are reposts ok?
> If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates.
> Please don't delete and repost the same story. Deletion is for things that shouldn't have been submitted in the first place.
Often I submit a link, but it doesn’t even get a submission made. Instead it just counts as an upvote on the same link that somebody else already submitted.
Yes. If you were on a machine with an actual domain name in .com, you could enter "foo.com" and be directed to "foo.com.com". Which is part of an ad farm. In hard to read type at the bottom, it says: The third-level domain name in the URL for this page was user-generated based on the com.com third-level domain you attempted to reach. The content and/or advertisements you see on this page are generated based off this user-generated third-level domain. For example, if you try to reach “example.com.com” you will see content or advertisements based on the word “example.”
On Firefox, you can type a dot at the end of the domain, and it successfully loads the page. But it seems to consider the domain with dot a different from the one without, for purposes of cookies etc.
Reminds me of when I was in school, and you could access blocked sites by appending a dot. Presumably their firewall had a bunch of domain block rules that didn’t take this into account, and the vendor didn’t think to check for both variations of a domain.
I once submitted a bug for Mozilla, it got shot down:
The site does not work as expected if you use https://youtube.com. in Firefox.
This can be a security issue, if you are on corporate or public-wifi DNS that is a security issue, too:
if the default search happens in companyname.com. by DNS setting of that network and they offer youtube.com.companyname.com., you will get youtube.com served from evil companyname.com
Why does that nowadays still exist? A good use case, if you are lazy, is that you can visit webmail.companyname.com by typing https://webmail and being in corporate (virtual) private network, which I frequently do.
All fully-qualified domain names end with a dot. The dot is effectively the label for the DNS root. Most tools (e.g. browsers) automatically assume a trailing dot.
[Edit] Interestingly, if I add a dot to this URL, after the domain-name, it works, and I get essentially the same content; but the styling is quite a bit different. I imagine it must be to do with the way stylesheets are referenced from HTML.
[Edit-2] I deprecate the use of the term "DNS root" to refer to the domains .com, .net, .org etc. These are top-level domains, not "roots".
There is a single root, and it's name is dot.