The resolving proxy server that one sends queries to, from a client library (built into the C library or otherwise), is not a "leaf". This is the same erroneou

The resolving proxy server that one sends queries to, from a client library (built into the C library or otherwise), is not a "leaf". This is the same erroneous mental model of the DNS that got the world the completely wrongheaded tool known as dnstracer, that bamboozled people for years. * http://jdebp.eu./FGA/dnstracer-incorrect-algorithm.html http://jdebp.eu./FGA/dnstracer-incorrect-algorithm.html There is not a "chain" of servers, each passing on queries to the next one along. There is a resolving proxy DNS server that takes a front-end query, makes a bunch of back-end query+response transactions with content DNS servers, and stiches their results together to make the final front-end response. * http://jdebp.eu./FGA/dns-query-resolution.html http://jdebp.eu./FGA/dns-query-resolution.html The aforementioned DNS client library can be given the IP addresses of multiple such resolving proxy DNS servers, but there has not been one single conventional order of querying them for far longer than systemd has been around. Different DNS client libraries do it in different ways. nslookup's internal DNS client library does something different to the ISC DNS client library that forms part of many C libraries, as I have already pointed out in this discussion. The whole "chain of servers" model is one of the commonest misunderstandings of the DNS, in my personal fairly long experience of people with DNS problems. It is quite wrong.