<div dir="ltr">Hi Ubence.<div>Firstly, may we see your configs please. It's impossible to say exactly what's going on from a human description.</div><div><br></div><div>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.</div><div><br></div><div>Thirdly, naming of multi-homed systems. A long time ago, in a previous job, I tried to work out how to make (say) "<a href="http://system.lab.domain.com">system.lab.domain.com</a>" 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*.<br></div><div>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:</div><div><br></div><div>zone "<a href="http://domain.com">domain.com</a>" {</div><div> type primary;</div><div> file "<a href="http://db.domain.com">db.domain.com</a>";</div><div>};</div><div><br></div><div>Contents at least:</div><div>@ SOA etc...<br></div><div>@ IN NS <fqdn_of_production_ns.><br></div><div>lab IN NS <fqdn_of_lab_ns.> ;don't forget the delegation</div><div>system IN A 10.32.10.1</div><div><br></div><div>zone "<a href="http://lab.domain.com">lab.domain.com</a>" {</div><div> type primary;</div><div> file "<a href="http://db.lab.domain.com">db.lab.domain.com</a>";</div><div>};</div><div><br></div><div><div>Contents at least:</div><div>@ SOA etc...<br></div><div><a class="gmail_plusreply" id="plusReplyChip-2">@</a> IN NS <fqdn_of_lab_ns.></div><div>system IN A 10.32.10.1</div><div><br></div></div><div>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 "<a href="http://system.domain.com">system.domain.com</a>" for its production side or <a href="http://system.lab.domain.com">system.lab.domain.com</a>" for its lab side. There is no ambiguity about what address "system" has because each one now has a unique name.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Hope that helps. But as i said, configs please and then *we* don't have to guess :)</div><div>Cheers, Greg</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 28 Jun 2023 at 23:45, Ubence Quevedo <<a href="mailto:thatrat@gmail.com">thatrat@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><br>I have two domains configured, a production and lab/testing domain [let's say <a href="http://domain.com" target="_blank">domain.com</a> and <a href="http://lab.domain.com" target="_blank">lab.domain.com</a>].<br><br>I have a few different networks configured [<a href="http://192.168.10.0/24" target="_blank">192.168.10.0/24</a> and <a href="http://10.32.10.0/24" target="_blank">10.32.10.0/24</a>].<br><br>I have a system that has two network cards on both the 192.168.10.X network and 10.32.10.X network.<br><br>I have a remote system that is also configured to on both networks, with hostnames on both domains/networks.<br><br>I have a hostname entry in my primary master for the <a href="http://domain.com" target="_blank">domain.com</a> [<a href="http://system.lab.domain.com/192.168.10.170" target="_blank">system.lab.domain.com/192.168.10.170</a>], but there are other systems configured via the bind 9 system that serves out <a href="http://lab.domain.com" target="_blank">lab.domain.com</a> with an entry for this system [<a href="http://system.lab.domain.com/10.32.10.1" target="_blank">system.lab.domain.com/10.32.10.1</a>].<br><br>On the primary DNS server, the <a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a> 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 <a href="http://lab.domain.com" target="_blank">lab.domain.com</a> 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.<br><br>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.<br><br>What's happening is the that hostname I have configured on the primary name server [<a href="http://system.lab.domain.com/192.168.10.170" target="_blank">system.lab.domain.com/192.168.10.170</a>] is not taking precedence over the secondary domain that is configured [<a href="http://system.lab.domain.com/10.32.10.1" target="_blank">system.lab.domain.com/10.32.10.1</a>].<br><br>Any resolution now for the system.lab.totusmel.coml hostname now brings back 10.32.10.1 instead of the 192.168.10.170.<br><br>I think it's because the lab domain takes precedence because the domain name <a href="http://lab.domain.com" target="_blank">lab.domain.com</a> is a higher priority than <a href="http://domain.com" target="_blank">domain.com</a> even with the system.lab tacked onto the primary domain.<br><br>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 <a href="http://system.lab.domain.com/10.32.10.1" target="_blank">system.lab.domain.com/10.32.10.1</a> entry and if it came from the 192.168.10.X network, return the <a href="http://system.lab.domain.com/192.168.10.170" target="_blank">system.lab.domain.com/192.168.10.170</a> entry.<br><br>This seemed to work after re-arranging the order of the main configuration file, and I could resolve the <a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a> as 192.168.10.170 as I intended but this then broke all of the host entries I had configured for <a href="http://domain.com" target="_blank">domain.com</a> as none were resolvable.<br><br><br>My question is, is there any way to "properly" return a hostname/IP based on what network the request is coming from?<br><br>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.<br><br><br>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.<br><div><br></div><div>Any thoughts or advice would be greatly appreciated!</div></div>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>