Re: also-notify and nsupdate doesnt work

hi, Am 02.05.2016 um 23:19 schrieb Darcy Kevin (FCA): Right. also-notify (on a master) versus allow-notify (on a slave). Different use cases. the problem would not in the notify config. the notify and transfer works fine with the zone config. until i add the dynamic update option on the

Re: also-notify and nsupdate doesnt work

hi, The use case for also-notify is when you have slave servers that aren't in the NS records of the zone. Otherwise, those slaves won't update until the Refresh timer goes off. thats exactrly how i want to use it... jonny ___ Please visit

Re: also-notify and nsupdate doesnt work

hi, > Apologies if this has already been asked, but are you sending these NOTIFYs from a master which is _not_ in the "masters" clause of the nameserver which is receiving it? That's precisely the use case for "allow-notify"... the notifies are sent by the only master, which is noted in the

Re: BIND assertion failure - 9.10.4

On Tue, May 03, 2016 at 10:41:10AM +1000, James Brown wrote: > Upgraded to 9.10.4 a few days ago, and this morning it crashed: Thanks. The best place to send bug reports is bind9-b...@isc.org, not bind-users. > Running Mac OS X 10.11.4. > > Have never had a problem with any previous version of

BIND assertion failure - 9.10.4

Upgraded to 9.10.4 a few days ago, and this morning it crashed: 03-May-2016 04:01:54.575 zone rpz.spamhaus.org/IN/internal: transferred serial 1462212030 03-May-2016 04:01:54.575 transfer of 'rpz.spamhaus.org/IN/internal' from 199.168.90.51#53: Transfer status: success 03-May-2016 04:01:54.575

Re: Whether Bind (bind-9.10.3-P3) support Edns ?

On Mon, May 02, 2016 at 09:13:07PM +0800, johnzeng wrote: > Whether Bind (bind-9.10.3-P3) support Edns ? or Maybe we need patch > 0001-EDNS0-client-subnet-support.patch for BIND. No. There's support for sending the option in "dig", but not in "named". There is limited support for ECS in the 9.11

Re: Nsupdate usage scenario

On 2 May 2016 at 16:38, wrote: > > > On Mon, May 2, 2016, at 12:15 PM, Jeremy C. Reed wrote: > > What about using a specific zone file just for the purpose of the single > > A record you want to maintain using dynamic updates? > > Well, this is a timely idea for another

RE: also-notify and nsupdate doesnt work

Right. also-notify (on a master) versus allow-notify (on a slave). Different use cases. - Kevin -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry

Re: also-notify and nsupdate doesnt work

In article , "Darcy Kevin (FCA)" wrote: > Apologies if this has already been asked, but are you sending these NOTIFYs > from a master which is _not_ in the "masters" clause of the nameserver which > is receiving

RE: also-notify and nsupdate doesnt work

Apologies if this has already been asked, but are you sending these NOTIFYs from a master which is _not_ in the "masters" clause of the nameserver which is receiving it? That's precisely the use case for "allow-notify"... -

Re: Nsupdate usage scenario

On Mon, May 2, 2016, at 12:15 PM, Jeremy C. Reed wrote: > What about using a specific zone file just for the purpose of the single > A record you want to maintain using dynamic updates? Well, this is a timely idea for another issue I've been working on ... Could you expand on this a bit?

Re: Nsupdate usage scenario

Also for the generated master file, have a look at "masterfile-style full;" option. Have a look at the named-compilezone -j with -s full or -s relative so you can compare outputs. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to

9.10.4 build/test - one failure

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Building on centos/rhel 6, the build works, but "make test" has one failure: S:notify:Mon May 2 11:26:31 PDT 2016 T:notify:1:A A:System test notify I:checking initial status (1) I:reloading with example2 using HUP and waiting up to 45 seconds

Re: Nsupdate usage scenario

What about using a specific zone file just for the purpose of the single A record you want to maintain using dynamic updates? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list

Re: Cannot get BIND logs to write to the correct file.

On Mon, 2 May 2016, Sean Son wrote: > I am trying to get BIND to write its logs to two files: > > /var/log/named/named.log > > and > > /var/log/named/dnsreqs.log > > > No matter what I do , the logs are still being written to > /var/named/data/named.run > > Here is the part of my named.conf

Nsupdate usage scenario

I was trying to use nsupdate to automatically update a single A record in our domain to its latest dynamic, but public, IP address. Although it did indeed rewrite the zone file to reflect the new IP address, it also rearranged all the entries in the file into seemingly random order (maybe sorted

Cannot get BIND logs to write to the correct file.

Hello all I am trying to get BIND to write its logs to two files: /var/log/named/named.log and /var/log/named/dnsreqs.log No matter what I do , the logs are still being written to /var/named/data/named.run Here is the part of my named.conf which deals with logging: logging {

Re: also-notify and nsupdate doesnt work

Aye... I'm sitting here looking for zone transfer use of TSIG... It's too early in the morning. *sigh* On 5/2/16, 10:30 AM, "jo...@hasig.de" wrote: >hi, > > > There's nothing in this part of the configuration that links key usage >to > > the zone. > >sure. the * is. >and the

Re: also-notify and nsupdate doesnt work

hi, > There's nothing in this part of the configuration that links key usage to > the zone. sure. the * is. and the update works great. the serial counts up, the update is taken, the slave is motified and updated. the only thing is, that the "also-notify" servers get no notify. (if i do an

Re: also-notify and nsupdate doesnt work

On 5/2/16, 10:09 AM, "bind-users-boun...@lists.isc.org on behalf of jo...@hasig.de" wrote: > >1. >zone "abc.net" { > notify yes; > type master; > file "abc.net"; > allow-transfer { any; }; >

Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?

On Mon, May 2, 2016, at 07:17 AM, Matthew Pounsett wrote: > The general procedure is > 1) use 'rndc freeze ' to stop dynamic updates to the zone > 2) edit the file > 3) use 'rndc thaw ' to re-enable dynamic updates > > If the zone is not set up to use dynamic updates, then: > 1) edit the zone

Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?

> > > > >On Mon, May 2, 2016, at 07:17 AM, Matthew Pounsett wrote: >> The general procedure is >> 1) use 'rndc freeze ' to stop dynamic updates to the zone >> 2) edit the file >> 3) use 'rndc thaw ' to re-enable dynamic updates >> >> If the zone is not set up to use dynamic updates, then: >> 1)

Re: also-notify and nsupdate doesnt work

hi, > Can you share your whole config? It's possible there are options outside > the zone stanzas that could affect the behaviour of notifies. no, the whole config covers about 600 zones with different configs. and why should the notify work with stanza 1 but not with 2? the notify 1 works

Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?

On 5/2/16, 10:17 AM, "Matthew Pounsett" wrote: > > > On 2 May 2016 at 10:05, wrote: >> General question -- >> >> When I want to change a zone file's data manually, say to add an A record, >> what's

Re: also-notify and nsupdate doesnt work

hi, What you're describing sounds wrong. It shouldn't work that way. what do you mean by "wrong" and which "it" should not work? :-) Can you share your configuration so that we can see what's actually happening? sure :-) samples: 1. zone "abc.net" { notify yes; type

Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?

On 2 May 2016 at 10:05, wrote: > General question -- > > When I want to change a zone file's data manually, say to add an A record, > what's the right procedure: > > If the zone is set up for dynamic updates, like the examples you've given, then in order to touch the

Re: also-notify and nsupdate doesnt work

On 2 May 2016 at 10:09, wrote: > hi, > > What you're describing sounds wrong. It shouldn't work that way. >> > what do you mean by "wrong" and which "it" should not work? :-) > > What I mean is, given a typical configuration, the brokenness you're observing shouldn't be broken.

Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?

I'm pretty sure I got this sorted -- as you said, perms. With default ownership of root:named, both the zone & jnl files need to be group writeable inside the chroot. That's fixed now, and I'm getting jnl data written to zone files. (1) Thanks! (2) No idea why I see no logging of these perm