Ich auch (my German is basic), Michael.
The thread I provided as a reference has a lot of info. I think the bridge code has a bug somewhere but my python3 skills are basic. Jon mentioned that the bridge works if I define static hosts but if I have dynamic hosts, sometimes the bridge notifies unbound, sometimes it does not. Adolf checked that in his VM environment. I run the bridge with -d -vv flags so I can see what's going on in /var/log/messages. When a laptop joins the network and cannot resolve it by name, I restart DHCP and unbound, then it resolves.
-Paul
On Fri, Nov 19, 2021 at 4:32 AM Michael Tremer michael.tremer@ipfire.org wrote:
Hello Paul,
Nice to e-meet you.
On 2 Nov 2021, at 13:37, paul kairis kairis@gmail.com wrote:
I had an email exchange with Adolf Belka and he suggested I join the DEV
list and post my issues there.
Yes, this is absolutely the right place.
The way I understand it is that the DHCP table should match the Unbound
table at any given time.
Yes.
Example
I install linux on ssd and move the ssd to a laptop and deploy on the
network. I use a fast system i7-7700K to install linux, do post-install configurations, shutdown, move the ssd to a laptop (e6500), and boot. DHCP server gets confused since now I have two different mac, two different ip, and the same host.
10.0.0.33 f4:6d:04:76:60:f8 mx 28/10/2021 06:04:27 <==== i7-7700K mac
10.0.0.50 78:24:af:3e:18:53 mx 28/10/2021 06:10:31 <==== laptop e6500 mac
Unbound is confused, it tries to resolve mx to 10.0.0.50 but a reverse
lookup shows 10.0.0.33 Even if I run my 3-line script (rst) to restart DHCP and unbound, the cache is not cleared. I have to wait 15 min which is half of the default lease time (30) for .33 to expire in DHCP and then run my script again so that unbound properly (and reverse lookup) resolves the laptop to .50
Is there a way that when a system shuts down, DHCP *immediately* removes
that entry from its list and, via the bridge code, unbound is notified as well to forget that (host,ip) pair, *immediately*. I reduced Default Lease time to 5 min, Max Lease time to 10 so I have to wait 2.5 min but then /var/log/messages keeps growing.
That is a very short lease time and I would advise against it. Especially in larger networks you will keep the system busy handing out IP addresses and create more pressure for the unbound/DHCP bridge.
DHCP clients can hand back a lease (on Windows using ipconfig /release), but in normal operation, clients will unlikely do it. If you close a laptop’s lid, it will hibernate immediately and usually phones just leave the wireless reception area and won’t even be able to tell the DHCP server that they are gone. The usual way is that leases will time out.
In that case, the bridge should remove the A and PTR record from unbound.
Example
Clients do not implement DHCPRELEASE. Per the RFC, this is optional. I
shutdown my laptop (e6500) but when I look at ipfire > Network > DHCP server, the entry is still there for a few min till the lease expires.
Yes, this is what I would expect from most clients.
Example
I come to a party, the DHCP server is at the door. Hi, I am e6500 and
would like to enter. Sure, DHCP server says, your ip is 10.0.0.33, then the bridge updates Unbound with pair (e6500,10.0.0.33) I walk around the party with a tag (e6500,10.0.0.33) I mingle with people, ping, ssh by name or ip ... all good. I leave the party but DHCP has no knowledge I left till the lease expires. So for the next 5-10 min, I'm still shown in the party even though I left. What I'd like is a complete sync between the DHCP table and the Unbound table. pfSense does that but it is BSD which I don't know much about.
Yes, this is the protocol design.
I do not know what else I can say about it :)
Do you think there is a bug here anywhere?
-Michael
Regards,
Pavlos Kairis
REF:
https://community.ipfire.org/t/dhcp-hosts-not-reliably-propagated-to-dns/343...
Appendix
First script is dns_verify (adjusted for my network 10.0.0.*)
This script uses dig to do a lookup for an ip, get the name, then do a
reverse lookup using the name to make sure they are the same ip.
#### dns_verify see https://calomel.org/dns_verify.html
#
i=0 ## counter
NETS="10.0.0" ## network
IPS=$(seq 1 60) ## for Linux
DNS="@10.0.0.1" ## DNS to use
#
echo
echo -e "\tip \t-> hostname \t\t-> ip"
echo '-----------------------------------------------------------'
for NET in $NETS; do
for n in $IPS; do
A=${NET}.${n} HOST=$(dig $DNS -x $A +short) if test -n "$HOST"; then ADDR=$(dig $DNS $HOST +short) if test "$A" = "$ADDR"; then echo -e "ok\t$A \t-> $HOST \t\t-> $ADDR" ((i++)) elif test -n "$ADDR"; then echo -e "fail\t$A \t-> $HOST \t\t-> $ADDR" else echo -e "fail\t$A \t-> $HOST \t\t-> [unassigned]" fi fidone
done
echo ""
echo $i "hosts DONE."
Second script is watchDNS. I’m running watchDNS and every 5 sec, it
clears the screen and shows me what Unbound has in its table. I turn on the e6500 laptop. Unbound does not show it since the bridge fails to register that change. But if I look at the ipfire > Network > DHCP server, I see that e6500 got a 10.0.0.33 I run my 3-line script to restart DHCP and unbound, e6500 shows up! Wait a few min, then shutdown the laptop. DHCP will keep the lease until lease time expires (could be in 5, 10, 15 min) even though the laptop is gone from the network. If you run watchDNS, you see the laptop still has 10.0.0.33 and unbound is not notified to remove that entry.
while true; do
clear
echo '+--------------------------------------------------------+'
echo '| DNS info every 5 seconds |'
echo '+--------------------------------------------------------+'
. dns_verify
sleep 5
done
Third script is rst. It restarts DHCP and Unbound (and the bridge)
/etc/init.d/dhcp stop
/etc/init.d/dhcp start
/etc/init.d/unbound restart
END OF DOCUMENT