DNS not resolving IPv6 only address via WAN/localhost only

[OffstageRoller]

There's a similar topic here that I found, but it doesn't explain why this is happening:
https://forum.netgate.com/topic/185102/ipv6-test-aaaa-dns-queries-not-resolving

aaaa.v6ns.test-ipv6.com is only resolvable via IPv6, and provides an AAAA record in the response.

I do my own DNS resolving, and I have my outbound interface set to localhost. Everything works fine resolving DNS, but I am unable to resolve a DNS record via the pfSense GUI or using dig.

❯ dig aaaa aaaa.v6ns.test-ipv6.com

However, if I add one of my VLANs as an outgoing interface in my DNS Resolver, then things work both in the pfSense GUI and via dig.

❯ dig aaaa aaaa.v6ns.test-ipv6.com
aaaa.v6ns.test-ipv6.com. 300	IN	AAAA	2001:470:1:18::115

Why is that happening? Why, going out my WAN, does this fail, but going out a VLAN (which ultimately goes out my WAN), things begin working?

This isn't a real world problem. This would just get me a 10/10 instead of 9/10 on test-ipv6.com. I'm really just interested in understanding why I need to add a VLAN as an outgoing interface in order to resolve this specific DNS record that only replies via IPv6. Shouldn't this work via my WAN already?

[Gertjan]

@OffstageRoller said in DNS not resolving IPv6 only address via WAN/localhost only:

I do my own DNS resolving, and I have my outbound interface set to localhost.

localhost (127.0.0.1 or ::1) only ?

By default, this one ( Outgoing Network Interfaces ) :

is set to "All".
I've selected "WAN", and this is wgat I see in my unbound config file :

# Outgoing interfaces to be used
outgoing-interface: 192.168.10.4
outgoing-interface: 2a01:cb19:beef:a600:92ec:77ff:fe29:392a

where 192.168.10.4 is the IP of my WAN (its gateway is 192.168.10.1, my upstream ISP router)

For me, the outgoing network interface is : https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html - search "outgoing-interface:" on that page :

Interface to use to connect to the network. This interface is used to send queries to authoritative servers and receive their replies ......

IMHO 127.0.0.1 connects to .... itself.

[OffstageRoller]

@Gertjan If I use WAN only, I get the same result.

My understanding is that localhost goes out the default gateway. I've heard someone say the benefit of localhost over WAN is that if the WAN goes down, it won't cause issues like crashing with unbound (no idea if that's true or not).

See @johnpoz's answer from my link above, where he is also using localhost:

Personally I normally just have it use loopback.

[Gertjan]

@OffstageRoller

Yeah, I know. edit : if he says so, I should also just do so, and don't think about it.
Not very scientific, but :

This works well, I can still resolve. But I don't understand why it works ... unbound needs the 'outgoing' interface to resolve, so why not pointing it to it ?
I get it, it's smart enough to 'test' all interfaces, or, as you said, it knows the 'route out' to get out.
My WAN can't go down ( ^^ ) except if I rip out some cables, my upstream router and ISP are 'very stable'. And true, when WAN is down, the GUI can be somewhat (very) slow to reply, as it does some contact some outside resources, and resolving of them will time out eventually.

Anyway, I can confirm that, after setting this to 'localhost' I can still resolve, dig, whatever very well.

dig aaaa aaaa.v6ns.test-ipv6.com +trace

shows the normal resolve process.

[OffstageRoller]

@Gertjan I don't understand either. I used to have it only set to WAN, but I set it to localhost recently after reading a few people recommending that. In theory, Localhost shouldn't even be an option for outgoing network interface. The same could be true for all those link local options showing up as well.

That being said, you're actually getting results back for your dig command when your outgoing interface is set to WAN or Localhost only?

I'm not, which is what I'm trying to figure out. I do get a response if I also add one of my VLANs as an outgoing interface (which has IPv6 enabled via track). I'm confused on why a VLAN is needed as an outgoing interface for this to work.

Here's my dig command with trace enabled:

❯ dig aaaa aaaa.v6ns.test-ipv6.com +trace
;; Received 28 bytes from 2600:1500:9f88:4f03:92ec:77ff:fe3f:4ab8#53(2600:1500:9f88:4f03:92ec:77ff:fe3f:4ab8) in 39 ms

Here's my WAN interface status:

Status: up 
DHCP: up
MAC Address: 88:96:2e:65:65:a1 
IPv4 Address: 104.179.133.193 
Subnet mask IPv4: 255.255.254.0 
Gateway IPv4: 104.179.132.1 
IPv6 Link Local: fe80::8a96:4eff:fe85:65c1%ix3 
IPv6 Address: 2001:503:79f8:a011::1 
Subnet mask IPv6: 128 
Gateway IPv6: fe80::2d0:f6ff:fecd:d980%ix3 
MTU: 1500 
Media: 1000baseT <full-duplex,rxpause,txpause> 

[bmeeks]

The advantage of setting the outbound interface to localhost is that the interface will never "go down" unless pfSense itself reboots.

Contrast that to say the WAN interface which can cycle up and down when your cable modem reboots, when something like one of the IDS/IPS packages restarts (and then either PCAP or netmap cycle the interface where the IDS/IPS is running) or there is a temporary packet loss and dpinger fires an alarm response. In these instances, the WAN interface will be restarted. unbound does not tolerate an interface it is actively using "going down". unbound at a minimum must restart in that scenario. I would also not be surprised if certain interface "down" scenarios might result in ubound getting stuck in some limbo state and then requiring a manual restart to recover.

[Gertjan]

@OffstageRoller said in DNS not resolving IPv6 only address via WAN/localhost only:

That being said, you're actually getting results back for your dig command when your outgoing interface is set to WAN or Localhost only?

I've set it to localhost only since yesterday, if @johnpoz and @bmeeks tells me to so so, "I do not me, I do them".

Still, why should I have to select 'something' like 127.0.0.1 on "Outgoing Network Interfaces" , Why not leaving it empty all-together ? I guess I have to really read the unbound manual again ...

My unbound is still very happy. I can still dig and 'dns resolve' around as before. look for yourself, I've the stats to 'proof' it : no difference whatsoever.

@bmeeks said in DNS not resolving IPv6 only address via WAN/localhost only:

I would also not be surprised if certain interface "down" scenarios might result in unbound getting stuck in some limbo state and then requiring a manual restart to recover.

Makes two of us.
And things don't stop there, as for this very reasons this one gets added, making things worse.

[OffstageRoller]

@Gertjan What response are you getting for this command?

dig aaaa aaaa.v6ns.test-ipv6.com

Are you also getting a successful result using the DNS Lookup feature in the GUI under Diagnostics -> DNS Lookup?

[Gertjan]

@OffstageRoller said in DNS not resolving IPv6 only address via WAN/localhost only:

@Gertjan What response are you getting for this command?

dig aaaa aaaa.v6ns.test-ipv6.com

and earlier (I didn't notice) :

@OffstageRoller said in DNS not resolving IPv6 only address via WAN/localhost only:

This isn't a real world problem. This would just get me a 10/10 instead of 9/10 on test-ipv6.com.

Your right : that changed for me also :

I thought : because the unbound config only contains this - the IPv4 localhost : 127.0.0.1, I add this :

Now I have :

checking the unbound config file :

I closed all browsers, ditched the local DNS on my PC (ipconfig /flushdns) and redid the test :

[23.09.1-RELEASE][root@pfSense.bhf.tld]/root: dig @::1 aaaa aaaa.v6ns.test-ipv6.com +trace +nodnssec

; <<>> DiG 9.18.16 <<>> @::1 aaaa aaaa.v6ns.test-ipv6.com +trace +nodnssec
; (1 server found)
;; global options: +cmd
.                       85938   IN      NS      h.root-servers.net.
......
.                       85938   IN      NS      i.root-servers.net.
;; Received 239 bytes from ::1#53(::1) in 7 ms

com.                    172800  IN      NS      a.gtld-servers.net.
.....
com.                    172800  IN      NS      m.gtld-servers.net.
;; Received 848 bytes from 198.97.190.53#53(h.root-servers.net) in 24 ms

test-ipv6.com.          172800  IN      NS      ns1.test-ipv6.com.
test-ipv6.com.          172800  IN      NS      ns3.test-ipv6.com.
;; Received 148 bytes from 192.26.92.30#53(c.gtld-servers.net) in 18 ms

aaaa.v6ns.test-ipv6.com. 300    IN      NS      v6ns.test-ipv6.com.
aaaa.v6ns.test-ipv6.com. 300    IN      NS      v6ns1.test-ipv6.com.
couldn't get address for 'v6ns.test-ipv6.com': not found
;; Received 210 bytes from 176.58.89.68#53(ns3.test-ipv6.com) in 34 ms

aaaa.v6ns.test-ipv6.com. 300    IN      AAAA    2001:470:1:18::115
v6ns.test-ipv6.com.     300     IN      NS      v6ns1.test-ipv6.com.
;; Received 141 bytes from 2001:470:1:18::3:53#53(v6ns1.test-ipv6.com) in 160 ms

There is an answer in there ( 2001:470:1:18::115 ).
Running the same command without +trace :
No answer ???!?

Look at this :

[[23.09.1-RELEASE][root@pfSense.bhf.tld]/root: dig @::1 aaaa aaaa.v6ns.test-ipv6.com +trace +nodnssec +short
NS e.root-servers.net. from server ::1 in 5 ms.
NS l.root-servers.net. from server ::1 in 5 ms.
NS a.root-servers.net. from server ::1 in 5 ms.
NS k.root-servers.net. from server ::1 in 5 ms.
NS d.root-servers.net. from server ::1 in 5 ms.
NS b.root-servers.net. from server ::1 in 5 ms.
NS g.root-servers.net. from server ::1 in 5 ms.
NS f.root-servers.net. from server ::1 in 5 ms.
NS i.root-servers.net. from server ::1 in 5 ms.
NS h.root-servers.net. from server ::1 in 5 ms.
NS j.root-servers.net. from server ::1 in 5 ms.
NS c.root-servers.net. from server ::1 in 5 ms.
NS m.root-servers.net. from server ::1 in 5 ms.
couldn't get address for 'v6ns.test-ipv6.com': not found
AAAA 2001:470:1:18::115 from server 2001:470:1:18::3:53 in 153 ms.](link url)

How should I read this ?
One NS didn't have an answer, but the second one did (2001:470:1:18::115) ?

Btw : I dig using @::1 to force it using IPv6 locally. I've added the +nodnsec to make the resolving a bit more readable.