IPv6 DNS lookups on 2.8 returns very odd results

muddyfeet

I have setup DHCPv6 on pfSense handing out IP addresses prefixed with the tracked WAN prefix. This works correctly.

However, what doesn't work is I get an extra DNS entry in unbound - the ::0.1.0.1 "IPv4-Compatible IPv6 address" in the example below. The machine was assigned ::1:1 in the DHCPv6 configuration on pfSense and 17.20.1.1 in the DHCPv4 configuration.

This was the case on 2.8.0 RC and I have just updated to 2.8.0 and the result is the same.

This is causing IPv6 connectivity to break as the ::0.1.0.1 address goes nowhere.

From the machine itself which is configured by Kea DHCPv4/6 correctly:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:9f:67:ae brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet 172.20.1.1/16 brd 172.20.255.255 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 2403:5813:9f82:20::1:1/128 scope global dynamic noprefixroute
       valid_lft 6760sec preferred_lft 4060sec
    inet6 2403:5813:9f82:20:be24:11ff:fe9f:67ae/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86164sec preferred_lft 14164sec
    inet6 fe80::be24:11ff:fe9f:67ae/64 scope link
       valid_lft forever preferred_lft forever

Querying a windows machine for its address using nslookup (which has pfSense as its dns provider):

>nslookup pigdon.linton.id.au
Server:  wilson.linton.id.au
Address:  2403:5813:9f82:20:xxxx:xxxx:xxxx:xxxx

Name:    pigdon.linton.id.au
Addresses:  ::0.1.0.1
          2403:5813:9f82:20::1:1
          172.20.1.1

Querying another linux machine for its address using dig:

$ dig pigdon.linton.id.au AAAA

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> pigdon.linton.id.au AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49247
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;pigdon.linton.id.au.           IN      AAAA

;; ANSWER SECTION:
pigdon.linton.id.au.    1327    IN      AAAA    2403:5813:9f82:20::1:1
pigdon.linton.id.au.    1327    IN      AAAA    ::0.1.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu May 29 09:42:48 AEST 2025
;; MSG SIZE  rcvd: 104

$ dig pigdon.linton.id.au A

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> pigdon.linton.id.au A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50041
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;pigdon.linton.id.au.           IN      A

;; ANSWER SECTION:
pigdon.linton.id.au.    1324    IN      A       172.20.1.1

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu May 29 09:42:51 AEST 2025
;; MSG SIZE  rcvd: 64

I have no idea what is going on here other than an obscure reference in RFC4291 section 2.5.5.1.

Patch

@muddyfeet
Maybe related to this thread KEA DHCPv6: bug (?) with early DNS registration for Tracked Interfaces
And associated bug report https://redmine.pfsense.org/issues/16191

muddyfeet

@Patch Yes, I have just confirmed that it is related to early DNS registration