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

2023-05-23 Thread Kaya Saman 

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 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; };
    allow-recursion {
    127.0.0.1;
    };


    zone "domain.com" {
    type master;
    file "/var/named/var/named/domain-external.db";
    notify yes;
    also-notify { pub_dns2; pub_dns3; };
    allow-transfer { pub_dns2; pub_dns3; };
    allow-query { pub_dns2; pub_dns3; !internals; any; };
    };

...

;


This shows the slave:


view "external" {
    match-clients { !internals; any; };
    allow-recursion {
    127.0.0.1;
    };


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

...

;



Both have the !internals macro there, so the servers should not throw up 
anything from the 'internal' view. It doesn't make sense that mxtoolbox 
and others, even sending mail from Google sees the private address of 
the machine? There's no chroot environment either contrary to the file 
path... I converted this back to normal many years ago when I started 
using Jails.



Additionally for the domain to transfer using the internal (private) 
network, do I need to change the 'allow-transfer' portion to the private 
addresses? I have read around a little bit but wasn't quite sure, though 
someone did suggest to use the 'notify explicit' statement, though I'm 
not sure of the difference exactly. Closest read on that I could find is 
from here: https://www.zytrax.com/books/dns/ch7/xfer.html#notify



Is it possible to suggest anything to get my servers working properly 
again? I'm running version 9.16.40 on the master and 9.16.39 on both 
slaves all built from FreeBSD ports.




Regards,


Kaya

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

2023-05-23 Thread 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

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

2023-05-23 Thread 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: resolver: DNS format error from

2023-05-23 Thread Petr Menšík 
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 status:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2078

$ dig @195.178.56.17 +norec ns1.apr.gov.rs +noedns | grep status:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13954

$ dig @195.178.56.17 +norec ns1.apr.gov.rs | grep status:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 44465

It is obvious their server cannot cope with cookies, which should be 
fixed on their side. It would be nice to send them kind mail requesting 
fix of their server.


server 195.178.56.17 { send-cookie no; };
server 91.150.72.154 { send-cookie no; };

Should help until they do, but it is just a workaround. The are 
violating RFC 6891, paragraph 6.1.2 [1]:


 Any OPTION-CODE values not understood by a responder or requestor
   MUST be ignored.

Cheers,
Petr

[1] https://www.rfc-editor.org/rfc/rfc6891#section-6.1.2

On 16. 05. 23 16:52, Alex wrote:


Hi,
I have a bind-9.18.7 system on fedora37 and having some strange errors 
with some queries.


$ host info.apr.gov.rs 
Host info.apr.gov.rs  not found: 2(SERVFAIL)

in my bind logs I have the following:
16-May-2023 10:37:49.800 resolver: DNS format error from 
195.178.56.17#53 resolving ns1.apr.gov.rs/ 
 for : server sent FORMERR
16-May-2023 10:37:49.800 lame-servers: received FORMERR resolving 
'ns1.apr.gov.rs//IN ': 195.178.56.17#53
16-May-2023 10:37:49.800 lame-servers: timed out resolving 
'info.apr.gov.rs/A/IN ': 212.62.49.194#53
16-May-2023 10:37:49.800 query-errors: client @0x7f9d546d5168 
127.0.0.1#59712 (info.apr.gov.rs ): query 
failed (failure) for info.apr.gov.rs/IN/A 
 at ../../../lib/ns/query.c:7717


In the limited search results I've found for this, I believe it has 
something to do with dnssec or EDNS, but I really don't know how to 
troubleshoot this. Is this a known problem?


It also appears to be happening with even hosts like ticketmaster?
16-May-2023 10:21:09.348 lame-servers: FORMERR resolving 
'engage.ticketmaster.com/NS/IN 
': 205.251.194.123#53

This resolves fine to me now, does not need disabling cookies or ends.


The host resolves fine on my bind-9.16.38 system using the exact same 
configuration, as well as most or all public resolvers.



--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-- 
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: Problem with subdomain delegation - NS RR ignored?

2023-05-23 Thread Petr Menšík 
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 domain, which is reserved for local use of networks. If you 
want to keep .hub, you will have to set exception to not validate this 
domain on every  validating resolver in your network.


# to allow this domain forever, add to named.conf options{}:
validate-except { "hub" };

Cheers,
Petr

On 10. 05. 23 6:07, bindu...@thegeezer.net wrote:

Howdy

I'm struggling with subdomain creation, for some reason the delegation 
glue records are being ignored - and i was wondering if someone could 
help me identify what I've done wrong please.  I know i need to setup 
another server for the subdomain, but I've been trying to get this 
going at work and getting the same issue, so thought to try on my test 
bed.  Can't even get the NS record returned for the subdomain


Given the domain ".hub"  I can verify the domain level NS
# host -t NS hub localhost
> hub name server localhost.

I can create an A record  for "salmon.hub."  and this resolves as 
expected:

# host -t a salmon.hub localhost
> salmon.hub has address 8.8.8.8

I want to delegate to a different domain server the subdomain 
"fish.hub" and have created glue records as below in the config 
snippet, but get NXDOMAIN for both the A record and the NS record

# host -t a ns1.fish.hub localhost
> Host ns1.fish.hub not found: 3(NXDOMAIN)

# host -t NS fish.hub localhost
> Host fish.hub not found: 3(NXDOMAIN)

Any suggestions gratefully received.  Pertinent parts of named.conf 
and zone file are shown below, if you need more info please don't 
hesitate to ask


thanks in advance!

TG

/etc/bind/named.conf
acl "trusted" {
    10.0.0.0/8;
    192.168.0.0/16;
    127.0.0.0/8;
    ::1/128;
};
allow-recursion {
    trusted;
   };
forwarders {
    208.67.220.220;
    208.67.222.222;
    };
zone "hub" IN {
   type master;
   file "pri/hub.zone";
   notify no;
    };

/etc/bind/pri/hub.zone
$TTL 1W
@   IN  SOA hub. root.hub.  (
  2008122601 ; Serial
  28800  ; Refresh
  14400  ; Retry
  604800 ; Expire - 1 week
  86400 )    ; Minimum
@   IN  NS  localhost.
@   IN  A   127.0.0.1

@   IN      ::1

salmon.hub. IN  A   8.8.8.8
fish.hub.   IN  NS  ns1.fish.hub.
ns1.fish.hub.   IN  A   4.4.4.4




--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

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

2023-05-23 Thread 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?

2023-05-23 Thread 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?

2023-05-23 Thread 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?

2023-05-23 Thread 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?

2023-05-23 Thread 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?

2023-05-23 Thread 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?

2023-05-23 Thread 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?

2023-05-23 Thread 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?

2023-05-23 Thread 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

Can update-policy accept IP addresses ?

2023-05-23 Thread Patrick Rynhart 
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 update-policy
statement (because we want to make use of keys), but as a transition
step we would like our existing whitelisted IPs to be included.  We
have tried the following:

zone "redacted.ac.nz" {
   type master;
   update-policy {
 grant ::1 zonesub ANY;
 grant 127.0.0.1 zonesub ANY;
 grant 131.123.103.2 zonesub ANY;
 grant 131.123.88.3 zonesub ANY;
 ...
   }
}

But all operations from the whitelisted IPs result in the following:

update 'assey.ac.nz/IN' denied

If we roll back to the "allow-update" statement block, everything
starts working again.

Could someone please advise whether update-policy allows IPs (there
are some sources on the net that suggest it should be able to accept
IPs and/or FQDN addresses - for example
http://pig.made-it.com/ddns.html) ?

If the statement does allow it, how can we go about troubleshooting ?
We have already tried starting named in the foreground with -d 10, but
don't get anything useful (just update 'assey.ac.nz/IN' denied)

With Thanks in Advance

Patrick
-- 
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: Can update-policy accept IP addresses ?

2023-05-23 Thread Mark Andrews 


> 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;
>   131.123.88.3;
>   ...
> }
> 
> We are wanting to transition to the more modern update-policy
> statement (because we want to make use of keys), but as a transition
> step we would like our existing whitelisted IPs to be included.  We
> have tried the following:
> 
> zone "redacted.ac.nz" {
>   type master;
>   update-policy {
> grant ::1 zonesub ANY;
> grant 127.0.0.1 zonesub ANY;
> grant 131.123.103.2 zonesub ANY;
> grant 131.123.88.3 zonesub ANY;
> ...
>   }
> }
> 
> But all operations from the whitelisted IPs result in the following:
> 
> update 'assey.ac.nz/IN' denied
> 
> If we roll back to the "allow-update" statement block, everything
> starts working again.
> 
> Could someone please advise whether update-policy allows IPs (there
> are some sources on the net that suggest it should be able to accept
> IPs and/or FQDN addresses - for example
> http://pig.made-it.com/ddns.html) ?

No.  They are not accepted.  tcp-self and 6to4-self are the closest to
using IP addresses and allow for updating of only individual reverse names
with requests sent over TCP.  They are intend to allow hosts to add PTR
records for themselves without having to establish a prior trust relationship.

Just add keys to the allow-update acl as you transition services over then
once everything is working using TSIG or SIG(0) move to update-policy.  Unless
you need the finer grain controls allow-update is equally as secure as
update-policy.

allow-update {
key key1;
key key2;
127.0.0.2;
…
};

> If the statement does allow it, how can we go about troubleshooting ?
> We have already tried starting named in the foreground with -d 10, but
> don't get anything useful (just update 'assey.ac.nz/IN' denied)
> 
> With Thanks in Advance
> 
> Patrick
> -- 
> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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