Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Pihole has 4 blocking modes: returning 0.0.0.0 or [::] for blocked A/AAAA records (this is the default), returning the pihole server's address (to provide a custom blocking page), or returning either NXDOMAIN or NODATA.

I if I recall correctly Windows, Linux, and MacOS all have the resolving behavior of only querying alternative servers if absolutely no response at all is received within some default time frame with the order of attempted servers being the order listed in the DNS configuration. I believe that this is also the behavior recommended by RFC. These methods should also result in some level of local caching as well by default if you're on Windows or MacOS, but Linux will vary by distro.

Because alternatives will only be tried if the preceding server fails it should be safe to manually add something like Cloudflare as a back up DNS server or distribute the alternative via DHCP (along with pihole or via pihole if it's also acting as DHCP).



For the most part, once a client goes through the process of selecting another DNS server it will stick with that choice until the process is triggered again. This will cause It's Always DNS memes when you've configured multiple servers which have differing views of DNS.


Oh you're right. I didn't think about the time it'd take to switch back to the "more desirable" name server or how often it checks it (or if it even does) when it's already selected another. I wonder what the differences are on OS/forwarder implementations for that.


If you want to give yourself a migraine, Microsoft has a comprehensive document[0]. DNS/AD has been the focus of my job for the last 5 years and I'm still not absolutely certain the circumstances that a given Windows client will return to the 1st candidate DNS server when there are > 2.

On Unix-y things, resolv.conf is specified to be used in the listed order[1]. Local caching resolvers will default to remembering the last successful server and treating the list as circular, so after the first DNS server has a failure it won't be tried again until each subsequent server has failed. Every time a distro has switched to having a local caching resolver by default you'll find big threads of people confused over the altered behavior[2].

And default behaviors are meant to be over-ridden, so in places where I have dnsmasq providing DNS for a network (PiHole, EdgeRouters) I set all-servers[3] so that every upstream is queried simultaneously and the fastest response wins -- an exceptionally bad configuration option when having upstreams with differing views of DNS, but for the general use case it makes the Which public DNS is fastest debate moot.

[0] https://docs.microsoft.com/en-us/previous-versions/windows/i...

[1] http://man7.org/linux/man-pages/man5/resolv.conf.5.html

[2] https://github.com/systemd/systemd/issues/5755

[3] http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html


> Because alternatives will only be tried if the preceding server fails it should be safe to manually add something like Cloudflare as a back up DNS server.

Is this definitely correct? I’ve read that primary and secondary are more or less equals and it’s just 2 servers and either may be picked. If you have a secondary that isn’t a Pihole, some percentage will bypass the Pihole. Disclaimer: I have no expertise and just read what Pihole and a few guides had to say. It was recommended to point primary and secondary at the same address or 2 separate Piholes to avoid issues.

https://discourse.pi-hole.net/t/primary-vs-secondary-dns/153...


I was referring to client side configuration and not pihole's configuration.

Pihole is basically a front end for dnsmasq which may indeed forward to servers in a round-robin fashion. Servers capable of forwarding usually have other options for determining who to forward to than just an ordered list. For example, if I recall correctly, Unbound by default distributes at random and then favors what it determines to be the fastest.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: