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

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

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

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

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

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

Re: resolver: DNS format error from

Fedora 37 has more recent version in updates. I would recommend when in doubt trying to update your system, it might have been fixed already. But this problem is not on your side. You can try with dig some queries to their server: $ dig @195.178.56.17 +norec ns1.apr.gov.rs +nocookie | grep

Re: Problem with subdomain delegation - NS RR ignored?

What is status of your dnssec-validation? .hub does not exist in public dns tree and dnssec has a proof that it does not exist. Any validating resolver will therefore turn the response to NXDOMAIN. You should use your own existing domain with a proper delegation instead. Or use just home.arpa

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

Can update-policy accept IP addresses ?

Currently we have (for our Master zone) a list of IPs that can update our DNS master using the allow-update statement: zone "redacted.ac.nz" { type master; allow-update { ::1; 127.0.0.1; 131.123.103.2; 131.123.88.3; ... } We are wanting to transition to the more modern

Re: Can update-policy accept IP addresses ?

> On 24 May 2023, at 13:59, Patrick Rynhart wrote: > > Currently we have (for our Master zone) a list of IPs that can update > our DNS master using the allow-update statement: > > zone "redacted.ac.nz" { > type master; > allow-update { > ::1; > 127.0.0.1; > 131.123.103.2; >