Comment by m3047 | Hacker News Reader

Comment by m3047 | Hacker News Reader

Parent Full thread

Hi.

The root servers use anycast, so you can figure there are "several" nameservers with the same address scattered around the 'tubes, and distinguished by the routes announced in different places.

There are and have been alternate roots since the beginnings of internet time, notiwthstanding Mockapetris' opinion that people who advertise false root should be shot.

Writing a decent recursive nameserver is nontrivial, I've written several for specific purposes but generally I use BIND.

I concur that running a recursive server for your SMTP server is best practice because network intelligence is oftentimes utilized for spam / malware mitigation. I'm unclear why you need it for e.g. HTTP.

> few root servers with a few people that have keys to them

Well, kind of. As said, there are quite a few root servers although the control is in the hands of relatively few. Maybe you realize this, maybe you don't but yes there are keys for DNSSEC. I'm not sure exactly how it works, but several people have to cooperate to sign the root zone. They have key signing ceremonies which are televised online. During COVID I watched them drill a lockbox, because one of the keyholders couldn't make it to the ceremony; fun times.

I don't like anycast because I think it requires BGP and backbone access or similar expensive stuff. DNS should have had regions in the main protocol so that people in EU don't use a DNS server in Asia f.ex. But it's too late for that now.

I might use geolocation on my DNS replies, and unfortunately here is the 2nd flaw of DNS, the replies should follow the sent order, because as the protocol works now you either get round-robin redundancy or direct your users to the hopefully correct continent, you can't have both!

As for my brute force workaround: I use IPs for connecting as often as I can, and the hostname is just for virtual hosting to work.

So all my applications have euro., asia. and iowa. prefixes and when outside of a browser I can "hardcode" the IPs so that extra second of lookup never hits my users.

Ofcourse that requires fixed IPs and open port 53 which is something every home fiber owner should ask for to distribute the internet again!

Most recursive resolvers try to figure out which authoritative server for a domain responds fastest and use that one. If you've got enough DNS requests and enough DNS servers, it kind of works out ok without anycast. Although, I've been told that 4 authoritatives is the optimal number, which is limiting (you can do more of course, but a random internet use recalls but can't find a writeup suggesting more wasn't great in some semi-failure cases, and you can cargocult top X domains which seem to do 4 for the most part)

Advanced protocols may be able to use SRV records to distribute further traffic, but web browsers can't, so kind of stuck for them.

> Advanced protocols may be able to use SRV records to distribute further traffic, but web browsers can't

Not for lack of trying from the DNS community, more like web browsers won't. However if you haven't already you should take note of the HTTPS and SVCB DNS record types: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...

Personally I don't see a use case other than advertising or surveillance for a web page doing 20 DNS lookups (and that includes CNAME chains). Having said that...

> extra second of lookup

Hrm. Sounds like you want it to work like today's internet, with today's internet services.

You're using radios, what's your traffic shaping look like UDP vs TCP? I know from experience that media devices spam the crap out of wifi (weird stuff too, like multicast MAC addresses). A common scenario is a TCP channel for control, and an accompanying UDP spew for the actual content.

DNS resolution according to the standards which were promulgated in the 1980s uses UDP, unless a (UDP) reply indicates that the request should be retried with TCP: there is no use of TCP, as in there is no "and if all else fails, retry with TCP".

For media, this provides a first mover advantage: whomever resolves their service and starts streaming first attenuates DNS resolution for the latecomers. I actually wrote about this on HN and wrote a demo TCP-only forwarder (which also conveniently does DoT) https://github.com/m3047/tcp_only_forwarder but nobody was very interested.

Point being, if DNS resolution is failing or slow and you can't / won't do traffic shaping you might want to force DNS over TCP / TLS.

There is MDNS for example. Also in terms of alternatives to BGP, you're still going to need to figure out routes. And / or, you going to have to detect loops. Different "anycast" nodes could use something like this to detect each other's presence. You could use the (IP) TTL to limit how many hops a packet will traverse looking for a particular server (no similar concept at the MAC level AFAIK). I hope you have fun!

https://www.youtube.com/watch?v=CVukpkWAp4Y

here is a link to the key signing ceremony if, like I was, you are interested.

Maybe it's the englisher in me, but I was hoping for more grandeur, perhaps some kind of ceremonial mace or at least a benediction.

God save the internet, and its fascist regime!

> but yes there are keys for DNSSEC

why would you want DNSSEC?

DNSSEC works fine for me, why not? When people break it, I get early warning. When people implement it and don't utilize it, I find out. But in all seriousness my sights are on DANE and ultimately eliminating Certificate Authorities.

It's not happening, for multiple reasons.

https://educatedguesswork.org/posts/dns-security-dane/

Reasons not to DNSSEC? The biggest one is that it exposes you to misconfigurations that happen routinely even at large sites (because DNSSEC is hard to manage), for no actual security benefit. The "no actual benefit" part is my big reason, though. DNSSEC is pure path-dependence; people do it because they think they should be doing it, because a bunch of people put a standard together back in the 1990s and have been lobbying for it ever since.

If you proposed DNSSEC today, rather than in 1994, it would go nowhere. But since it's been an IETF effort for 2 decades, it now has a life of its own.

I upvoted you because you're clearly a fanatic in this space. (Hello!) However, I disagree. Viktor punches above his weight (we've gone a couple rounds).

I'm against CAs because they are fabrications who do a beauty show primarily for the browser makers, and everybody else has to deal with the fallout (eschewing political comparisons... deep breaths...); they also provide cover for "infrastructure vendors" who mint their own CAs.

They say that DNS encapsulates the two most difficult problems in data science: naming and cache expiry (I'd add delegation). So if we already have one global tribe attempting to solve this problem, how much of our attention budget do we really want to spend on people who have discovered this "new problem": CA chains: really?

There are (Derrida-not) misconfigurations which routinely happen (PeeWee Herman "I meant to do that") which clearly benefit from DNSSEC. Surely noone would configure their network to trust the name of, say a file server, which serves the executables for your short order diner. Dang. It's such a brilliant idea. Why doesn't it pan out? JasBug hasn't been solved, other than M$ saying "don't do that". What if the DNS solved it?

We're writing here for the public so yes, "CA chains" is technically inaccurate. I don't care.

Reply on news.ycombinator.com