Hacker News Reader

Comment by manacit | Hacker News Reader

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.

View on HN

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.

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.

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

There is quad9 - 9.9.9.9 :)

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.

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-...

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?

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.

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

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.

Reply on news.ycombinator.com