In a previous topic I wrote something which I am no longer sure is correct – someone was asking how to confirm that their Unbound installation is running as a recursive resolver.
After posting I wondered if this was a reliable test because I noticed that the ra flag was showing up almost all the time no matter which server I used. To test this I ran dig against my home router, which is definitely not a recursive resolver (it forwards to an ISP DNS which is). This query still returned the ra flag.
So is this flag in fact picked up from the end resolver? For Unbound in recursive mode this would be that instance, and for Unbound or an ISP router in forwarding mode it would be the upstream server? If so, this test is not suitable because it doesn't confirm that Unbound is doing recursion itself.
I'm aware of dig +trace but that doesn't help because that will only query Unbound for the root servers (whether Unbound is recursive or not) and then query the nameservers up the chain itself.
I'm also aware of sites like IP Leak and DNS leak test which are primarily for testing VPNs but which are useful to show if multiple servers are responding to client queries. If Unbound is running recursively and is the only server running, these tests will show the user's own public IP as the DNS server. Otherwise they reveal the upstream servers.
There's also the command below on the Pi-hole, which similarly will give the user's own public IP if Unbound is running recursively, or will give an upstream DNS IP if Unbound is forwarding.
dig whoami.akamai.net @127.0.0.1 -p 5335
These last two approaches feel a bit hacky, because they require the user to know their own public IP and interpret the IP address responses.
Is there a way to simply ask a target DNS server if it – not any upsteam server it may be using – is a recursive resolver, preferably using dig and observing the headers, flags, etc?
No and this behavior is even mandated by the RFCs. A forwarder should act transparently, regardless of how many are in between you and the final one.
I'm yet unsure why such a test is really useful. unbound will, by default, always be installed as recursive resolver and needs serious reconfiguration to behave differently. The easiest way to tell if unbound is configured to work recursively is (enabling and) checking its log files.
One further comment: The only DNS servers I can imagine right now where RA should never be set (because it is really not available) are the root DNS servers. And, indeed:
dig de @192.5.5.241
; <> DiG 9.18.1-1ubuntu1.2-Ubuntu <> de @192.5.5.241
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46759
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 13
;; WARNING: recursion requested but not available <---------------------------
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 2ee11794d96a62b6010000006383618a75b4f984c0ed1681 (good)
;; QUESTION SECTION:
;de. IN A
;; AUTHORITY SECTION:
de. 172800 IN NS n.de.net.
de. 172800 IN NS f.nic.de.
de. 172800 IN NS z.nic.de.
de. 172800 IN NS a.nic.de.
de. 172800 IN NS l.de.net.
de. 172800 IN NS s.de.net.
;; ADDITIONAL SECTION:
z.nic.de. 172800 IN A 194.246.96.1
s.de.net. 172800 IN A 195.243.137.26
n.de.net. 172800 IN A 194.146.107.6
l.de.net. 172800 IN A 77.67.63.105
f.nic.de. 172800 IN A 81.91.164.5
a.nic.de. 172800 IN A 194.0.0.53
z.nic.de. 172800 IN AAAA 2a02:568:fe02::de
s.de.net. 172800 IN AAAA 2003:8:14::53
n.de.net. 172800 IN AAAA 2001:67c:1011:1::53
l.de.net. 172800 IN AAAA 2001:668:1f:11::105
f.nic.de. 172800 IN AAAA 2a02:568:0:2::53
a.nic.de. 172800 IN AAAA 2001:678:2::53
;; Query time: 135 msec
;; SERVER: 192.5.5.241#53(192.5.5.241) (UDP)
;; WHEN: Sun Nov 27 14:09:31 CET 2022
;; MSG SIZE rcvd: 431
The role of the proxy should therefore be no more and no less than to receive DNS requests from clients on the LAN side, forward those verbatim to one of the known upstream recursive resolvers on the WAN side, and ensure that the whole response is returned verbatim to the original client. It is RECOMMENDED that proxies should be as transparent as possible, such that any "hop-by-hop" mechanisms or newly introduced protocol extensions operate as if the proxy were not there.
Mainly as a simple way to directly demonstrate, to any casual Pi-hole user who has just set up Unbound and asks in here how to see it in action, that domain lookups are now happening this new way compared to the previous old way, without needing to interpret "leak test" results or change log verbosity levels, restart services and interrogate logs and then reset back to defaults.
I saw the ra flag and initially thought that's a handy way to see it but that's not the case. It looks like it's more a case of "if you followed the Pi-hole docs instructions then rest assured it is", with some web / cli tests available to show the effects of it, if desired.