>Domain names provide the internet much more user-friendly way of referencing servers
Too bad some people decided that this "friendly name service" should also be the centerpiece of all encryption on the web, as well as the only thing that prevents websites from reading each other's client-side data.
(Please note that in 1993 a typical PC would spend significant amount of CPU to decrypt even 3des, and encryption beyond 40 bits of key was restricted in the US and not allowed for export.)
The part I don't fully get is how TLD servers, like .com work. Do they have a list of registrar DNS servers defined, and they ask them if somebody wants to resolve a domain they do not know about?
Registrars provide the nameservers you give them to the TLD itself. So, resolution doesn't depend on the registrar's infrastructure unless you're using the registrar's nameservers directly.
It works like this:
Root -> TLD -> NS -> NS -> ETC.
Thank you for the reply. Can you explain how "provide" works in your first sentence? How does the .com TLD server know who registered google.com ? Seems like TLD servers still have to know the list of possible registrars where one can register a domain for their TLD.
Yes, registrars have an agreement with the TLDs and have API access that allows them to submit requests for DNS delegation, transfers, registrations, creating glue records etc.
The registrar will send a request to the TLD to essentially ask that they delegate your domain to a specified nameserver which will add records to the TLDs zone for your domain
Interesting article but needs a bit more depth, for instance it mentions incredibly briefly the MX record
> The PTR (or reverse) record query is used to validate that the IP address is assigned to the same host that is resolved in the Mail eXchanger (MX) record query
It does not explain that when you try to send an email the MX record is what is referenced as to where the email should go, it also neglects to mention "round-robin" DNS or Anycast DNS which are used by to distribute the web and an important part of modern day internet usage.
DNS was always a thorn in my side. I never liked the way it was a single point of failure and the first thing attackers looked at when analyzing traffic. Luckily with things like DoH[0], looking at DNS traffic is a lot less invasive in terms of privacy.
And even more lucky, and something that serves us all is Mozilla's attempt to bake this as the default (DoH) in their mainline browsers. My only complaint being that they use Cloudflare as the default & Cloudflare acts as a honeypot for Internet traffic. If they (Mozilla) could move away from Cloudflare as a partner then that would be great. (Of course this demands a new privacy-respecting provider to serve requests for the user :p)
True, however the failure rate of all of the webservers you might want to connect to is much lower than the DNS server's.
Moreover, the DNS failure might not come from the DNS server, but a misconfigured computer/router/DHCP server, etc. And it depends a lot on your DNS server itself. It is a single point (chain, if you want) of failure, and tends to fail quite often, in my experience.
That hasn't been my experience w/ DNS. If you want to pick on single points of failure, there is a whole chain of SPOFs all the way between you and the server you are connecting to. Many of them can't fail over. At least with DNS there is generally a good failover configured by default.
What about the failure rate of all the DNS servers? It's not like someone set up a Windows Server box and we all share it. Google's DNS server at 8.8.8.8 for example uses some sort of complex multihoming/multicast setup and is globally distributed. I trust DNS to work more than any other service on the internet. It's a triumph of software engineering. The Roman aqueduct of the internet.
AFAIK they use Anycast for the multihoming [0] - It follows the normal routing process, but the anycasted network is announced from multiple sites instead of just one.
AFAIK Google have ~19 data centres, and DNS / 8.8.8.8 is probably being served from all or most of them. So it is indeed very reliable.
> Moreover, the DNS failure might not come from the DNS server, but a misconfigured computer/router/DHCP server, etc. And it depends a lot on your DNS server itself. It is a single point (chain, if you want) of failure, and tends to fail quite often, in my experience.
Misconfigured networking is going to make networking fail anyway. DNS is an amazingly resilient system since it has had decades to mature.
My biggest concern is that Mozilla do not offer the option of using DoT (at least in the current stable channel). You can configure a different DoH server, but not a DoT server.
There's some textual detail in the video that seems important to his presentation which could be missed at 2x/1.5x and I like listening to things at normal speed. Listening any faster would probably make his speech affectation even more deeply annoying. It's just a terrible presentation.
When you're knowledgeable and your content is quality, I don't understand why you'd need to dress like a cat during the videos. Is it a gimmick for attention? If so, is the assumption that those interested in DNS somehow intersect with those that enjoy seeing 30+ year old men dress up like a cat? Maybe I'm overthinking this - the guy does seem to have quite a few views, so apparently it's working for him.
Which is it? " " or ".". That's an easy way to confuse people whilst trying to be complete. This is supposed to be a 101 class.
. is the designation for root in DNS but it is not spelt out except where it is!
For example: In a (BIND) zone file you terminate an entry with . otherwise it is considered relative to the "current" domain. When you type into your browser something like www.example.com you don't include a trailing dot.
Finally, the empty string was shown like this: " ". That's a space.
