dig returning "recursion requested but not available" on queries via IPv6 only

jhg · Mar 21, 2025, 8:31 PM

This is a simple home LAN running pfSense 2.7.2 connected to Xfinity cable.

DHCP and DHCPv6 are configured with DNS defaults (enabled, pfSense address as primary DNS server). I haven't touched the pfSense configuration in quite a while, and this warning/failure has just recently started popping up.

The following work as expected:

dig -4 google.com
dig -4 google.com aaaa

The following return "recursion requested but not available":

dig -6 google.com
dig -6 google.com aaaa

Any query received by pfSense over its IPv6 address is refused.

Any idea why this is and what I need to do to fix it?

Gertjan · Mar 24, 2025, 1:05 PM

@jhg

You executed the digs on a LAN device or pfSense ?

https://test-ipv6.com/ shows a 10/10 ?

jhg · Mar 24, 2025, 5:14 PM

@Gertjan Sorry I wasn't more clear.

Running a DNS query (dig, nslookup, whatever iOS does) directed to the pfSense IPv6 address from any LAN device. Tested from Windows, Debian and iOS, the reply is always status REFUSED.

Gertjan · Mar 25, 2025, 7:19 AM

@jhg

From a Windows pfSense LAN PC :

C:\Users\Gauche>nslookup www.google.com
Serveur :   pfSense.bhf.tld
Address:  2a01:cb19:dead:beef:92ec:77ff:fe29:392c

Réponse ne faisant pas autorité :
Nom :    www.google.com
Addresses:  2a00:1450:4007:810::2004
          142.250.75.228

DNS testing 'works' and uses IPv6 to communicate with pfSense (could use IPv4 also).

C:\Users\Gauche>ipconfig /renew6

Configuration IP de Windows

Carte Ethernet Ethernet :

   Suffixe DNS propre à la connexion. . . : bhf.tld
   Adresse IPv6. . . . . . . . . . . . . .: 2a01:cb19:dead:beef::c7
   Adresse IPv6 de liaison locale. . . . .: fe80::a6bb:6dff:feba:16a1%5
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.6
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Passerelle par défaut. . . . . . . . . : fe80::92ec:77ff:fe29:392c%5
                                       192.168.1.1

My Windows PC obtained a DHCPv6 lease from pfSense.
I use 'tracking' on the pfSense LAN, and pfSense got a prefix from the upstream ISP router.

and the simple IPv6 test :

My iPhone on the same network also works fine.

jhg · Mar 26, 2025, 4:42 PM

@Gertjan I'm not sure what your post means in regard to my issue.

I too have exactly the same configuration, and have no problems with IPv6 for LAN hosts. They all get IPv6 addresses within my delegated prefix, and they have no trouble communicating over IPv6 with external hosts.

For example see below.

The only issue is that, from LAN hosts, DNS queries to my pfSense DNS resolver, sent over IPv6, are refused.

In the example below, replace the initial dig -4 google.com aaaa with dig -6 google.com aaaa (or just dig google.com aaaa -- debian defaults to IPv6 if it's active) and the result is opcode: QUERY, status: REFUSED, id: 595 with message recursion requested but not available.

In other words, IPv6 is working just fine, the only problem is pfSense's DNS resolver is refusing requests it receives over IPv6.

I also tried issuing the dig commands in an ssh session on the pfSense system. Curiously, there is no issue in that case. See the second example below.

So the problem can be narrowed down to the single case of DNS queries received on the LAN interface over IPv6.

Example 1: Terminal Session on a LAN host showing that IPv6 connectivity is working without issues

jhg@debian ~
$ dig -4 google.com aaaa

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> -4 google.com aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21085
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;google.com.                    IN      AAAA

;; ANSWER SECTION:
google.com.             147     IN      AAAA    2607:f8b0:400e:c03::8a
google.com.             147     IN      AAAA    2607:f8b0:400e:c03::64
google.com.             147     IN      AAAA    2607:f8b0:400e:c03::71
google.com.             147     IN      AAAA    2607:f8b0:400e:c03::8b

;; Query time: 59 msec
;; SERVER: 192.168.10.254#53(192.168.10.254) (UDP)
;; WHEN: Wed Mar 26 09:29:21 PDT 2025
;; MSG SIZE  rcvd: 151


jhg@debian ~
$ ping 2607:f8b0:400e:c03::8a
PING 2607:f8b0:400e:c03::8a(2607:f8b0:400e:c03::8a) 56 data bytes
64 bytes from 2607:f8b0:400e:c03::8a: icmp_seq=1 ttl=106 time=19.5 ms
64 bytes from 2607:f8b0:400e:c03::8a: icmp_seq=2 ttl=106 time=21.3 ms
64 bytes from 2607:f8b0:400e:c03::8a: icmp_seq=3 ttl=106 time=19.0 ms
^C
--- 2607:f8b0:400e:c03::8a ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 19.003/19.933/21.314/0.995 ms

Example 2: dig in pfSense ssh session

[2.7.2-RELEASE][admin@janus.jhmg.pvt]/root: dig -4 google.com aaaa

; <<>> DiG 9.18.19 <<>> -4 google.com aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19966
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;google.com.                    IN      AAAA

;; ANSWER SECTION:
google.com.             300     IN      AAAA    2607:f8b0:400e:c0c::65
google.com.             300     IN      AAAA    2607:f8b0:400e:c0c::8a
google.com.             300     IN      AAAA    2607:f8b0:400e:c0c::64
google.com.             300     IN      AAAA    2607:f8b0:400e:c0c::66

;; Query time: 178 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Mar 26 09:40:20 PDT 2025
;; MSG SIZE  rcvd: 151

[2.7.2-RELEASE][admin@janus.jhmg.pvt]/root: dig -6 google.com aaaa

; <<>> DiG 9.18.19 <<>> -6 google.com aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53369
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;google.com.                    IN      AAAA

;; ANSWER SECTION:
google.com.             290     IN      AAAA    2607:f8b0:400e:c0c::8a
google.com.             290     IN      AAAA    2607:f8b0:400e:c0c::64
google.com.             290     IN      AAAA    2607:f8b0:400e:c0c::66
google.com.             290     IN      AAAA    2607:f8b0:400e:c0c::65

;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Wed Mar 26 09:40:30 PDT 2025
;; MSG SIZE  rcvd: 151

jhg · Mar 26, 2025, 5:08 PM

I think I solved the problem. Previously, in pfSense's DNS server config I had All selected in both Network Interfaces and Outgoing Network Interfaces (the default). I changed this to:

This caused DNS resolution over IPv6 to start working, in all LAN hosts.

Gertjan · Mar 27, 2025, 7:21 AM

@jhg said in dig returning "recursion requested but not available" on queries via IPv6 only:

I'm not sure what your post means in regard to my issue.

I need more info, so I'll be able to say wjay the issue is.

This

from LAN hosts, DNS queries to my pfSense DNS resolver, sent over IPv6, are refused.

means : Your device, using IPv6 - wants to contact the known local DNS server, normally pfSense, using the pfSense LAN IP.
That should work.

You can test if unbound, the resolver, on pfSense actually uses IPv6 :

[25.03-BETA][root@pfSense.bhf.tldroot: sockstat -6 | grep 'unbound'
unbound  unbound    53983 3   udp6   *:53                  *:*
unbound  unbound    53983 4   tcp6   *:53                  *:*

Also, your LAN firewall rules have to 'pass' IPv6 traffic.
Destination port 53, TCP6 and UDP6.

Your LAN needs to have a IPv6 :

[25.03-BETA][root@pfSense.bhf.tld]/root: ifconfig igc0 inet6
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: LAN
        options=48427b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWTSO,HWSTATS,MEXTPG>
        inet6 fe80::92ec:77ff:fe29:392c%igc0 prefixlen 64 scopeid 0x1
        inet6 2a01:dead:beef:a6e2:92ec:77ff:fe29:392c prefixlen 64
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Btw : "igc0" is my LAN network driver interface name.

Check that the PC or device you're using has an IPv6 with the same prefix :
== inet6 2a01:cb19:907:a6e2:92ec:77ff:fe29:392c prefixlen 64
in my case.

Check :

ipconfig /all :
.....
2a01:dead:beef:a6e2::c7
....

which also has the prefix "2a01:dead:beef:a6e2".

Si I can ping from my PC the pfSense Ipv6 :

C:\Users\Gauche>ping 2a01:dead:beef:a6e2:92ec:77ff:fe29:392c

Envoi d’une requête 'Ping'  2a01:dead:beef:a6e2:92ec:77ff:fe29:392c avec 32 octets de données :
Réponse de 2a01:dead:beef:a6e2:92ec:77ff:fe29:392c : temps<1ms
....

(My PC replies to ICMP packets = ping on its LAN interface).

I use the 'perfect' firewall rules on my LAN :

@jhg said in dig returning "recursion requested but not available" on queries via IPv6 only:

I also tried issuing the dig commands in an ssh session on the pfSense system. Curiously, there is no issue in that case

When connected to pfSense using SSH, your commands (command line) are send out over a interface.
These will be outgoing connections.
Firewall rules are for incoming connections, for every interface.
( Floating firewall rules can be the exception here, but normally you don't have thase )

@jhg said in dig returning "recursion requested but not available" on queries via IPv6 only:

I think I solved the problem. Previously, in pfSense's DNS server config I had All selected in both Network Interfaces and Outgoing Network Interfaces (the default). I changed this to:

These settings, the default settings, should always work :

I never had to change them.
The selection you made seem, imho, ok of course.
Can you confirm that when you switch back to "All" "All" it stops working ?

jhg · Mar 28, 2025, 11:07 PM

This post is deleted!

jhg · Mar 29, 2025, 12:05 AM

@Gertjan I did take your suggestion of switching back to "ALL" outgoing interfaces, and things still work.

So I'm going to chalk this up to the DNS resolver getting itself into a funky state over IPv6, which was corrected by restarting the resolver.

If this happens again I'll crank up logging to see if anything interesting shows up in the logs.

For now the issue is closed.