Re: migration to new isp - now private addresses showing up publicly?

[Kaya Saman]

Hi Mark,


it looks like things are fixed!! :-) :-) :-)


Just checking with mxtoolbox now and all lights are green.


Thank you so much, I really appreciate it!


Best Regards,


Kaya


On 5/24/23 00:26, Mark Andrews wrote:

Follow example 4 on . 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  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  wrote:


On 5/23/23 20:18, Sten Carlsen wrote:



On 23 May 2023, at 19.46, Kaya Saman  wrote:


On 5/23/23 18:07, Sten Carlsen wrote:

On 23 May 2023, at 19.00, Kaya Saman  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 

Re: migration to new isp - now private addresses showing up publicly?

[Mark Andrews]

Follow example 4 on . 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  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  wrote:
>>> 
>>>  
>>> On 5/23/23 20:18, Sten Carlsen wrote:
 
 
> On 23 May 2023, at 19.46, Kaya Saman  wrote:
> 
> 
> On 5/23/23 18:07, Sten Carlsen wrote:
>>> On 23 May 2023, at 19.00, Kaya Saman  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 

Re: migration to new isp - now private addresses showing up publicly?

[Kaya Saman]

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  wrote:




On 5/23/23 20:18, Sten Carlsen wrote:




On 23 May 2023, at 19.46, Kaya Saman  wrote:


On 5/23/23 18:07, Sten Carlsen wrote:

On 23 May 2023, at 19.00, Kaya Saman  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 

Re: migration to new isp - now private addresses showing up publicly?

[Mark Andrews]

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  wrote:
> 
> 
> 
> 
>> On 5/23/23 20:18, Sten Carlsen wrote:
>> 
>> 
>>> On 23 May 2023, at 19.46, Kaya Saman  wrote:
>>> 
>>> 
>>> 
>>> On 5/23/23 18:07, Sten Carlsen wrote:
>> On 23 May 2023, at 19.00, Kaya Saman  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' 

Re: migration to new isp - now private addresses showing up publicly?

[Kaya Saman]

On 5/23/23 20:18, Sten Carlsen wrote:




On 23 May 2023, at 19.46, Kaya Saman  wrote:


On 5/23/23 18:07, Sten Carlsen wrote:

On 23 May 2023, at 19.00, Kaya Saman  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

Re: migration to new isp - now private addresses showing up publicly?

[Sten Carlsen]

> On 23 May 2023, at 19.46, Kaya Saman  wrote:
> 
> 
> 
> On 5/23/23 18:07, Sten Carlsen wrote:
>> 
>>> On 23 May 2023, at 19.00, Kaya Saman  
>>>  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.
> The crazy thing is that I am using the DNS check tool from mxtoolbox. So far 
> it's telling me:
> 
> 
> 
> Bad Glue Detected
> Parent server gave glue for ns2.domain.com to be int_dns2 but we resolve that 
> hostname to ext_dns2
> 
> 
> 
> Another weird issue is that it's reading the serial from the zone file to be:
> 
> 
> Serial numbers match
> 2022022801
> 
> That's my 'internal' zone! Not the 'external' zone and should not be anywhere 
> on the public internet at all.
> 
> 
> 
>>> Currently I tried putting this into my master config:
>>> 
>>> 
>>> zone "domain.com" {
>>>type master;
>>>file "/var/named/var/named/domain-external.db";
>>> notify explicit;
>>> also-notify { int_dns2; int_dns3; };
>>> allow-transfer { ext_dns2; ext_dns3; };
>>> allow-query { ext_dns2; ext_dns3; !internals; any; };
>>> };
>>> 
>>> 
>>> 
>>> And this into my slave config:
>>> 
>>> 
>>> 
>>> zone "domain.com" {
>>>type slave;
>>>file "/var/named/var/named/domain-external.db";
>>> masters { ext_dns1; };
>>> // allow-notify { ext_dns1; };
>>>allow-query { int_dns1; !internals; any; };
>>> };
>>> 
>>> 
>>> But it doesn't seem to mesh up?
>>> 
>>> 
>>> The general.log file is telling me this:
>>> 
>>> zone domain.com/IN/external: refresh: retry limit for master ext_dns1#53 
>>> exceeded (source 0.0.0.0#0)
>>> 
>>> -- 
>>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
>>> this list
>>> 
>>> ISC funds the 

Re: migration to new isp - now private addresses showing up publicly?

[Kaya Saman]

On 5/23/23 18:07, Sten Carlsen wrote:



On 23 May 2023, at 19.00, Kaya Saman  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



The crazy thing is that I am using the DNS check tool from mxtoolbox. So 
far it's telling me:



Bad Glue Detected
Parent server gave glue for ns2.domain.com to be int_dns2 but we resolve 
that hostname to ext_dns2



Another weird issue is that it's reading the serial from the zone file 
to be:



Serial numbers match
2022022801

That's my 'internal' zone! Not the 'external' zone and should not be 
anywhere on the public internet at all.




Currently I tried putting this into my master config:


 zone "domain.com" {
type master;
file "/var/named/var/named/domain-external.db";
 notify explicit;
 also-notify { int_dns2; int_dns3; };
 allow-transfer { ext_dns2; ext_dns3; };
 allow-query { ext_dns2; ext_dns3; !internals; any; };
 };



And this into my slave config:



 zone "domain.com" {
type slave;
file "/var/named/var/named/domain-external.db";
 masters { ext_dns1; };
 // allow-notify { ext_dns1; };
allow-query { int_dns1; !internals; any; };
 };


But it doesn't seem to mesh up?


The general.log file is telling me this:

zone domain.com/IN/external: refresh: retry limit for master ext_dns1#53 
exceeded (source 0.0.0.0#0)

--
Visithttps://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 athttps://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

Re: migration to new isp - now private addresses showing up publicly?

[Sten Carlsen]

> 
> On 23 May 2023, at 19.00, Kaya Saman  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.
> 
> Currently I tried putting this into my master config:
> 
> 
> zone "domain.com" {
>type master;
>file "/var/named/var/named/domain-external.db";
> notify explicit;
> also-notify { int_dns2; int_dns3; };
> allow-transfer { ext_dns2; ext_dns3; };
> allow-query { ext_dns2; ext_dns3; !internals; any; };
> };
> 
> 
> 
> And this into my slave config:
> 
> 
> 
> zone "domain.com" {
>type slave;
>file "/var/named/var/named/domain-external.db";
> masters { ext_dns1; };
> // allow-notify { ext_dns1; };
>allow-query { int_dns1; !internals; any; };
> };
> 
> 
> But it doesn't seem to mesh up?
> 
> 
> The general.log file is telling me this:
> 
> zone domain.com/IN/external: refresh: retry limit for master ext_dns1#53 
> exceeded (source 0.0.0.0#0)
> 
> -- 
> 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

Re: migration to new isp - now private addresses showing up publicly?

[Kaya Saman]

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?


Currently I tried putting this into my master config:


    zone "domain.com" {
   type master;
   file "/var/named/var/named/domain-external.db";
    notify explicit;
    also-notify { int_dns2; int_dns3; };
    allow-transfer { ext_dns2; ext_dns3; };
    allow-query { ext_dns2; ext_dns3; !internals; any; };
    };



And this into my slave config:



    zone "domain.com" {
   type slave;
   file "/var/named/var/named/domain-external.db";
    masters { ext_dns1; };
    // allow-notify { ext_dns1; };
   allow-query { int_dns1; !internals; any; };
    };


But it doesn't seem to mesh up?


The general.log file is telling me this:

zone domain.com/IN/external: refresh: retry limit for master ext_dns1#53 
exceeded (source 0.0.0.0#0)


--
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

Re: migration to new isp - now private addresses showing up publicly?

[Kaya Saman]

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.





Hi, I omitted those but here they are:


acl internals {
    127.0.0.0/8;
    192.168.0.0/16;
    172.16.0.0/12;
    10.0.0.0/8;
};

// These zones are already covered by the empty zones listed below.
// If you remove the related empty zones below, comment these lines out.
    disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
    disable-empty-zone 
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
    disable-empty-zone 
"1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";



// If you enable a local name server, don't forget to enter 127.0.0.1
// first in your /etc/resolv.conf so this server will be queried.
// Also, make sure to enable it in /etc/rc.conf.

// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };

// RFCs 1912, 5735 and 6303 (and BCP 32 for localhost)
zone "localhost"    { type master; file 
"/usr/local/etc/namedb/master/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/localhost-reverse.db"; };
zone "255.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };


// RFC 1912-style zone for IPv6 localhost address (RFC 6303)
zone "0.ip6.arpa"   { type master; file 
"/usr/local/etc/namedb/master/localhost-reverse.db"; };


// "This" Network (RFCs 1912, 5735 and 6303)
zone "0.in-addr.arpa"   { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };


// Private Use Networks (RFCs 1918, 5735 and 6303)
zone "10.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "16.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "17.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "18.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "19.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "20.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "21.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "22.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "23.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "24.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "25.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "26.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "27.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "28.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "29.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "30.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "31.172.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "168.192.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };


// Shared Address Space (RFC 6598)
zone "64.100.in-addr.arpa" { type master; file 
"/usr/local/etc/namedb/master/empty.db"; };
zone "65.100.in-addr.arpa" { type master; file 

Re: migration to new isp - now private addresses showing up publicly?

[Matus UHLAR - fantomas]

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.



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Silvester Stallone: Father of the RISC concept.
--
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