I kept running into DNS issues, and needed to triple-check that I was pointing to the right DNS servers, so I made this utility website that does exactly that: which-dns [1]
This isn't a new idea ([2]), but mine supports https (hat tip to Matt Holt's certmagic [3]), is ad-free, and the source is available [4].
> How does it work? You make a request to a hostname with a unique prefix. All hostnames resolve to the same IP, but the DNS server records which IP address the query came from. The webserver looks for this record and returns it.
That's a smart way of detecting a user's DNS server - well done!
Is there a way to "fail" the first request and try to force the user's secondary DNS to kick in so that it can be detected too?
The extended test on https://www.dnsleaktest.com/ does that. There’s also various tests that reveal EDNS subnet leakage.
It’s pretty easy to implement; somehow don’t respond to a request, but do respond to a second. (If you’re clever you can probably do it without server side state, e.g. encode a deadline in the custom hostname.)
It only sees the "last hop" of recursive DNS resolution [1]. If you have internal DNS servers, you would need to run a copy of which-dns internally, and your internal DNS servers would need have the which-dns entries added.
If you want to see if a local workstation is pointing to a different public/external DNS server than the rest of your network, it should work.
This is really cool, especially because I can just 'wget -qO- $RANDOM.which.nameserve.rs/api.json?callback=myfunction' which means I can use this in scripts. (For example an added field to scripts that grab from ifconfig.co)
Duly noted. It's ok, most of my scripts just pile up the cobwebs and never get used anyway, and they are all personal, not commercial. I would of course consider standing up my own for any real use. Good work!
Now you have me thinking about the economics of api as a service... another rabbit hole.
PCH provides the infrastructure for Quad9...so I don't think it makes sense to say that Quad9 is "relaying" DNS traffic to PCH/WoodyNet. There isn't some organizational boundary that's being crossed.
Hi. I'm Bill Woodcock, the eponymous "woody" of "woodynet." And executive director of PCH, and chairman of Quad9's board. They are three separate corporations, which exist for different reasons, and under different tax regulations (PCH and Quad9 are public-benefit not-for-profits, whereas WoodyNet exists to pay taxes on taxable transactions and keep the non-profits' books clean), but they're very closely related.
In this case, you're seeing WoodyNet IPs and IN-ADDRs because WoodyNet is giving transit to the Quad9 anycast instance you're talking to.
I'm happy to answer any questions you may have about how all this works.
I'd also note that round-robining between two different organizations with radically different privacy practices and security services... um... might not make the most sense? Depending what your goal is, of course. Again, happy to talk about any of this, just let me know if I (or any of the Quad9 or PCH folks) can be of help.
Not the person you responded to, but I too run my own resolver on my router. I also have the router configured to drop [1] all outgoing packets to any DoH IPs; there are a bunch of lists for those, like https://github.com/Sekhan/TheGreatWall
[1]: Specifically, to reject them, which means sending a TCP reset / ICMP unreachable response back rather than blackholing them.
I run a DoH resolver domain-fronted by Cloudflare... Blocking it at IP level would mean blocking other Cloudflare proxied websites. With IPv6, a DoH endpoint rotating between various IPs might get even more trickier to block.
A better strategy might be to look at the SNI for hostname at least until ESNI becomes prevalent (the one I run supports ESNI already).
So if I understand this correctly, this provides a way for example.com to suggest a DoH server that the client can use to resolve example.com's subdomains? I can see it being problematic because it'll bypass my resolver's ad-blocking.
I don't use any Apple software or hardware, but if Firefox starts using it I'll start worrying about it.
I have a similar setup, but the DNS servers are at a hosting facility and I access them from home over a VPN. This avoids the problem of the ISP messing with the DNS responses (e.g. to replace NXDOMAIN with an A record for their own bullshit "not found" page with ads).
I do the same, but I read that that is also sending your IP all around the internet, which can have repercussions? The alternative is to not use a recursive resolver, but just punt to one of the "safer" ones such as 1.1.1.1?
Meaning, if you don't want people to know you are searching for snm.donkeyporn.com than going out to the nameserver that donkeyporn is using is not exactly keeping the information private.
If you're talking about clouflare warp, then yes... kind of. If you mean only the DNS, them no, there are still many connections matching you to the destination.
Worth noting that until Encrypted SNI is universally used, you probably transmit snm.donkeyporn.com in the clear when your browser does the initial TLS exchange anyway.
I personally feel that concentrating all the information of "what DNS names are people looking up" into the hands of a few parties (e.g. CloudFlare) makes it much easier to collect and analyze this information.
You are correct that if you run your own resolver, then all the DNS traffic from your resolver to other nameservers is in cleartext. DoH and DoT only get used by forwarders.
I run the same setup, local resolver that recurses from the roots, and I don't cache anything other than what my systems actually request. If I hit a new site, I pay the penalty for not having certain information cached.
Hows the DNS server to know what to pre-cache to reduce lookup times?
Even for something that is not in the cache DNS is lightweight and quick, and I have full control over when to flush it, and have logs.
I am not huge fan of the trend of various device manufacturers (looking at you Google, and now Apple too) sending queries over DoH instead of using the local resolver on my network :/
DNS lookup times are strongly affected by things entirely within the control of DNS content publishers and nothing to do with what one uses locally, namely whether "glue" is in-bailiwick. Out-of-bailiwick glue causes a massive explosion of additional back-end queries.
This has been a known problem for decades, people having encouraged in-bailiwick "glue" since at least the turn of the century. If you want to decrease lookup times, add your voice to encouraging this. Experts in the field are nowadays generally persuaded that it is a good thing, which took a saddening amount of persuasion. But everyday administrators still too-often do not get encouraged to use in-bailiwick delegations.
Thank you. What an awesome explanation. This has been incredibly helpful. Perhaps one of the web optimizations that site owners need to think about is use in-bailiwick delegations
If Mozilla silently enabled DOH-via-CloudFlare for you, it would show up here right? Because if yes, this would make it quite easy to find whether you have the right settings without having to find it somewhere in a configuration screen or trying to find out which users' throats Mozilla ended up deciding to force this down.
Sort of: it doesn't differentiate between DoH and normal resolution (it only does IPv4 TCP & UDP resolution). This means that it will return Cloudflare (i.e. ASN of CLOUDFLARENET), but probably the same Cloudflare as if you are using Cloudflare's public DNS servers.
Tip: You can check a specific DNS server with dig and curl:
Very satisfied NextDNS user here. Easy to set up, and it’s a surprise for me how much nicer ad and tracker blocking is over my entire network (all laptops, phones, smart TV etc.) than just using a blocker in my web browser.
Neat, this helped me realize I haven't switched away from my provider's default DNS when I moved in, which is something I usually do.
How to choose a DNS server? I usually just go with 8.8.8.8/8.8.4.4, I used to always test this with Namebench (https://en.wikipedia.org/wiki/Namebench) and these always turned out as the fastest - but it looks like it hasn't been updated since 2010 - are there any better tools for this, or any considerations in general? I prefer performance over privacy here, I think privacy should be on a different layer.
Performance over privacy is a fine tradeoff but if you have the means to, I would recommend avoiding unencrypted unauthenticated DNS over UDP/53. It's probably not a big threat in practice but if someone were to intercept your DNS traffic, they could redirect your internet connections to a different server. TLS (or other forms of authentication) should handle authenticity issues but (probably) not everything on your system mandates TLS.
If I'm not mistaken you can use DNSSEC to authenticate, but not encrypt, your DNS requests. For me however, the simpler way was to just use DoT/DoH. I haven't noticed any slowdowns.
If you care about performance, you could check if your system caches DNS responses and configure that cache accordingly.
You are not mistaken; DNSSEC doesn't encrypt records, and DoH does. DoH also authenticates the channel between you and your name server. It's likely that DoH will ultimately obviate the need for DNSSEC anywhere.
Client devices, I think - filtering that happens transparently and without an easy way to disable is just asking for problems - I couldn't deal with having to log in to the DNS management console every time when a website notices that ads didn't load and therefore doesn't display content. I don't think we're at a point where privacy can be guaranteed by technology choices - it's all about behavior of end users (like avoiding websites which block content if ads don't load ;-)
Is it possible these privacy/filtering DNS services like NextDNS come without a performance hit? Imagine setting it up and forgetting about it, and discovering later that all your DNS queries happened with a substantial lag - it's like realizing you've been driving with a hand brake on
It would be neat if this also recognized that you're hosting your own dns, instead of spitting your own IP back at you. I didn't recognize my IP at first.
This is a good solution. Another much lighter-weight solution is to simply add a static name/ip association in your local /etc/hosts file. It's a bit brittle, but honestly for a lot of websites its a lot less brittle than you think (and it's even more efficient than a Pi-hole). The biggest drawback is that you'll have another thing to trouble-shoot if something goes wrong. But that's true for any privacy-preserving DNS solution.
pi-hole now allows custom DNS entries, which will then work for all devices on your network and not just the one you edited /etc/hosts on (useful for, e.g, phones & smart devices where DNS configuration can be very limited).
> I specifically made the API be JSONP only (i.e. you need to provide a callback parameter), so if you abuse it, bad things will happen to your clients!
Is OP threatening to inject harmful code into abusers' script tags, or am I totally misreading this.
Yes: I've made free APIs in the past that have been abused. I've made this for my needs and am happy to share, but it isn't a moneymaker. It is really simple to host your own copy, and I've tried make it pretty clear that it should only be for light, non-commercial use.
You can see the code, so obviously I haven't done anything nefarious. Hopefully just the possibility will be enough of a deterrant.
I'm curious how everyone else is dealing with freeloaders. I'm open to alternative suggestions.
Oh I don't have an alternative suggestion. Just thought it was an interesting approach. Also I've never used JSONP and hadn't considered the security implications of using a JSONP api you don't control.
Gosh, I feel old, how do I set DNS servers in Linux these days?
I used to just edit /etc/resolv.conf and add 8.8.8.8 to it but now recent distros have "Do not edit." in resolv.conf and don't tell you what to actually edit. Why do they have to do this to us ... things used to be simple.
Today, you can set up DNS per interface and designate, which DNS accessible via which interface can resolve which zones. So your intranet.company.com can go through specific VPN connection and the rest via your default route, for example.
I don't think resolvectl is less simple, just different. It makes it much easier to realize you've typo'd something, for instance. It also makes it easier to understand what the running config is, as opposed to the old "read a bunch of text files and hope they haven't been edited since the daemon was hup'd".
You can still edit /etc/resolv.conf. If it has a "Do not edit" comment in it, it's probably a symlink to some file that's dynamically managed (most likely to automatically use or fallback to the DNS server advertised on the network, as needed for e.g. captive portals). Just replace the symlink with a text file with your prefered DNS server in there.
This shows which DNS server performed the recursive query for you, but in more complicated setups it won't be the DNS server your system is pointed to. For example if you're using 1.1.1.1, this will show some other CloudFlare IP.
That's correct, but it is still useful (IMHO). The ASN value should be the same (or at least related). If it isn't, there is something going on that you should probably investigate.
In this thread, @jelv suggested GRC's Benchmark [1]. There is also namebench [2], an older python tool. I personaly haven't used either one (yet). Definitely an opportunity for a new, portable tool!
This isn't a new idea ([2]), but mine supports https (hat tip to Matt Holt's certmagic [3]), is ad-free, and the source is available [4].
Let me know what you think!
[1] https://which.nameserve.rs
[2] http://www.whatsmydnsserver.com/
[3] https://github.com/caddyserver/certmagic
[4] AGPL. It is my first foray into golang. https://github.com/redirect2me/which-dns
> How does it work? You make a request to a hostname with a unique prefix. All hostnames resolve to the same IP, but the DNS server records which IP address the query came from. The webserver looks for this record and returns it.
That's a smart way of detecting a user's DNS server - well done!
Is there a way to "fail" the first request and try to force the user's secondary DNS to kick in so that it can be detected too?
It’s pretty easy to implement; somehow don’t respond to a request, but do respond to a second. (If you’re clever you can probably do it without server side state, e.g. encode a deadline in the custom hostname.)
I'm not sure failing will do that, but it might reveal interesting things anyway. I'll add it to the to-do list.
If you want to see if a local workstation is pointing to a different public/external DNS server than the rest of your network, it should work.
[1] https://www.cloudflare.com/learning/dns/what-is-recursive-dn...
I always use IPleak.net [1]. Works for public IPv4, IPv6, DNS server, Tor/AirVPN exit node, BitTorrent, geolocation, and all kind of browser metadata.
Browsing through comments shows this can do some things IPleak.net can't do such using wget/curl with API.
[1] https://ipleak.net
[1] https://airvpn.org/forums/topic/14737-api/
But please, only light, non-commercial use! It is on the cheapest static IP that I could find with no failover or anything.
It is really easy to run your own copy if you need it for a commercial project.
Now you have me thinking about the economics of api as a service... another rabbit hole.
Page alternately returns WOODYNET @ rrdns.pch.net and CLOUDFLARENET. I like the pch.net info - it's something about Quad9 I didn't know.
In this case, you're seeing WoodyNet IPs and IN-ADDRs because WoodyNet is giving transit to the Quad9 anycast instance you're talking to.
I'm happy to answer any questions you may have about how all this works.
I'd also note that round-robining between two different organizations with radically different privacy practices and security services... um... might not make the most sense? Depending what your goal is, of course. Again, happy to talk about any of this, just let me know if I (or any of the Quad9 or PCH folks) can be of help.
My resolvers perform queries against the root servers directly and cache results.
It's refreshing to skip all the DNS fuckery that's going on nowadays.
[1]: Specifically, to reject them, which means sending a TCP reset / ICMP unreachable response back rather than blackholing them.
A better strategy might be to look at the SNI for hostname at least until ESNI becomes prevalent (the one I run supports ESNI already).
1: https://datatracker.ietf.org/doc/draft-pauly-add-resolver-di...
I don't use any Apple software or hardware, but if Firefox starts using it I'll start worrying about it.
And I supply DNS-over-TLS and DNS-over-HTTPS locally. It's really not too difficult.
edit: downvoting honest questions?
Donkeyporn's DNS provider, com's DNS provider (0.1% chance it's not already cached), your ISP, transit providers, donkeyporn's ISP, donkeyporn service
To: cloudflare, your ISP, transit providers, donkeyporn's ISP, donkeyporn service
It's not a huge change and it's really about whether you trust CloudFlare more than the service donkeyporn has chosen.
I personally feel that concentrating all the information of "what DNS names are people looking up" into the hands of a few parties (e.g. CloudFlare) makes it much easier to collect and analyze this information.
I run the same setup, local resolver that recurses from the roots, and I don't cache anything other than what my systems actually request. If I hit a new site, I pay the penalty for not having certain information cached.
Hows the DNS server to know what to pre-cache to reduce lookup times?
Even for something that is not in the cache DNS is lightweight and quick, and I have full control over when to flush it, and have logs.
I am not huge fan of the trend of various device manufacturers (looking at you Google, and now Apple too) sending queries over DoH instead of using the local resolver on my network :/
This has been a known problem for decades, people having encouraged in-bailiwick "glue" since at least the turn of the century. If you want to decrease lookup times, add your voice to encouraging this. Experts in the field are nowadays generally persuaded that it is a good thing, which took a saddening amount of persuasion. But everyday administrators still too-often do not get encouraged to use in-bailiwick delegations.
* https://cr.yp.to/djbdns/notes.html
Tip: You can check a specific DNS server with dig and curl:
and then do a ASN lookup on the IP addressNote: the debug page is unofficial, and may change, so don't bake this into anything.
* https://developer.akamai.com/blog/2018/05/10/introducing-new...
One question popped into my head is how do you trust nextdns? or are you doing something so that you do not need to trust it?
How to choose a DNS server? I usually just go with 8.8.8.8/8.8.4.4, I used to always test this with Namebench (https://en.wikipedia.org/wiki/Namebench) and these always turned out as the fastest - but it looks like it hasn't been updated since 2010 - are there any better tools for this, or any considerations in general? I prefer performance over privacy here, I think privacy should be on a different layer.
[1] https://www.grc.com/dns/benchmark.htm
If I'm not mistaken you can use DNSSEC to authenticate, but not encrypt, your DNS requests. For me however, the simpler way was to just use DoT/DoH. I haven't noticed any slowdowns.
If you care about performance, you could check if your system caches DNS responses and configure that cache accordingly.
Can you elaborate which layer?
Is it possible these privacy/filtering DNS services like NextDNS come without a performance hit? Imagine setting it up and forgetting about it, and discovering later that all your DNS queries happened with a substantial lag - it's like realizing you've been driving with a hand brake on
I run Unbound (a DNS resolver) alongside Pi-hole on a dedicated raspberry pi for my home network.
https://resolve.rs/http/myheaders.html
It says:
> These are the HTTP headers that are being sent my your browser.
Great set of tools, BTW.
for i in `cat dns_list.txt|grep -v '^#'` do qt=`dig @$i archive.is| grep "Query time:" |cut -f2 -d ':'` echo "$i: $qt" done
[1] https://github.com/redirect2me/which-dns#alternatives
Is OP threatening to inject harmful code into abusers' script tags, or am I totally misreading this.
You can see the code, so obviously I haven't done anything nefarious. Hopefully just the possibility will be enough of a deterrant.
I'm curious how everyone else is dealing with freeloaders. I'm open to alternative suggestions.
I used to just edit /etc/resolv.conf and add 8.8.8.8 to it but now recent distros have "Do not edit." in resolv.conf and don't tell you what to actually edit. Why do they have to do this to us ... things used to be simple.
Today, you can set up DNS per interface and designate, which DNS accessible via which interface can resolve which zones. So your intranet.company.com can go through specific VPN connection and the rest via your default route, for example.
You can't do that with simple /etc/resolv.conf.
https://wiki.archlinux.org/index.php/Systemd-resolved#Settin...
https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs...
[1] https://dnsadblock.com/dns-leak-test/
[1] https://www.grc.com/dns/benchmark.htm
[2] https://github.com/catap/namebench