CU 203 Test : DNS does not update DHCP leases

[hjkl (H&M)]

@pscar13

Under Windows, when the Ethernet cable is plugged in, the Wi-Fi connection is disconnected automatically afterwards; there is no manual intervention.

True. But user can power up WiFi after that - saw that so many times, once done for the company town hall by the IT HD “just to be sure the connection is not lost for townhall meeting.”

Oh well, the entire town hall failed because the video conf apps was jumping from one link to another leading to seconds of pause (no vide or no audio) - session was distributed to +10000 video conferencing clients connected to that session).

Plus, the cache mechanism: existing connections will get replies send to the initial network card (i.e. Wifi). This mechanism will generate some time outs at server side: server side services are unaware of the change from ETH to WiFi (until the local client sends a new request, or, in case of streaming services, join again that streaming service). And CONNECTION Tracking will keep those sessions opened for so long - you will see them in conntrack table long time after the WiFi disconnected

Answers to your questions:

@pscar13

Which version of IPFire?
Are the IP addresses reserved in dhcp.cgi?
Are the hosts defined in hosts.cgi only?
Do all clients use the IPFire DNS to resolve the name of each service?
Have you tested CU203 with this configuration?

IPfire CU200(Production) + CU202 (in tests)

Yes, all ETH cards have reservations in DHCP. Some of these belong to Meraki AP - IPfire does not provide WiFi, this service being provided by Meraki AP (and the AP also acts as DNS proxy for the WiFi client - Meraki Boxes do use IPFire DNS for name resolution and blocks ALL DNS traffic coming from WiFi clients, except DoH (Meraki does not offer yet DoH filtring on their APs, or I did not read that article yet)

Each LAN client is defined in DHCP and multiple times in HOSTS (if that client provides services - like cups/printing, UPS management, Samba, etc). Meraki does NAT - WiFi clients are not aware of the LAN - this is why, dynamic protocols like Avahi are useless - WiFi clients behind Meraki AP are unaware of the CUPS print server that sists in LAN and these clients rely on DNS resolution to find it print.mydomain.ccTLD

Yes - all client are forced to use IPFire DNS - Meraki AP blocks all DNS requests that are not toward the Meraky DNS proxy provided in the DHCP response (all except DoH requests) and act as DNS proxy for all WiFi clients, proxy toward Prod IPfire DNS service and also to Testing IPfire box (secondary DNS). On LAN the IPFire FW rules + RPZ filtering do the same filtering and DoH filtering as well.

CU203 - no tests yet. I do run custom RPZ (Release Release 0.1.20 · JonMurphy/RPZ_add-on · GitHub) + Custom FW addon (Release firewall-local v1.8.0-ui · horace-michael/firewall-local · GitHub) plus other non-public add-ons I’ve wrote (for integrating IPfire with STEP-CA) therefore my testing is focused on these custom add-ons that provide functionalities I need: centralized Certificate Authority with ACME protocol for certificate renewal, FW rules management (all ipset list:set based to decrease the effort on checking the packets against so, so many rules that consume ASNs, CIDR, or company names, all I have defined in past 10+ years of using IPFire).

[pscar13]

Thank you for these clarifications.

[hjkl (H&M)]

Probably these 2 images will explain better than my English:
DHCP: Remark field is used to tell me that machine is dedicated for STEP-CA:
that box has 4 different network cards and some services are bound to a specific IP in that box to separate the traffic dedicated to each service (printing uses one card, step-ca another, samba uses the third card)

But, that step-ca definition inside DHCP is never used in DNS resolution: instead the hosts entry is used, and, because some the STEP-CA clients do search for step-pki instead of step-ca I had to register that hostname as well.

I hope this explains better how I am using the hosts vs DHCP entries.

[bbitsch (Bernhard Bitsch)]

Creating of the namespace of the local network(s) isn’t a trivial job.
There are several sources:

• (name, IP ) tuples in hosts, defined by hosts.cgi
• name the DHCP client signals itself
• an agreement of the IPFire SW: if the remark in the fixed leases definition matches the host name syntax, an name entry is produced.
• …

The bridging SW from DHCP to DNS uses one of these definitions. Don’t actually know how the weights are set.

With this procedure DNS may get multiple definitions for the same name with different or same IPs.

It is worth to discuss the best practice to handle this topic.
Which configs should work how?
Is it necessary to signal violences of the policy?

It is obvious, that not all arrangements of the ‘old’ DNS resolver are working in new implementation. But to realize a broadly usable name space handling, we should know the requirements.

[pscar13]

Thank you all for taking the time to help clarify this topic. I appreciate the explanations about your configurations and the local DNS behavior with Unbound.

My original question was specifically about CU203 and Knot Resolver.

At this point, I think the discussion has become broader than my original question, and I don’t believe it is likely to lead to any further clarification on that specific topic.

I’ll wait for the final CU203 release and see how the behavior evolves.

I would like to ask the moderators to close this topic.

Thank you again to everyone who contributed.