Follow example 4 on <https://kb.isc.org/docs/aa-0085>. You haven’t got named to read the keys into named.conf nor told named to use the keys for notify and zone transfers. Also just use TSIG in your allow-transfer acls.
include “external.key”; include “internal.key”; masters { 10.0.0.1 key external; }; masters { 10.0.0.1 key internal; }; also-notify { 10.0.0.2 key external; }; also-notify { 10.0.0.2 key internal; }; allow-transfer { key external; }; allow-transfer { key internal; }; Mark > On 24 May 2023, at 08:13, Kaya Saman <kayasa...@gmail.com> wrote: > > Not sure if I did something wrong? Unfortunately the same thing has happened, > the internal zone file got transferred as the external zone file? > > I followed your suggestion and this article here: > https://bind9.readthedocs.io/en/v9_18_4/chapter6.html > which I think you mentioned at the bottom? > > I created keys called internal. and external. from the example in the docs: > $ tsig-keygen host1-host2. > host1-host2.key > > they got stored in files called external.key and internal.key within the > namedb directory > > So my named.conf file now contains: > > acl internals { > 127.0.0.0/8; > 192.168.0.0/16; > 172.16.0.0/12; > 10.0.0.0/8; > }; > > acl all-keys {key internal.; key external.;}; > > I then referenced the keys like so on the master for both internal and > external views (I'm only showing external in this example): > > view "external" { > match-clients { key external.; !all-keys; !internals; any; }; > allow-recursion { > 127.0.0.1; > }; > > > zone "domain.com" { > type master; > file "/var/named/var/named/domain-external.db"; > notify explicit; > also-notify { int_dns2; int_dns3; }; > allow-transfer { int_dns2; int_dns3; }; > allow-query { ext_dns2; ext_dns3; !internals; any; }; > allow-update { key external. ;}; > }; > }; > > and on the slave: > > view "external" { > match-clients { key external.; !all-keys; !internals; any; }; > allow-recursion { > 127.0.0.1; > }; > > > zone "domain.com" { > type slave; > file "/var/named/var/named/domain-external.db"; > masters { int_dns1; }; > // allow-notify { ext_dns1; }; > allow-query { int_dns1; !internals; any; }; > }; > }; > > I'm sure there are extra steps needed which I have omitted somewhere?? > > On 5/23/23 22:03, Mark Andrews wrote: >> Use different TSIG keys rather than IP address to select which view matches >> for notify and zone transfers. >> >> acl all-keys {key internal; key external;}; >> >> match-clients {key internal; !all-keys; …}; >> >> The !all-keys is to prevent matching by IP for the listed keys. >> >> Do similar for all views. >> >> Then add keys to primary definitions and server clauses with keys at the >> view level for notify. >> >> I’m pretty sure there is a knowledge base article with full details. >> >> -- >> Mark Andrews >> >>> On 24 May 2023, at 05:40, Kaya Saman <kayasa...@gmail.com> wrote: >>> >>> >>> On 5/23/23 20:18, Sten Carlsen wrote: >>>> >>>> >>>>> On 23 May 2023, at 19.46, Kaya Saman <kayasa...@gmail.com> wrote: >>>>> >>>>> >>>>> On 5/23/23 18:07, Sten Carlsen wrote: >>>>>>> On 23 May 2023, at 19.00, Kaya Saman <kayasa...@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 5/23/23 12:47, Matus UHLAR - fantomas wrote: >>>>>>>> >>>>>>>>> On 23.05.23 12:22, Kaya Saman wrote: >>>>>>>>> I've got a very strange problem that has emerged somehow after >>>>>>>>> migrating my isp. >>>>>>>>> >>>>>>>>> >>>>>>>>> My setup previously used 2x servers in master/slave configuration for >>>>>>>>> my public "view" and then had 3x servers for the "internal" view. >>>>>>>>> This was working fine for years and I have been regularly testing >>>>>>>>> using online dns healthcheck sites such as mxtoolbox etc... >>>>>>>>> >>>>>>>>> >>>>>>>>> Now when I try to run any type of check from mxtoolbox or other site >>>>>>>>> eg. https://dnschecker.org/ I am getting my private IP's showing >>>>>>>>> instead of the public ones? >>>>>>>>> >>>>>>>>> >>>>>>>>> Initially it started off by my external zone files not transferring >>>>>>>>> which I managed to see that the information was trying to traverse my >>>>>>>>> NAT (I know, not the best practice to have all dns servers on the >>>>>>>>> same network). >>>>>>>>> >>>>>>>>> >>>>>>>>> As a result external emails from my mail server are not working too >>>>>>>>> well with a hit and miss type thing going on right now. >>>>>>>>> >>>>>>>>> >>>>>>>>> Just to go over, my zone files are fine as the 'external' ones only >>>>>>>>> have public ip addresses in them and do not include any type of >>>>>>>>> internal addressing whatsoever. >>>>>>>>> >>>>>>>>> >>>>>>>>> Here's an example of the config in named.conf for the master: >>>>>>>>> >>>>>>>>> view "external" { >>>>>>>>> match-clients { !internals; any; }; >>>>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>>> view "external" { >>>>>>>>> match-clients { !internals; any; }; >>>>>>>>> >>>>>>>> I don't see your definition of "internals". >>>>>>>> Also, I don't see your definition of internal view. >>>>>>>> if internal IP addresses are visible on the internet, obviously the >>>>>>>> internet sources fall into your internal view, not into this one. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Finally, I understand what is going on and things get stranger.... >>>>>>> >>>>>>> >>>>>>> The internal IP addressing is being served up by the slave servers. >>>>>>> They seem to have pulled the file domain.db and renamed it to >>>>>>> domain-external.db??? >>>>>>> >>>>>>> >>>>>>> Of course the 'master' machine is already serving up domain-external.db >>>>>>> to the public domain. This has the correct IP addressing with >>>>>>> everything else such as dkim and dmarc. >>>>>>> >>>>>>> >>>>>>> So, currently I think the whole problem is stemming from the fact that >>>>>>> the zone transfers are not working correctly for my external view >>>>>>> between 'master' and 'slave' servers. >>>>>>> >>>>>>> >>>>>>> How can I do that without needing to traverse my NAT? >>>>>>> >>>>>>> >>>>>> When migrating ISP, are you sure that there is not another NAT in the >>>>>> ISP router? >>>>>> That would explain this. The internet would present itself as >>>>>> 192.168.xx.xx and match your internals. >>>>> >>>>> I can certainly ask. Though I am on a business package with multiple >>>>> static public IPv4 addresses. I think I have a /28 block if memory serves >>>>> me well.... >>>>> >>>> You might find that it has some kind of address translation built-in "to >>>> protect your business" or whatever. To me it still smells that way. >>>> You might look at the IP address for the port you think is the internet - >>>> if that has an 192.168.x.x. or 172.16.x.x. or 10.x.x.x it would be clear >>>> that is what your problem is. It can still be solved but other setup >>>> details will be needed. >>> >>> I'm not sure what you mean by "port to the internet"? >>> >>> The actual DNS servers themselves don't have a public IP address. They are >>> all running internal addressing and have been for many years, another words >>> the address on the NIC itself is private. What I am doing is using NAT/PAT >>> to translate the public address to the private address of the server itself. >>> >>> So essentially on my side I am doing int_dns -> ext_dns -> internet >>> Reverse then becomes internet -> ext_dns (port 53 udp/tcp) -> int_dns (port >>> 53 udp/tcp) >>> >>> That's how I am handling things. I wonder if that is the cause or if there >>> is something that my ISP has in place? Hence the fact that I'm using >>> "views" to differentiate between 'internal' and 'external' addresses. >>> Actually I did run a tcpdump on the server and my firewall/gateway both and >>> the addresses coming in are both from public domain. No internal addressing >>> hitting the server WAN side, even when my NAT/PAT translates my ext_ip to >>> int_ip, the public address of say the mxtoolbox checker is still there. >>> >>> I should know in a few days if there is anything my ISP is doing in the >>> middle. But* I really am not sure if it is something that I am doing within >>> the config, though I have posted pretty much all of my named.conf file up. >>> Though it still doesn't explain how the IP addresses keep 'flapping' - >>> especially in mxtoolbox using the DNS Check. Sometimes I see internal >>> addresses and sometimes I see external addresses?? It just seems like >>> random occurrence really unless I badly misconfigured something? >>> -- >>> 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- 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