AndreBL
Stale addresses are not removed from DNS
On devices that use privacy addresses, old addresses that are no longer reachable, are not pruned from DNS resolution. As a result, DNS queries for the hostname return both the old and new addresses, except that only the new ones are reachable. This means that, for example, if you try to ssh to a host, it may hang for some time as it iterates through all the returned IP addresses until it gets one that is valid.
According to ip6neigh the addresses are no longer valid, yet they are still returned from DNS queries to OpenWrt for that name. In the following example 2607:f598:ba6a:610:b7b:534b:40ab:bfc6 is a stale address.
Command output demonstrating issue
root@yumi:~# ip6neigh list discovered | grep taravangian-eth
taravangian-eth 2607:f598:ba6a:610:be4f:2d10:b135:a3ef
taravangian-eth 2607:f598:ba6a:610:e2a2:2662:398d:a332
taravangian-eth.LL.lan fe80::ba32:e2cd:5d2c:1d46
taravangian-eth.LL.lan fe80::ba32:e2cd:5d2c:1d46
{raxod502@taravangian} ~ % dig -t AAAA taravangian-eth.lan
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> -t AAAA taravangian-eth.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42796
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;taravangian-eth.lan. IN AAAA
;; ANSWER SECTION:
taravangian-eth.lan. 0 IN AAAA 2607:f598:ba6a:610:b7b:534b:40ab:bfc6
taravangian-eth.lan. 0 IN AAAA 2607:f598:ba6a:610:e2a2:2662:398d:a332
taravangian-eth.lan. 0 IN AAAA 2607:f598:ba6a:610:be4f:2d10:b135:a3ef
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Feb 24 18:56:33 PST 2025
;; MSG SIZE rcvd: 132
{raxod502@cephandrius} ~ % ssh -oControlPath=none -6 -v taravangian-eth.lan
OpenSSH_8.9p1 Ubuntu-3ubuntu0.11, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /home/raxod502/.ssh/config
debug1: /home/raxod502/.ssh/config line 5: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to taravangian-eth.lan [2607:f598:ba6a:610:b7b:534b:40ab:bfc6] port 22.
debug1: connect to address 2607:f598:ba6a:610:b7b:534b:40ab:bfc6 port 22: No route to host
debug1: Connecting to taravangian-eth.lan [2607:f598:ba6a:610:e2a2:2662:398d:a332] port 22.
debug1: Connection established.
Interestingly... you know where the only place this stale address appears?
root@yumi:~# grep -R bfc6 /tmp/hosts
/tmp/hosts/ip6neigh.bak:2607:f598:ba6a:610:b7b:534b:40ab:bfc6 taravangian-eth
Is it possible that ip6neigh is creating a backup file for itself and this is inadvertently getting picked up by dnsmasq? Or is it something else entirely? I removed the backup file and after a few minutes, queries no longer return the stale record.
I see the .bak here:
https://github.com/AndreBL/ip6neigh/blob/816d42b93793f2002876927599131706bf29507f/main/ip6neigh-svc.sh#L190-L196
And I tested and verified on my own router that the sed packaged with OpenWrt does not clean up the .bak file even if the operation is successful. Maybe we just need https://github.com/AndreBL/ip6neigh/pull/30?