Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes. Everything I do is designed to deal with those conditions. I never assume a powerful computer or a reliable connection. But nothing is ever "once-size-fits-all". There could be situation where, e.g., a website's authoritative DNS servers are barely functional, but a cache like Cloudflare's has a copy of the RRs. IME, that is quite rare.

I store the RRs permanently in a custom zone files once I retrieve them. Then query the data from a loopback-bound authoritative DNS server. No subsequent queries for those RRs leave the network interface. This is faster than 1.1.1.1 .



Yes, I do get that your system caches the authoritative servers, but as I said above there are times where the connection is "weird" and some DNS revolvers are better-equipped to solve them. Some authoritative DNS administrators wrongly used (for example) MaxMind GeoIP (don't do this, use ASes to differentiate connections when it comes to DNS steering) to steer their DNS requests, and it ends up that the user is getting a suboptimal server.

Here's a real-life example I encountered: Wikimedia (which operates Wikipedia et al.) has historically routed Japanese connections to Singapore, where they're geographically close, but due to how the internet backbone in the area works (it goes via Hong Kong, where switching time adds up to the latency) it made more sense to route them to WM's Los Angeles servers (and some ISPs have done this before WM has formally rerouted it to Los Angeles).

Or even a more frustrating one: I have routed SingTel users to Hong Kong despite also operating a server to Singapore because their routing is so bonkers that SingTel will route the connection to America and back just so they can access a server that they can physically go by using the metro (yes, I have contacted their NOC. No, they haven't changed anything).

Will this break DNSSEC? Absolutely. Will ordinary users care? While I'll care about correctness, more users will care about the speed and quality of their connection rather than correctly routing to a suboptimal server.


Sounds like you would want more manual control over routing if you could have it. You and I want the same type of thing. I'm an end user not an administrator. I just prefer manual control over DNS. When I do purely authoritative lookups I see all the queries made. The way admins have configured things, it can be grossly inefficient, not to mention brittle. With one popular CDN, I can see something like seven queries just to resolve the IP address of a single domain name. I can alleviate some of the inefficiency and unecessary dependencies manually by querying certain servers directly. Geo-based routing makes sense sometimes (most times, perhaps) but, as you point out, not always. Sometimes with CDNs I will retreieve content from certain servers that so-called "smart" DNS-based routing would not recommend. Because in some cases they are in fact faster for me. The point is that it should be the user's choice which server to use. "Smart" stuff, letting others make decisions for us, should be optional not mandated; because, let's face it, this stuff isn't always as "smart" as it could be.

I should clarify what I meant by "there is no technical advantage anymore". There was a time when "personal" computers and internet were so slow, users could not be expected to do their own lookups. No one could be expected to run "BIND" on their own computer. Running something like Unbound, "Pi-hole" (dnsmasq) or countless other options was not feasible like it is today. A shared DNS cache run by a third party made sense. What I am suggesting is those days have passed. One of the authors of the popular O'Reilly books on DNS, a so-called "DNS expert" that most DNS administrators followed back in the early days, more or less admitted this many years ago. Technically, no one needs DNS "nannies" anymore. Users have the ability to exercise some manual control, if they so choose. I do my own DNS-based blocking.

Anyway, that's how I see it. One person's opinion.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: