Hacker News Reader

Comment by cm2187 | Hacker News Reader

To me that’s a diversification away from 8.8.8.8. I am absolutely not criticising google’s DNS, it’s a useful service. But I am happy to get more choice.

View on HN

I agree - there are not very many internet-scale (for lack of a better term), completely free and fast DNS servers who have an IP address that's easy to remember.

Is that specific? sure, but I'll tell you when I go to set a new system up I'm going to type 8.8.8.8 because it's what comes to my mind.

For "easy to remember" my preference is to use Level 3 because I don't (directly) use them for any other service.

   4.2.2.1
   4.2.2.2

For as often as I manually configure DNS (I use DHCP) it's not onerous to look up the IPs of whatever DNS is preferable for your purpose.

edit: Depending on who you are this may redirect you to a search portal. Probably best to find an alternate DNS provider.

Those resolvers are technically for Level3 customers only - they'll return one of those ad-filled "search" portals where an NXDOMAIN would be proper, see:

  ; <<>> DiG 9.9.7-P3 <<>> thisprobablydoesntexist.com @4.2.2.2
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12860
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;thisprobablydoesntexist.com.	IN	A

  ;; ANSWER SECTION:
  thisprobablydoesntexist.com. 10	IN	A	104.239.213.7
  thisprobablydoesntexist.com. 10	IN	A	198.105.254.11

Contrast that with 8.8.8.8:

  ; <<>> DiG 9.9.7-P3 <<>> thisprobablydoesntexist.com @8.8.8.8
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7991
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

The NXDOMAIN response is proper - the level3 DNS servers are just a faster version of my ISPs goal to garner ad revenue at this point.

Those resolvers are technically for Level3 customers only

There is this comment from a few years ago, https://news.ycombinator.com/item?id=7120248 , linking to a blog post which is now only accessible from the Internet Archive, where a VP at Level3 stated they were public.

I use 4.2.2.x and I do get NXDOMAIN from them, and I'm not a L3 customer. I wonder if they respond differently depending on who you are...

I get:

  ; <<>> DiG 9.9.7-P3 <<>> @4.2.2.1 thisprobablydoesntexist.com
  ; (1 server found)
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10665
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;thisprobablydoesntexist.com.	IN	A

  ;; ANSWER SECTION:
  thisprobablydoesntexist.com. 10	IN	A	104.239.213.7
  thisprobablydoesntexist.com. 10	IN	A	198.105.254.11

  ;; Query time: 29 msec
  ;; SERVER: 4.2.2.1#53(4.2.2.1)
  ;; WHEN: Fri Mar 30 09:27:39 PDT 2018
  ;; MSG SIZE  rcvd: 77

Yeah I actually just looked and my DHCP is configured to use 8.8.8.8 :S

Looks like I ran into that issue and went back to Google.

I just changed DHCP config to 1.1.1.1 :)

  ; <<>> DiG 9.9.7-P3 <<>> @1.1.1.1 thisprobablydoesntexist.com
  ; (1 server found)
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28530
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 1536
  ;; QUESTION SECTION:
  ;thisprobablydoesntexist.com.	IN	A

  ;; AUTHORITY SECTION:
  com.			900	IN	SOA	a.gtld-servers.net. nstld.verisign-grs.com. 1522427379 1800 900 604800 86400

  ;; Query time: 33 msec
  ;; SERVER: 1.1.1.1#53(1.1.1.1)
  ;; WHEN: Fri Mar 30 09:29:56 PDT 2018
  ;; MSG SIZE  rcvd: 132

Level 3's resolvers will return fake NXDOMAIN responses that redirect to searchguide.level3.com.

I thought NXDOMAIN responses indicated that the domain doesn't exist and there wasn't a way to actually direct the user anywhere. Your resolver could of course lie and return an IP instead of NXDOMAIN however. Perhaps I'm wrong.

They take the "lie" route:

    # dig +short this-should-be-a-nxdomain.com @4.2.2.2
    198.105.254.11
    104.239.213.7

They do it a little more cleanly than some other attempts I've seen, but there's still flaws in their approach. In particular, they will generate redirects for NXDOMAIN responses to certain records under domains that do exist:

    # dig +short why-does-this-resolve.example.com @4.2.2.2
    198.105.254.11
    104.239.213.7

Specifically, they'll generate a redirect for any record that starts with the letter "w". (No, I'm not kidding. Try it.) Other records generate a real NXDOMAIN.

Right, what I meant is that you can't return an NXDOMAIN response that "redirects" the domain. (Of course this isn't really a redirect per-se.)

You are correct, their resolver is basically lying.

There is quad9 - 9.9.9.9 :)

Highly recommend Quad9. Their privacy policy is absolutely no identifying data logging, period. They're also the few providers offering DNS over TLS. Google, on the other hand, keeps identifying logs for 24-48 hours.

Just watch out for them if you're not in the US - any DNS-based CDNs will send you to an American node rather than your closest, it could slow things down a little

  dig @9.9.9.9 icnerd-1e5f.kxcdn.com
  icnerd-1e5f.kxcdn.com.	3600	IN	CNAME	s-us-ca00.kvcdn.com.
  s-us-ca00.kvcdn.com.	55	IN	CNAME	p-ussj00.kxcdn.com.
  p-ussj00.kxcdn.com.	55	IN	A	209.58.129.70

  dig @8.8.8.8 icnerd-1e5f.kxcdn.com
  icnerd-1e5f.kxcdn.com.	21599	IN	CNAME	p-uklo00.kxcdn.com.
  p-uklo00.kxcdn.com.	59	IN	A	217.146.91.55

9.9.9.11 is a CDN-friendly IP in Quad9. https://kznnog.co.za/wp-content/uploads/2017/11/Quad9-Intro-...

Does quad9 offer encrypted DNS?

Does quad9 offer encrypted DNS?

From their FAQ:

    Does Quad9 support DNS over TLS?
    We do support DNS over TLS on port 853 (the standard) using an auth name of dns.quad9.net.

Well, there's 9.9.9.9 (Quad9.net) which is global and secure, too.

There is a public DNS server at 141.1.1.1 (which I used for connection testing before there was 8.8.8.8 etc.), but I actually do not know by whom it is operated. Whois says Vodafone.

141.1.1.1 is owned by vodaphone de now.

https://dnslytics.com/ip/141.1.1.1

Most ISPs provide their own DNS server via dhcp, why not use that?

My ISP (Spectrum / Time Warner) will not return a proper NXDOMAIN, and will instead send you to an ad-filled "search" page. They're also slower than Google DNS somehow, and generally not much more than an opportunity for my ISP to get more information and ad revenue from me.

At least I'm not paying Google to do the same, and I can trust that they'll send the proper results.

Because most of them suck (Censorship, NXDOMAIN fuckups). Or are not reachable outside the ISP network.

For servers you typically have no DHCP. Also ISP often have annoying behaviours like redirecting you to their own websites for failed lookups. And my ISP doesn’t allow local non routable IPs (192.168.1.x) in DNS responses while google does.

>And my ISP doesn’t allow local non routable IPs (192.168.1.x) in DNS responses

isn't that the recommended behavior? otherwise you can do a bunch nasty stuff like rebinding attacks.

https://www.ietf.org/proceedings/52/I-D/draft-ietf-dnsop-don...

It's necessary for adding SSL to an intranet service.

I wonder if, given that we now have a number of reasonably decent DNS services, if we can make software better to obscure/divide up our DNS use.

Take your 1.1.1.1, 8.8.8.8, 9.9.9.9, maybe your ISP DNS, etc., check against them randomly to try and avoid giving any one of them all of your DNS request traffic, maybe look up the same address on two of them to confirm that you're getting the same destination from both?

I'm waiting for Facebook to get 6.6.6.6.

That's a DNS service everyone would love to use, right?

If you are Chinese, you would. 1, 6 and 8 are lucky numbers to Chinese.

I suspect that the whole reason why 8.8.8.8 is a Google DNS server is that they were originally only 4.4.4.4 until someone Chinese pointed out that 4 is an unlucky number. :)

Well for me it is really useful to renew let’s encrypt certificates. When doing DNS validation, you must enter a TXT entry as a response to a challenge. Having multiple public DNS is useful to ensure the entries have propagated before letting letsencrypt know they can query them. OVH’s Anycast DNS servers propagation for instance is really non deterministic. It may have propagated when queried from one location but not yet from another.

There's also Quad9 that I saw in an article earlier (not sure if it was on HN).

Quad9 blocks malicious domains by default, which is probably fine for most, but may not be wanted in all use cases.

They also provide 9.9.9.10, which doesn't have a blocklist.

https://www.quad9.net/faq/#Is_there_a_service_that_Quad9_off...

However, 9.9.9.10 does not perform DNSSEC validation, as 8.8.8.8 (Google), 64.6.64.6 (Verisign), 9.9.9.9 (Quad9), and now 1.1.1.1 (CloudFlare) do, so results may not be as trustworthy.

It does.

  $ dig @9.9.9.10 +dnssec +short verisignlabs.com
  72.13.58.64
  A 8 2 3600 20180413202737 20180330202737 31485 verisignlabs.com. KrnT9i6qytaYWDZWThBmBwc6anOmawNxJTxmSlpaY3L7Yfupga9FS70l 8nMVp8ggbEtA+CnS9AbNwObkPaYvk3nFpDvo4C+2hg+PECsP1HVTgGxl G3eblfnYAMNfYzLYlfUnSBgM7kLSIXY4rLBxsl01KiPJYezNhmQ53KYf ygs=

My personal experience is that I had reliability problems that I didn’t have with Google. And DNS is a critical step in the connection for which you really want reliability.

And mine is the opposite. I have not seen reliability problems with Quad9.

Use cases are different - Quad9 for "nasty" filtered and 8.8.8.8 for err probably not filtered.

Do it yourself otherwise.

Reply on news.ycombinator.com