Ignoring domain CONFIG_DOMAIN for DHCP host name HOSTNAME

seems so:
image

but this is correct:
image

And what I don't understand: another business-laptop (with same settings, just other business-domain) doesn't produce this warning AND: it occurs since last update of Pi-Hole...

Looking at your screenshots:

There is a difference between the primary DNS-suffix (CONSULTING-AG.local) and the connection-specific DNS-suffix (home.lan). Can you find out why Windows does not use the latter? Is this the connection you are using to connect to your home network or there maybe something else involved (like a WiFi connection)?

The warnings have always existed in /var/log/pihole.log. The latest release just made them more visible by also printing them into /var/log/pihole-FTL.log and showing them on the dashboard.

yes, I know that there's a difference in the DNS-suffixes.... it's because the primary DNS-suffix is configured by the company.... but as I said, on my 2nd business-machine the settings are the same (just with another primary DNS-suffix) and there's no warning....

I've no idea at the moment how to find out, why Windows ist not using the latter....

Do you have any idea/hint how to find out why Windows on that machine does not use the connection-specific DNS-suffix (home.lan)?

1 Like

Same problem here. I generated a debug log. Token: https://tricorder.pi-hole.net/ctq25uyd/
Maybe a developer knows how to fix that. It's the laptop of my company.
Seems like everything is working fine. If the reason for the warnings cannot be eliminated, is there maybe a way to just disable the warnings or just the large warning sign in the dash?


1 Like

I read through several Microsoft documentation pages but nothing really helped. Here is what seems to happen: Windows always uses the primary DNS-suffix when asking for a DHCP lease. It simply ignores the connection-specific one. This one is only used when accessing devices over a given connection. Sounds somewhat useless but matches your observation.

The idea could be to add a new file /etc/dnsmasq.d/99-domains.conf and add

domain=CONSULTING-AG.local,192.168.2.123

where the CONSULTING-AG.local is the domain that Pi-hole complains about and 192.168.2.123 the address of the machine that is allowed to take it (please change this address!). @kzi has to use a different domain (cora-management.lcl). Then pihole restartdns and fingers crossed!

The warning is there intentionally and we should not offer a way to simply suppress it. In the end, it tells you that something different than you may expect is happening here. The intention of this mechanism is to constrain hostnames so that an untrusted host on the LAN cannot advertise its name via DHCP as e.g. "microsoft.com" and capture traffic not meant for it.

Ich wünsche Euch einen guten Start ins neue Jahr.

8 Likes

@DL6ER Thanks for your answer!
Isn't it then necessary to configurate a static DHCP lease for the concerned computer additionaly? Because otherwise it could get another ip with the next lease or am I wrong here?

Anyway I added the file /etc/dnsmasq.d/99-domains.conf as you suggested and it seems to work.
Another detail I'm wondering about, is, that now my laptop has two ipv4-addresses in the network-table (see attached screenshot) and one of them starts with 169.254, which seems to be a problem according to a quick google search. Although my internet connection is ok.

Have a good start into the new year too!

Watching this thread as I have the same issue with two work laptops in the house.

Both of the laptops are running Windows 10 and they both connect through the house Wi-Fi to their respective corporate VPNs, with each laptop using a different VPN software.

This isn't necessary. Instead of assigning IP addresses sequentially as done by many routers (first device becomes .2 , second device becomes .3 , etc.), Pi-hole always assigns the same address to the same device. The has the benefit that your devices always get the same address, not dependent on the order you switch them on after getting up in the morning.

We do this by, instead of simply counting up, basing the IP address on a hash computed form the device's MAC address. This is the reason why the first device connected might receive a relatively high address like .145 . Unlike many sequential router DHCP servers, Pi-hole's internal DHCP server is deterministic.

Obviously, this can only work with sufficient large network ranges, e.g., if you have a network range 192.168.0.10 - 192.168.0.50 and connect 35 devices, hash-based calculations will not be unique. Hence, Pi-hole has a second mechanism that helps staying deterministic: The leases table /etc/pihole/dhcp.leases.

Actually, static DHCP assignments should be avoided when possible as they rather oppose an obstacle for an otherwise well thought out and nicely working behind-the-scenes automated DHCP system. They might have been necessary for non-deterministic (i.e., sequential) servers to reduce network fluctuation or because you have some equipment in your household that needs to talk to another device (say a printer) and doesn't support hostname resolution.

Following the internet standards, if you see a 169.254.x.x address, it means that the DHCP server is not reachable. However, your machine obviously also received a correct address and is working fine as you say. We've seen reports in the past that Windows machines like to assign this second address to itself without any real trigger for it. As long as the machine works as expected, you can (and probably have to) ignore this.

3 Likes

Good to know, thank you for the background information!

DL6ER: thank you for your help - solution with 00-domain.conf - file seems to work! though there are some "funny" entries in pihole.log like

Jan 1 14:37:28 dnsmasq[29253]: query[A] CONSULTING-AG .consulting-ag.local from 192.168.1.97

Jan 1 14:37:28 dnsmasq[29253]: forwarded CONSULTING-AG .consulting-ag.local to 127.0.0.1

Jan 1 14:37:28 dnsmasq[29253]: reply CONSULTING-AG .consulting-ag.local is NXDOMAIN

and off course: HAPPY NEW YEAR!! / FROHES NEUES JAHR!!

Will try DL6ER's solution of creating a 99-domain.conf file with the two corporate laptops domains and IP addresses. Thanks for the suggestion.

The solution provided by DL6ER in #8 above has worked for me for a couple of days. No more errors. Thank you!

1 Like

Also here - thank yo DL6ER !!
But I don't understand why Windows is acting that way - I've to fix all businnes-laptops (my 2, my wife's) in that manner....

Thanks DL6ER this works for me but when switching over from ethernet to WiFi I use another IP address. What is the syntax to assign multiple IP addresses to a domain? Can I just add in another line with the same domain and new IP address?

Same question here - so far, I just added another line with the WiFi-IP address...

Yes, if they are directly next to each other you can also provide a IP address range like

domain=CONSULTING-AG.local,192.168.2.123,192.168.2.125

Note that, despite the command syntax, this is not a list of addresses but a range. The example above covers 192.168.2.123, 192.168.2.124, and 192.168.2.125

1 Like

Thank you for this information. I take it because it covers a range of addresses it is not possible to provide both IPv4 and IPv6 addresses on the same line?

If I have just 1 laptop with domain CONSULTING-AG.local, can I force to provide just 2 IP addresses (for eth & WiFi) with
domain=CONSULTING-AG.local,192.168.2.123,192.168.2.124
?

I guess you would need to use IP address reservation to ensure eth will be next to wifi


@DL6ER
many thanks for your solution. I was looking for this quite a while, as I basically had same issue with my company laptop. Thx to your solutions it's gone. :+1: