.
Original message From: Ondřej Surý Date:
31/07/23 8:10 PM (GMT+12:00) To: matt...@peregrineit.net Cc:
bind-users@lists.isc.org Subject: Re: Zone Transfers Being Refused Well, for
starters your primaries list 192.168.2.10, but your logs show connection from
192.168.1.1…--Ondřej Surý — ISC
Yeap, that's what my issue is :-)
On 31/07/2023 18:09, Ondřej Surý wrote:
Well, for starters your primaries list 192.168.2.10, but your logs show
connection from 192.168.1.1…
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated
Well, for starters your primaries list 192.168.2.10, but your logs show
connection from 192.168.1.1…
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 31. 7. 2023, at 9:51, dulux
Hi Ondřej,
Sorry, force of habit (re: "example.com").
External Secondary DNS Server (ns1.mjb-co.com):
~~~
acl "bogusnets" {
!"internal_hosts";
0.0.0.0/8;
10.0.0.0/8;
172.16.0.0/12;
192.0.2.0/24;
192.168.0.0/16;
224.0.0.0/3;
};
acl "internal_hosts" {
192.168.1.0/
Hi,
it’s hard to help you if you don’t provide your configuration (named-checkconf
-px) and use example.com instead of real domain names. Are even the IP
addresses real?
Ondřej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated
Edit the primary zone, just put a TXT record in it, saying anything,
gibberish even, save and reload the zone
let us know so we can check it for currency on both your NS1 and NS2
If you followed Tony's advice there is no reason it is not in sync and I
don't see an issue.
On 18/10/2019 05:48
>
> If the zone file on the primary can be edited by `named` (dynamic
> updates, signing, etc) then you need to `rndc freeze`, edit, `rndc thaw`
> instead.
I did all that, even restarted the systemd service on the primary after
noticing the the issue.
Then, on *both* servers:
*named-checkzone -j
jean-christophe manciot wrote:
> However, if I increment the serial number (SN) on the primary from
> 2019101614 to 2019101709 and order a retransfer on the secondary with "rndc
> retransfer sdxlive.com", I get in the logs:
> *on the primary*:
>
> (serial 2019101614)
Did you `rndc reload sdxlive
Also, if I send the command "rndc notify sdxlive.com" on the primary, I get
in the logs:
*on the primary*:
17-Oct-2019 11:08:46.047 general: info: received control channel command
'notify sdxlive.com'
17-Oct-2019 11:08:46.053 notify: info: zone sdxlive.com/IN (signed):
sending notifies (serial 201
However, if I increment the serial number (SN) on the primary from
2019101614 to 2019101709 and order a retransfer on the secondary with "rndc
retransfer sdxlive.com", I get in the logs:
*on the primary*:
*17-Oct-2019 10:56:09.038 xfer-out: info: client @0x
a.b.c.d#49155 (sdxlive.com <
>
> wow something has chewed up your message and vomited it out again but some
> of the remnants are vaguely legible...
>
I don't know what happened, but some IP addresses & other fields have been
intentionally obfuscated. The original first message have been attached to
this answer.
I'm not sure
jean-christophe manciot wrote:
wow something has chewed up your message and vomited it out again but some
of the remnants are vaguely legible...
> - the debug log shows that the zone transfer has *successfully* taken place
> on the primary towards the secondary server:
>
> - actually, the zone t
In message <4b8586a0.2030...@isc.org>, Alan Clegg writes:
> Dan Letkeman wrote:
>
> > I think I have a configuration issue somewhere. It looks like from
> > the logs that my master server is notifying the slaves correctly, but
> > then the other slaves are also notifying the slaves as well.
> >=
Dan Letkeman wrote:
> I think I have a configuration issue somewhere. It looks like from
> the logs that my master server is notifying the slaves correctly, but
> then the other slaves are also notifying the slaves as well.
>
> 172.16.0.100 is the master
> 172.16.0.101 is 1st slave
> 172.16.0.10
Michael Di Martino wrote:
>
> I have a Master BIND9 server with 2 active (up) interfaces eth0 and eth1.
>
> I need my zone update notifications and zone transfer to use eth1
> instead of eth0 which is currently using.
>
> How can I change this behavior while still having the server listen on
> e
In article ,
Michael Di Martino wrote:
> I have a Master BIND9 server with 2 active (up) interfaces eth0 and eth1.
> I need my zone update notifications and zone transfer to use eth1 instead o=
> f eth0 which is currently using.
> How can I change this behavior while still having the server list
> I have a Master BIND9 server with 2 active (up) interfaces eth0 and eth1.
> I need my zone update notifications and zone transfer to use eth1
> instead of eth0 which is currently using.
> How can I change this behavior while still having the server listen on
> eth0?
Have a look at the listen-o
Checkout the "transfer-source" directive for the transfers, and the
"notify-source" directive. I've not used the latter, so I'm not exactly
sure if it fits, but I expect that it will.
DNS and BIND @Google Books is a useful reference:
http://books.google.com.hk/books?id=zkZN52WhG8sC&printsec=
On Thu, Apr 30, 2009 at 10:20 AM, Kevin Darcy wrote:
>
> Use TSIG keys to differentiate the views.
>
I'll give that a try. Thank you.
--
Stephen Carville
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind
Stephen Carville wrote:
I am trying to create three DNS slave servers with views for internal
an external IP's. Each has an address in the DMZ and the firewall
(actually a CSS) routes requests from the external IP's to the
internal addresses. The correspondence is one-to-one:
external.1 <--> d
20 matches
Mail list logo
