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 <[email protected]> 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 <[email protected]> wrote:
>>>
>>>
>>> On 5/23/23 20:18, Sten Carlsen wrote:
>>>>
>>>>
>>>>> On 23 May 2023, at 19.46, Kaya Saman <[email protected]> wrote:
>>>>>
>>>>>
>>>>> On 5/23/23 18:07, Sten Carlsen wrote:
>>>>>>> On 23 May 2023, at 19.00, Kaya Saman <[email protected]> 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
>>> [email protected]
>>> 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: [email protected]
--
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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
