Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Greg Choules]

Hi Ubence.
Firstly, may we see your configs please. It's impossible to say exactly
what's going on from a human description.

Secondly, views and different answers. Yes it *is* entirely possible to use
views to provide answers based on client IP - `match-clients. I would start
with the most specific view first with a `match-clients` clause, then a
general view without one. If you only have two choices.

Thirdly, naming of multi-homed systems. A long time ago, in a previous job,
I tried to work out how to make (say) "system.lab.domain.com" resolve to
different addresses, depending on who was asking the question, or from
which direction they were asking it and it nearly drove me mad. I concluded
that "sytem" should not be regarded as one domain, but one domain *per
interface*.
So let's say that the box called "system" has two interfaces with addresses
192.168.10.170 for its lab side and 10.32.10.1 for its production side. I
would do this and not bother with views:

zone "domain.com" {
   type primary;
   file "db.domain.com";
};

Contents at least:
@ SOA etc...
@   IN   NS   <fqdn_of_production_ns.>
lab   IN   NS   <fqdn_of_lab_ns.>   ;don't forget the delegation
system   IN   A   10.32.10.1

zone "lab.domain.com" {
   type primary;
   file "db.lab.domain.com";
};

Contents at least:
@ SOA etc...
@   IN   NS   <fqdn_of_lab_ns.>
system   IN   A   10.32.10.1

Now to reach "system", depending on who you are, which direction you are
approaching it from and what network routeing and firewalls will allow you
either connect to "system.domain.com" for its production side or
system.lab.domain.com" for its lab side. There is no ambiguity about what
address "system" has because each one now has a unique name.

Note that this requires clients to use FQDNs, which IMHO is a good thing. I
always try to avoid "search...." in resolv.conf because it leaves the OS
stub resolver guessing what the user actually wants.


Hope that helps. But as i said, configs please and then *we* don't have to
guess :)
Cheers, Greg


On Wed, 28 Jun 2023 at 23:45, Ubence Quevedo <thatrat at gmail.com> wrote:

> Hi,
>
> I have two domains configured, a production and lab/testing domain [let's
> say domain.com and lab.domain.com].
>
> I have a few different networks configured [192.168.10.0/24 and
> 10.32.10.0/24].
>
> I have a system that has two network cards on both the 192.168.10.X
> network and 10.32.10.X network.
>
> I have a remote system that is also configured to on both networks, with
> hostnames on both domains/networks.
>
> I have a hostname entry in my primary master for the domain.com [
> system.lab.domain.com/192.168.10.170], but there are other systems
> configured via the bind 9 system that serves out lab.domain.com with an
> entry for this system [system.lab.domain.com/10.32.10.1].
>
> On the primary DNS server, the system.lab.domain.com worked great and
> pointed to 192.168.10.170, however I made the lab server a secondary on the
> primary and vice-a-versa so that the lab.domain.com entries would resolve
> for systems on the 192.168.10.X network so that the dual network capable
> system would be able to resolve lab hostnames from my primary DNS server.
> This is a Mac and the primary interface wins for name resolution as far as
> I can tell even though the other network interface is configured to point
> to the lab DNS server.
>
> This makes things work great to be able to resolve lab network host names,
> but the 10.32.10.X network isn't directly accessible to the 192.168.10.X
> network.
>
> What's happening is the that hostname I have configured on the primary
> name server [system.lab.domain.com/192.168.10.170] is not taking
> precedence over the secondary domain that is configured [
> system.lab.domain.com/10.32.10.1].
>
> Any resolution now for the system.lab.totusmel.coml hostname now brings
> back 10.32.10.1 instead of the 192.168.10.170.
>
> I think it's because the lab domain takes precedence because the domain
> name lab.domain.com is a higher priority than domain.com even with the
> system.lab tacked onto the primary domain.
>
> I started dabbling with views and tried to set up specific views that
> would return a fully qualified hostname as a domain based on what network
> the request came from.  If the request came from the 10.32.10.X network,
> return the system.lab.domain.com/10.32.10.1 entry and if it came from the
> 192.168.10.X network, return the system.lab.domain.com/192.168.10.170
> entry.
>
> This seemed to work after re-arranging the order of the main configuration
> file, and I could resolve the system.lab.domain.com as 192.168.10.170 as
> I intended but this then broke all of the host entries I had configured for
> domain.com as none were resolvable.
>
>
> My question is, is there any way to "properly" return a hostname/IP based
> on what network the request is coming from?
>
> This seemed like it would work, and it kind of did, but even with a
> separate view of "any" for the hostnames of the production domain, this
> didn't quite work.
>
>
> I know this is a somewhat confusing set up, but I thought it might be
> possible to resolve a hostname difference with views based on the
> requesting network.
>
> Any thoughts or advice would be greatly appreciated!
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230629/60aad945/attachment-0001.htm>