Host override with multihomed host
-
I have a host with two adapters on two different LANs, both of which use pfSense as the router/firewall. Each adapter gets a DHCP address from pfSense (ISC DHCP server) and because the DNS option to register DHCP leases is enabled in the DNS resolver, both IP addresses are returned in DNS queries for that host. So far, so good, this is as expected.
However, I don't want one of those addresses to appear (it's not routable from the host -- it's only meant for the host to communicate on its local subnet). So I added a host override entry for that host -- . But even with the host override, the DNS still returns BOTH IP addresses in DNS queries. I expected that the host override would hide any dynamic DHCP addresses that had been registered, but apparently not.
Is this expected behavior?
-
@dgilmour77 said in Host override with multihomed host:
Is this expected behavior?
Sure.
Better don't use pfSense on both NICs as gateway. Make a manual config on one NIC, without setting a gateway etc. -
@Bob-Dig Thanks.
Yes, the easiest thing to do was just to give the second network adapter a private static IP locally; pfSense doesn't even know about it, and so can't publish it in DNS.
But I have to say that the way the "host override" is described in the prompt, it certainly implied to me that it would override all domain lookups for that host -- meaning for unbound clients, not just the firewall itself. It doesn't really to that.
It would also be nice if there were a way to exclude a single DHCP lease from DNS registration - but I don't think there is.
No worries, I'm set with my workaround. Thanks again.
-
@dgilmour77 said in Host override with multihomed host:
it certainly implied to me that it would override all domain lookups for that host
I am not seeing that
https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-host-overrides.html#host-overrides
Host overrides define new records or override existing records so that local clients receive the configured responses instead of responses from upstream DNS servers.
So it says define "new" records... The override says existing records from "upstream DNS servers."
if you resolve host.domain.tld to 1.2.3.4 from the public internet, but you want it to resolve to 192.168.1.100 then is creating an override in your local resources would return 192.168.1.100 vs the public 1.2.3.4
Not sure why you would think creating an override for something that is also a local resource would prevent any other local resource records from being returned.
-
@johnpoz Thanks, I should have consulted the docs, but thought I understood what was going on based on the prompt in the UI:
Enter any individual hosts for which the resolver's standard DNS lookup process should be overridden and a specific IPv4 or IPv6 address should automatically be returned by the resolver. Standard and also non-standard names and parent domains can be entered, such as 'test', 'nas.home.arpa', 'mycompany.localdomain', '1.168.192.in-addr.arpa', or 'somesite.com'. Any lookup attempt for the host will automatically return the given IP address, and the usual lookup server for the domain will not be queried for the host's records.
I now understand that words "the resolver's standard DNS lookup process" are intended to mean the upstream lookup process, but they could also have referred to the lookup process offered by the resolver to its clients.
As for assuming that an override would prevent other resources from being returned, well, that's what it means to override something - replace its behavior. So if the reader thinks queries for local resources are what's being discussed, the idea of an "override" suggests -- strongly -- replacement of the result. Merging the query with other local resource records would be an unexpected and complex behavior in that context.
I personally think the prompt would be better -- that is, impossible to misinterpret -- if:
-
"any individual hosts" were changed to something that made it clear that hosts registered from DHCP leases were not included, and therefore the word "any" isn't actually true.
-
"returned by the resolver" were changed to "used by the resolver". "Returned" furthers the misconception that overrides are intended for downstream, not upstream use.
Thanks for pointing out my misunderstanding.
-
-
@dgilmour77 wording can be challenging whenever you have tech people writing info for users to be honest. Writing notes or docs can be difficult in general. But when someone is writing a note about something they tend to assume a certain knowledge level of the reader, normally based on their own understanding. Writing docs in mind where user does not understand the basics of what the doc is about is harder.. You either get to wordy trying to explain it to someone with little or no foundation, so users eyes tend to glaze over trying to read it or understand it. Or you seem to be talking down to people that do understand how it works in general and just want the tech details. Not docs for 5 year olds, etc.
That note for example is perfectly clear to me, but then again I have been working with dns since dns became a thing ;) I think I fired up my first bind server on one of the early releases of red hat linux.. Sometime in the mid 90s
The use of override in the host section, is redundant wording to be honest - and I believe meant for people with little understanding of dns in general. Its a given if you create a local resource for some fqdn, that this will "override" any record from some other NS. It is basic dns.. If I ask a ns for some fqdn, and it has a local resource or cache - its going to return that and not ask any other ns for what they have. So adding override to the description is not needed to be honest.
-
@johnpoz John, I feel your pain. Wording manuals and designing UIs is indeed hard. I've been doing it for almost half a century professionally.
I think many pfSense users are pros, but others are learning as they go. Based on some of the questions I see you respond to, some don't really understand their own setups. The docs are generally good and so some people are literally learning networking as they go. As a result, I think you have readers that span a pretty wide range.
The suggestions I made above are made in that spirit: tiny tweaks that don't add length, but may help to close off some inadvertent blind alleys by making the language just a tad more precise.
