Thanks all for the responses and guidance.
This is just me doing some tweaky things with a few local bind servers with
systems on multiple vlans trying to properly resolve traversing multiple
subnets and thinking I could leverage views for something it wasn't meant
for [but I think would be handy if it could].
I'll be adding the unique hostname entries into the appropriate bind server
so that they replicate to the primary server to be accessible.
To answer the question about search domains, I always try to do FQDN to
single out what it is that I'm trying to get to.
Again, thanks!
On Thu, Jun 29, 2023 at 8:32 AM Greg Choules <
gregchoules+bindus...@googlemail.com> wrote:
> Hi.
> Ah, I got the networks the wrong way round.
>
> Sorry, it wasn't until I saw Sten's response that it occurred to me that
> not everyone knows how views work. Indeed a query will be tested against
> each view, top down. If it satisfies the criteria for a view (either/both
> match-clients and match-destinations) it stops there. If that view can't
> answer, sorry. No further views are tested. This is why the 'any' view is
> last, like a default route.
>
> Having system10/system-10, system20, system30 etc.. or some such naming
> convention, all in "lab.domain.com" will certainly work. The goal is
> uniqueness. How you achieve it is down to preference.
>
> I have an additional thought about primaries and secondaries. In my
> experience, unless there are completely different teams who don't talk much
> to each other running separate DNS servers, it is best to keep all your
> primary zones in one place (or two for resilience). It makes it easier to
> administer and to understand which way data is flowing.
>
> Cheers, Greg
>
> On Thu, 29 Jun 2023 at 16:14, Ubence Quevedo <that...@gmail.com> wrote:
>
>> Hi,
>>
>> Actually, that config was from the primary at 192.168.10.3.
>>
>> Below is the config from the lab DNS server at 10.32.1.6/192.168.10.183:
>> include "/etc/bind/rndc.key";
>> include "/etc/bind/ddns-key.key";
>>
>> zone "lab.domain.com" {
>> type master;
>> forwarders {};
>> file "/var/lib/bind/db.lab.domain.com";
>> update-policy {
>> grant ddns-key wildcard *.lab.domain.com A DHCID;
>> };
>> notify yes;
>> allow-transfer { 192.168.10.3; };
>> };
>>
>> zone "domain.com" {
>> type secondary;
>> masterfile-format text;
>> file "/var/lib/bind/db.domain.com";
>> primaries { 192.168.10.3; };
>> };
>>
>> zone "1.32.10.in-addr.arpa" {
>> type master;
>> forwarders {};
>> file "/var/lib/bind/db.1.32.10.in-addr.arpa";
>> update-policy {
>> grant ddns-key wildcard *.domain.com A DHCID;
>> };
>> };
>>
>> zone "10.32.10.in-addr.arpa" {
>> type master;
>> forwarders {};
>> file "/var/lib/bind/db.10.32.10.in-addr.arpa";
>> update-policy {
>> grant ddns-key wildcard *.10.32.10.in-addr.arpa PTR;
>> };
>> };
>>
>> zone "20.32.10.in-addr.arpa" {
>> type master;
>> forwarders {};
>> file "/var/lib/bind/db.20.32.10.in-addr.arpa";
>> update-policy {
>> grant ddns-key wildcard *.20.32.10.in-addr.arpa PTR;
>> };
>> };
>>
>> zone "30.32.10.in-addr.arpa" {
>> type master;
>> forwarders {};
>> file "/var/lib/bind/db.30.32.10.in-addr.arpa";
>> update-policy {
>> grant ddns-key wildcard *.30.32.10.in-addr.arpa PTR;
>> };
>> };
>>
>> I now realize that views is *NOT* what I want to do since it's either one
>> view or the other not an and type of thing.
>>
>> The reason I was trying to do just both domain.com and lab.domain.com is
>> that I have let's encrypt certificates setup through both domain names.
>> Doing the net2.domain.com, net3.domain.com, etc. I think would mean that
>> I'd need certificates for each of those zones.
>>
>> However, I think if I just slightly change the hostname for the
>> lab.domain.com like system10.lab.domain.com, system20.lab.domain.com,
>> etc. and have those setup with different IP addresses, that *should* work.
>> No ambiguity there since it's an entirely different hostname being resolved
>> and still keep the lab.domain.com domain name.
>>
>> Ultimately, views won't work, which is very clear now, but having
>> distinct hostnames for each instance on a different subnet *should* work
>> and could be put on the lab.domain.com system so that when they are
>> replicated to the primary name server they will resolve appropriately.
>>
>> Does that sound about right?
>>
>> On Thu, Jun 29, 2023 at 7:53 AM Greg Choules <
>> gregchoules+bindus...@googlemail.com> wrote:
>>
>>> Hi Ubence.
>>> That is starting to get complex!
>>>
>>> Firstly, yes BIND parses views top down, so order matters.
>>> Secondly, most specific domain wins (like more specific routes).
>>>
>>> I now see that you have created three levels of zones:
>>> domain.com
>>> lab.domain.com
>>> system.lab.domain.com
>>>
>>> This config looks like it's from the 10... primary, correct? Can you
>>> send the config from 192.168.10.183 as well please?
>>> What zones does it have and are there views on it too?
>>>
>>> Rather than speculate why adding that secondary zone has started the
>>> problems, dump the database - rndc dumpdb -all - and see what it contains.
>>> That should show you what the server thinks it should be doing. Also, check
>>> the logs for what got transferred.
>>>
>>> I don't understand the purpose of both lab.domain.com and
>>> system.lab.domain.com, unless the intention is to provide a general
>>> zone for all things 'lab' and a set of more specific zones for just this
>>> system?
>>>
>>>
>>> I stand by my opinion that I still wouldn't use views for this and that
>>> the way to do it is to give every numbered interface on every machine its
>>> own domain.
>>> So if "system" has six addresses it has six FQDNs, each one in a
>>> different zone. That alone may sound at first like it is complicating
>>> matters, but consider this: each address exists for a reason and in a
>>> different network (or you wouldn't need a different address), so a domain
>>> suffix can be viewed as the domain for a given network and all interfaces
>>> of all devices that sit in that network share a domain suffix.
>>>
>>> If "system" is the end host itself I wouldn't give it its own zone. It's
>>> not illegal (and can actually be useful in some edge cases), just overly
>>> complicated. If this were my network I'd do something like:
>>>
>>> zone "domain.com" {
>>> type primary;
>>> #contains delegations for net1, net2...net6
>>>
>>> zone "net1.domain.com" {
>>> # 192.168.10.0/24
>>> etc...
>>>
>>> zone "net2.domain.com" {
>>> # 10.32.1.0/24
>>> etc...
>>>
>>> zone "net3.domain.com" {
>>> # 10.32.10.0/24
>>> etc...
>>>
>>> zone "net4.domain.com" {
>>> # 10.32.20.0/24
>>> etc...
>>>
>>> zone "net5.domain.com" {
>>> # 10.32.30.0/24
>>> etc...
>>>
>>> zone "net6.domain.com" {
>>> # ?.?.?.?
>>> etc...
>>>
>>> "system" has A records in all of these, with the relevant interface
>>> address for the network. Clients lookup the FQDN of interest to them at the
>>> time. This way there is guaranteed no ambiguity.
>>>
>>> Cheers, Greg
>>>
>>>
>>> On Thu, 29 Jun 2023 at 15:00, 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, even though
>>>> I set it to match-clients { any; }.
>>>>
>>>> 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; };
>>>> zone "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; };
>>>> zone "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; };
>>>> zone "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; };
>>>> zone "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; };
>>>> zone "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" {
>>>> type master;
>>>> forwarders {};
>>>> file "/var/lib/bind/db.domain.com";
>>>> update-policy {
>>>> grant ddns-key wildcard *.domain.com A DHCID;
>>>> };
>>>> notify yes;
>>>> allow-transfer { 192.168.10.183; };
>>>> };
>>>> zone "lab.domain.com" {
>>>> type secondary;
>>>> masterfile-format text;
>>>> file "/var/lib/bind/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 IN SOA ns1.domain.com. 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.
>>>> $ORIGIN 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 zone currently has an entry for
>>>> system.lab.domain.com for 192.168.10.170 and the secondary
>>>> lab.domain.com has an entry for 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 which
>>>> again I think had some type of precedence on the "fuller" FQDN being
>>>> served, and the system.lab from the 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, 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 with system hostname info which *might* complicate things.
>>>>
>>>>
>>>> On Wed, Jun 28, 2023 at 9:33 PM Greg Choules <
>>>> gregchoules+bindus...@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" 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 <that...@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@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
>>
>
--
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
