Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choosing a Public DNS Resolver

evilbit.de

Post reply on HN
Print view View original

111–120 of 143 posts

Re: Choosing a Public DNS Resolver

#111

Post by vimda »

aetherspawn wrote: post #82

Use your ISPs official DNS so that you get the shortest path possible from the ISPs handoff location to the CDN (and overseas trunks), not a generic DNS that doesn’t know about your ISPs layout. ISP: 1ms to Cloudflare Cloudflare: 10ms to Cloudflare Thank you for your attention to this matter. Edit: will clarify, this advice applies to countries with good privacy laws and no national surveillance i.e. not the USA

Cloudflare famously does anycast so the DNS answer you get is the same no matter where you're coming from. Your numbers there can't be attributable to DNS. On the contrary, Cloudflare can short circuit the recursive lookup for any of their properties, providing potential speedups at the resolution stage, and can use eDNS client subnet to route based on where you are if necessary

Re: Choosing a Public DNS Resolver

#112

Post by KomoD »

amiga386 wrote: post #104
marginalia_nu wrote: post #98

Earlier quoted context omitted.

Changing your DNS does basically bupkis for privacy, since they can still read your DNS queries and SNIs.

It doesn't fix privacy but it does work around censorship. Has a court or the government ordered your ISP to usurp its enemies' DNS records? If so, you need to talk to a different resolver, not constrained by your government or courts.

> but it does work around censorship

* for the countries/ISPs that don't also hijack all DNS

https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_...

Re: Choosing a Public DNS Resolver

#113

Post by 1vuio0pswjnm7 »

Why only 29

Is the author suggesting this represents the actual number of open resolvers on today's internet

How can any consideration of "privacy" or "security" of DNS not also consider SNI

SNI allows third parties to see when the user tries to connect to an address published for a domain name. It can allow third parties to interfere with such connections

DNS only allows third parties to see when a user looks up an address published for a domain name. To associate non-DNS traffic with these queries requires assumptions about the software that is sending them

Hence it is not surprising the advertising companies that control the popular web browsers want users to choose DoH _within the browser_ or corporate OS, deceptively labeled as "private DNS"^1, so these third parties can more effectively correlate these queries with non-DNS traffic from browsers or software running on corporate OS

1. Perhaps these companies will be sued for these deceptive claims. For example, users have successfully sued for deceptive claims about "private browsing"

Re: Choosing a Public DNS Resolver

#114

Post by toast0 »

brynx97 wrote: post #61
zinekeller wrote: post #55

Earlier quoted context omitted.

Some CDNs (like Cloudflare) use solely BGP anycast steering for routing to the "nearest" server. Other CDNs (like Akamai, Fastly, Netflix, and YouTube) use a hybrid BGP-DNS steering because some ISPs have extremely questionable routing practices . Unfortunately, if the CDN only rely on BGP steering (or conversely if you are a user who is stuck on an ISP monopoly), there are cases where this is not necessarily the nea…

I would be curious if you could provide any examples for the issues you cite. They sound plausible to me, especially around peering disputes or in various Asia countries, but I wonder how in practice this looks in like a traceroute for the amount of added latency etc. I would suspect some of non-optimized scenarios are eyeball network operator decisions on their networks that DNS providers and others do not have much…

BGP examples are easy to illustrate, although I don't have specific observations to share.

BGP's default route selection is to use the choice with the shortest AS Path.

If your ISP and your CDN peer in some locations, but not all, you can easily run into longer latency.

Ex: customer in Seattle, but ISP and CDN peer in Portland. CDN has a PoP in Seattle but not peered with the ISP.

BGP (without a lot of tuning) will prefer to send traffic through Portland, rather than through transit in Seattle, because the AS path through Portland is ISP -> CDN and the AS path in Seattle is ISP -> Transit ISP -> CDN

Of course, CDNs try to get peering in all common locations to address this, but that's not always possible, and not always because the ISP is unreasonably uncooperative. Sometimes the best path to resolution is by targetting the ISP dns server, but it doesn't catch all the customers.

Re: Choosing a Public DNS Resolver

#116

Post by ratorx »

vimda wrote: post #111
aetherspawn wrote: post #82

Use your ISPs official DNS so that you get the shortest path possible from the ISPs handoff location to the CDN (and overseas trunks), not a generic DNS that doesn’t know about your ISPs layout. ISP: 1ms to Cloudflare Cloudflare: 10ms to Cloudflare Thank you for your attention to this matter. Edit: will clarify, this advice applies to countries with good privacy laws and no national surveillance i.e. not the USA

Cloudflare famously does anycast so the DNS answer you get is the same no matter where you're coming from. Your numbers there can't be attributable to DNS. On the contrary, Cloudflare can short circuit the recursive lookup for any of their properties, providing potential speedups at the resolution stage, and can use eDNS client subnet to route based on where you are if necessary

Anycast DNS doesn’t mean what you think it means.

Your DNS traffic to Cloudflare is routed via anycast. If Cloudflare is sending this DNS query (eg to an authoritative DNS server), the IP address it uses for this is not going to be the anycast one. These IPs are geolocatable and Cloudflare even publishes feeds of their approximate location. The response you get will be geolocated based on the IP that Cloudflare is using to send traffic to the authoritative.

Cloudflare explicitly does not use ECS (the edns extension to provide client subnets to authoritatives): https://developers.cloudflare.com/1.1.1.1/faq/#does-1111-sen...

Re: Choosing a Public DNS Resolver

#117

Post by ekr____ »

aand16 wrote: post #83
abcdefg12 wrote: post #15

Earlier quoted context omitted.

Or you could use dnscrypt so ISP doesn’t see your lookups at all

During the TLS handshake, you send the domain name in clear text (Server Name Indication - SNI extension) so that the hoster can present the correct certificate for that domain. Nothing prevents the ISP from collecting that.

Hence Encrypted Client Hello (https://datatracker.ietf.org/doc/rfc9849/), though deployment is still thin.

Re: Choosing a Public DNS Resolver

#118

Post by pawal »

1vuio0pswjnm7 wrote: post #113

Why only 29 Is the author suggesting this represents the actual number of open resolvers on today's internet How can any consideration of "privacy" or "security" of DNS not also consider SNI SNI allows third parties to see when the user tries to connect to an address published for a domain name. It can allow third parties to interfere with such connections DNS only allows third parties to see when a user looks up an…

The author merely suggests that those 29 or in someway trusted by a lot of people to handle DNS queries. Those 29 also publish information on what properties the service have. If you read the whole page, the author also lists other publi DNS resolvers worth a mention.

For the long tail of unknown open DNS resolvers, use Shodan. But I would not suggest that you use any findings from Shodan to trust your internet usage with.

Yes, SNI is a generic internet privacy problem. However, it is not a property of DNS. On the positive side, ECH has been pushed through the IETF and should slowly be available to the general user.

/ The author

Re: Choosing a Public DNS Resolver

#119

Post by ragequittah »

TacticalCoder wrote: post #101
Bender wrote: post #5

I use Unbound locally as a DoH server. The Alpine Linux Unbound package is compiled with libnghttp2, required for the built in DoH listener . That's more than enough to enable ECH [1]. I pre-cache all the domains I use hourly via cron. My ISP is not going to dork with my DNS requests and their employees are bigger deviants than I. If I ever started browsing the web from a phone I would just set up my own public DoH s…

I run unbound too here. I love it that it takes wildcards to blacklist domains. I'm using big lists of domains to block and then I've got a whitelist that supercedes the blocked ones. And I've got a little tool that takes: ayt7.ads.acme.com afi6.ads.acme.com foi5.ads.acme.com and simplifies it to: ads.acme.com Then I've got a script which generates variations of domains name I use. Say if I use: mybank.com (legit) I…

I love the dedication but isn't using a good password manager the much cleaner and robust way of fixing the bank phishing problem? Or using the app on your phone.

Re: Choosing a Public DNS Resolver

#120

Post by llm_nerd »

marginalia_nu wrote: post #98
aetherspawn wrote: post #82

Use your ISPs official DNS so that you get the shortest path possible from the ISPs handoff location to the CDN (and overseas trunks), not a generic DNS that doesn’t know about your ISPs layout. ISP: 1ms to Cloudflare Cloudflare: 10ms to Cloudflare Thank you for your attention to this matter. Edit: will clarify, this advice applies to countries with good privacy laws and no national surveillance i.e. not the USA

Changing your DNS does basically bupkis for privacy, since they can still read your DNS queries and SNIs.

There are gaps depending upon the client configuration, but "bupkis" is simply wrong or horribly obsolete.

Encrypted DNS isn't an "any day now", basically every platform and browser and provider supports it, and 100% of my household's DNS requests are opaque to anyone watching the wire. And basically every system like Cloudflare supports ECH, so SNI isn't a thing for the vast majority of sites.

Post reply on HN