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

Reply via email to