> On 29 Jun 2023, at 15.59, Ubence Quevedo <that...@gmail.com> wrote:
>
> Hi Greg,
>
> Here's the most recent config that I tried that seemed to work, but
> ultimately broke resolution for the main zone domain.com
> <http://domain.com/>, even though I set it to match-clients { any; }.
Please remember that ONLY ONE view is matched. Your main view is only used if
none of the other views match.
>
> What I didn't mention in my original post was that I have other subnets
> configured for this remote host through vlans with different IP addresses.
> That's why there are so many other views. I was hoping the match-clients per
> each view would return the appropriate IP address per subnet making the
> request.
>
> include "/etc/bind/rndc.key";
> include "/etc/bind/ddns-key.key";
>
> view "192.168.10-net" {
> match-clients { 192.168.10.0/24 <http://192.168.10.0/24>; };
> zone "system.lab.domain.com <http://system.lab.domain.com/>" {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.192.168.10";
> };
> };
>
> view "10.32.1-net" {
> match-clients { 10.32.1.0/24 <http://10.32.1.0/24>; };
> zone "system.lab.domain.com <http://system.lab.domain.com/>" {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.10.32.1";
> };
> };
>
> view "10.32.10-net" {
> match-clients { 10.32.10.0/24 <http://10.32.10.0/24>; };
> zone "system.lab.domain.com <http://system.lab.domain.com/>" {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.10.32.10";
> };
> };
>
> view "10.32.20-net" {
> match-clients { 10.32.20.0/24 <http://10.32.20.0/24>; };
> zone "system.lab.domain.com <http://system.lab.domain.com/>" {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.10.32.20";
> };
> };
>
> view "10.32.30-net" {
> match-clients { 10.32.30.0/24 <http://10.32.30.0/24>; };
> zone "system.lab.domain.com <http://system.lab.domain.com/>" {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.10.32.30";
> };
> };
>
> view "main" {
> match-clients { any; };
> zone "domain.com <http://domain.com/>" {
> type master;
> forwarders {};
> file "/var/lib/bind/db.domain.com <http://db.domain.com/>";
> update-policy {
> grant ddns-key wildcard *.domain.com <http://domain.com/> A DHCID;
> };
> notify yes;
> allow-transfer { 192.168.10.183; };
> };
> zone "lab.domain.com <http://lab.domain.com/>" {
> type secondary;
> masterfile-format text;
> file "/var/lib/bind/db.lab.domain.com <http://db.lab.domain.com/>";
> primaries { 192.168.10.183; };
> };
> zone "10.168.192.in-addr.arpa" {
> type master;
> forwarders {};
> file "/var/lib/bind/db.10.168.192.in-addr.arpa";
> update-policy {
> grant ddns-key wildcard *.10.168.192.in-addr.arpa PTR;
> };
> };
> };
>
> The contents of /var/lib/bind/db.system.lab.domain.com.192.168.10:
> $ORIGIN .
> $TTL 604800 ; 1 week
> system.lab.domain.com <http://system.lab.domain.com/> IN SOA
> ns1.domain.com <http://ns1.domain.com/>. thatrat.gmail.com
> <http://thatrat.gmail.com/>. (
> 2023062800 ; serial
> 604800 ; refresh (1 week)
> 86400 ; retry (1 day)
> 2419200 ; expire (4 weeks)
> 604800 ; minimum (1 week)
> )
> NS ns1.domain.com <http://ns1.domain.com/>.
> $ORIGIN system.lab.domain.com <http://system.lab.domain.com/>.
> A 192.168.10.170
>
> The other /var/lib/bind/db.system.lab.domain.com.10.32.X.X follow a similar
> format with the domain name pointing to a different IP address for each
> "version" of the domain matching a view for a different entry subnet.
>
> Again, the domain.com <http://domain.com/> zone currently has an entry for
> system.lab.domain.com <http://system.lab.domain.com/> for 192.168.10.170 and
> the secondary lab.domain.com <http://lab.domain.com/> has an entry for
> system.lab.domain.com <http://system.lab.domain.com/> with 10.32.10.1.
>
> This was all working perfectly until I added the secondary domain to my
> config [essentially just the contents of the main view above] which it
> started only returning 10.32.10.1 for the system.lab.domain.com
> <http://system.lab.domain.com/> which again I think had some type of
> precedence on the "fuller" FQDN being served, and the system.lab from the
> domain.com <http://domain.com/> zone taking lesser precedence.
>
> It also seems that the bind configuration file is read from top down in
> processing order? I had the main view on top first, but then moved it below
> the other views, and then the 192.168.10-net view worked...but the main view
> did not work.
>
> I know this is an overly complicated setup and probably the simplest answer
> is just to remove the secondary zone from config so that there is only the
> one entry that resolves for the system.lab.domain.com
> <http://system.lab.domain.com/>, I just thought that there might be a away to
> have the hostname resolve differently based on what the requesting IP address
> was.
>
> I also have Dynamic DNS setup so that the ISC DHCP server will update
> domain.com <http://domain.com/> with system hostname info which *might*
> complicate things.
>
>
> On Wed, Jun 28, 2023 at 9:33 PM Greg Choules
> <gregchoules+bindus...@googlemail.com
> <mailto:gregchoules%2bbindus...@googlemail.com>> wrote:
>> 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
>> <http://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 <http://domain.com/>" {
>> type primary;
>> file "db.domain.com <http://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 <http://lab.domain.com/>" {
>> type primary;
>> file "db.lab.domain.com <http://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 <http://system.domain.com/>" for its
>> production side or system.lab.domain.com <http://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 <that...@gmail.com
>> <mailto:that...@gmail.com>> wrote:
>>> Hi,
>>>
>>> I have two domains configured, a production and lab/testing domain [let's
>>> say domain.com <http://domain.com/> and lab.domain.com
>>> <http://lab.domain.com/>].
>>>
>>> I have a few different networks configured [192.168.10.0/24
>>> <http://192.168.10.0/24> and 10.32.10.0/24 <http://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
>>> <http://domain.com/> [system.lab.domain.com/192.168.10.170
>>> <http://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
>>> <http://lab.domain.com/> with an entry for this system
>>> [system.lab.domain.com/10.32.10.1
>>> <http://system.lab.domain.com/10.32.10.1>].
>>>
>>> On the primary DNS server, the system.lab.domain.com
>>> <http://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 <http://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
>>> <http://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
>>> <http://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 <http://lab.domain.com/> is a higher priority than
>>> domain.com <http://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
>>> <http://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
>>> <http://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
>>> <http://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
>>> <http://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@lists.isc.org <mailto:bind-users@lists.isc.org>
>>> https://lists.isc.org/mailman/listinfo/bind-users
> --
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
