News for hackers. Stuff that matters.
Re:1.1.1.1 outage explanation by crtasm on Friday June 01, 2018 @10:24AM (#17205542)
I read on the Pi-Hole forums that 'fallback' is a misleading term because clients don't work that way - they will happily spread requests between two functioning DNS servers. Can anyone confirm this or provide further insight?
Re:1.1.1.1 outage explanation by mjcl on Friday June 01, 2018 @10:33AM (#17205626)
Different OSes handle it differently. Windows tries the primary, waits 1 second and then starts trying secondaries.
Re:1.1.1.1 outage explanation by dharmab on Friday June 01, 2018 @01:04PM (#17207464)
glibc tries in order. musl (Alpine Linux) tries all in parallel and returns thebl first resolution (If any).
Re:1.1.1.1 outage explanation by cookiecaper on Friday June 01, 2018 @11:24AM (#17206155)
Most systems do not round-robin by default afaik. They just try the listed DNS servers in order (and resolv.conf will only respect the first 3 IIRC).

DNS fallback is often also misunderstood to mean "fall back if the domain is not found", but it really means "fall back if the name server fails to respond". If the domain is not found (i.e. servers returns a valid NXDOMAIN response), most resolvers do not consult any other name servers.

Round-robin, cascading name lookups, and other frequently desired functionality can be obtained through dnsmasq or similar caching/forwarding name servers.

Re:1.1.1.1 outage explanation by LinuxBender on Friday June 01, 2018 @04:01PM (#17209546)
There are also options for libc that affect this behavior that can be set in /etc/resolv.conf like:

    options timeout:2 retries:2 max-inflight:768 max-timeouts:100 single-request-reopen rotate
There are man pages that describe these options.
Re:1.1.1.1 outage explanation by TravelTechGuy on Friday June 01, 2018 @10:59AM (#17205838)
Can confirm. If I have a secondary DNS specified in my router, other than my pi-hole, it becomes useless. My guess is the router is either measuring response time, and goes with the most efficient, or otherwise round-robining the requests. Either way, requests bypass the pi-hole in such quantities that it became useless.

PS: someone here mentioned that this behavior is OS-dependent - nope, this happens on the router level, and all devices in my apartment suffer.

Re:1.1.1.1 outage explanation by jschwartzi on Friday June 01, 2018 @11:34AM (#17206273)
It depends on how your router's DHCP server is configured. If you configure your router to pass its own IP address out as the DNS server for the local subnet then the router's behavior dictates how DNS works. If your router is passing out an external DNS in the DHCP configuration, then you'll get OS-dependent behavior.

My router uses a DNS resolver internally, and it will spread-cast to multiple DNS servers and use the quickest response it can get. It also caches using the TTL in the DNS response, and so it will serve up cached records transparently.

Re:1.1.1.1 outage explanation by detaro on Friday June 01, 2018 @11:01AM (#17205879)
Then your devices are likely using your router as a DNS resolver, which in turn talks to your pihole and the external one. And thus it depends on your router's OS what it does.
Re:1.1.1.1 outage explanation by iforgotpassword on Friday June 01, 2018 @07:06PM (#17211284)
Dnsmasq has different modes if you give it multiple upstream resolvers. By default it only queries the fastest one, which it determines by every now and then sending a query to all the servers and picking the one that replies first. You can tell it to always query all servers, or always query them in the order specified.
Re:1.1.1.1 outage explanation by LinuxBender on Friday June 01, 2018 @03:56PM (#17209477)
If your recursive DNS servers are Unbound DNS, they will keep note of which infra (upstream forwarder) nodes are responding and will blacklist the ones that do not. You can see this with

    unbound-control dump_infra
After the infra ttl expires, they will probe the down nodes. If they respond, then traffic will be distributed among them again.