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<kayasaman at 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....


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 at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230523/a9313928/attachment-0001.htm>