migration to new isp - now private addresses showing up publicly?
Kaya Saman
kayasaman at gmail.com
Tue May 23 22:13:21 UTC 2023
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 <kayasaman at gmail.com> wrote:
>>
>>
>>
>>
>> On 5/23/23 20:18, Sten Carlsen wrote:
>>>
>>>
>>>> On 23 May 2023, at 19.46, Kaya Saman <kayasaman at gmail.com> wrote:
>>>>
>>>>
>>>> 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....
>>>>
>>>>
>>> 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 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/c62e0f3d/attachment-0001.htm>
More information about the bind-users
mailing list