Re: rndc
On 8/1/14, 1:58 AM, Reindl Harald wrote: > i did not pretend it's a perfect solution in every environment > but it is suiteable for many and so a valid opportunity Sorry, yours is a bad solution for most and doing rndc correctly is a much better solution for nearly everyone. There, I said it. AlanC signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
SERVFAIL when increasing recursive-clients? (Was: bind-users Digest, Vol 1902, Issue 2
On Fri, Aug 01, 2014 at 09:56:53AM +0700, Xuan Hung wrote a message of 298 lines which said: > I think this problem of me, need have version new of Bind. 9.9.5 is quite recent. Actually, it is the latest in 9.9 branch. What makes you think upgrading would change anything? > I think resolver of Bind.9.9.5 have problem when response for > customer. Please, less "I think" and more actual copy-and-paste of config files, extracts of logs, output of dig, etc. > If recusive client of My DNS increase to 4000 then resolver response > servfail. Did you check the log (checking the logs is MANDATORY when managing a daemon) to see if BIND was properly reloaded after you increased recursive-clients? Also, what is the amount of memory? The more you increase recursive-clients, the more memory you need. Check the memory use by your server. Otherwise, no idea but could you post the actual query and response, as seen by dig? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc (and now nsupdate too)
Reindl Harald wrote: > Am 31.07.2014 um 21:08 schrieb /dev/rob0: > > > > The proper tool to manage zone data is nsupdate(8). Likewise well > > suited for automation. > > zone file *editing*? > > sorry, no, i developed 2008 a interface to create all zone files based > on database records, write the complete zone content in a main table > with a textfiled and a second textfiled where translation for NAT/WAN > zones happens and so there is and never was a reason to *edit* a > zone file > > it is created from scratch when changes in a zone happen and cronjobs > only pull zones with the "updated-field" set to 1 In our setup, changes made in the database are turned into an nsupdate script, so we don't need to bounce the name server and we can use BIND's automatic signing. Tony. -- f.anthony.n.finchhttp://dotat.at/ Sole: Southwest 3 or 4 veering northwest 5 or 6. Slight or moderate, becoming moderate or rough in west. Rain or showers. Moderate or good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Logs problem with Bind 9.9.4
Hi everybody
we recently installed Bind 9.9.4 on CentOS 7, and it's working properly.
the only problem that we have is the (logging), we can't stop logging.
First thing I tried is to disable IPv6 logs, by editing
"/etc/sysconfig/named" and make (OPTIONS="-4"),
but that doesn't work .
After that, I tried to use logging { } clause, and that doesn't work too.
Finally, I tried to stop all Bind logging, many attempts without success.
so, is there any solution to stop or control Bind logging ???
any help will be appreciated
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Logs problem with Bind 9.9.4
Am 01.08.2014 um 11:56 schrieb ahmed salim:
> we recently installed Bind 9.9.4 on CentOS 7, and it's working properly.
> the only problem that we have is the (logging), we can't stop logging.
> First thing I tried is to disable IPv6 logs, by editing
> "/etc/sysconfig/named" and make (OPTIONS="-4"),
> but that doesn't work .
> After that, I tried to use logging { } clause, and that doesn't work too.
> Finally, I tried to stop all Bind logging, many attempts without success.
>
> so, is there any solution to stop or control Bind logging ???
> any help will be appreciated
which logging (syslog or bind-logfiles)
which type of logs - there are a lot!
why disable it completly?
that's unwise in case of troubles
limit them in size and you have recent informations
querylog no;
logging
{
channel default_log
{
file "data/named.log" versions 0 size 1m;
severity dynamic;
print-time yes;
print-category yes;
};
channel transfer_log
{
file "data/transfer.log" versions 0 size 1m;
severity dynamic;
print-time yes;
print-category yes;
};
channel rate_limit_log
{
file "data/rate_limit.log" versions 0 size 1m;
severity dynamic;
print-time yes;
print-category yes;
};
channel lame_servers_log
{
file "data/lame_servers.log" versions 0 size 1m;
severity dynamic;
print-time yes;
print-category yes;
};
channel query_errors_log
{
file "data/query_errors.log" versions 0 size 1m;
severity dynamic;
print-time yes;
print-category yes;
};
category default {default_log;};
category resolver {default_log;};
category security {default_log;};
category xfer-in {transfer_log;};
category xfer-out {transfer_log;};
category config {default_log;};
category queries {default_log;};
category notify {default_log;};
category database {default_log;};
category rate-limit {rate_limit_log;};
category lame-servers {lame_servers_log;};
category query-errors {query_errors_log;};
};
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc (and now nsupdate too)
-Original Message- From: Tony Finch Date: Friday, August 1, 2014 at 5:31 AM To: Reindl Harald Cc: "bind-users@lists.isc.org" Subject: Re: rndc (and now nsupdate too) >Reindl Harald wrote: >> Am 31.07.2014 um 21:08 schrieb /dev/rob0: >> > >> > The proper tool to manage zone data is nsupdate(8). Likewise well >> > suited for automation. >> >> zone file *editing*? >> >> sorry, no, i developed 2008 a interface to create all zone files based >> on database records, write the complete zone content in a main table >> with a textfiled and a second textfiled where translation for NAT/WAN >> zones happens and so there is and never was a reason to *edit* a >> zone file >> >> it is created from scratch when changes in a zone happen and cronjobs >> only pull zones with the "updated-field" set to 1 > >In our setup, changes made in the database are turned into an nsupdate >script, so we don't need to bounce the name server and we can use >BIND's automatic signing. no argument on nsupdate, but even if you copy files around...you don't need to bounce the nameserver, unless rndc reload is what you mean (when i hear bounce i think stop/start). ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc (and now nsupdate too)
Am 01.08.2014 um 15:14 schrieb Mike Hoskins (michoski): > From: Tony Finch > Date: Friday, August 1, 2014 at 5:31 AM > To: Reindl Harald > Cc: "bind-users@lists.isc.org" > Subject: Re: rndc (and now nsupdate too) > >> Reindl Harald wrote: >>> Am 31.07.2014 um 21:08 schrieb /dev/rob0: The proper tool to manage zone data is nsupdate(8). Likewise well suited for automation. >>> >>> zone file *editing*? >>> >>> sorry, no, i developed 2008 a interface to create all zone files based >>> on database records, write the complete zone content in a main table >>> with a textfiled and a second textfiled where translation for NAT/WAN >>> zones happens and so there is and never was a reason to *edit* a >>> zone file >>> >>> it is created from scratch when changes in a zone happen and cronjobs >>> only pull zones with the "updated-field" set to 1 >> >> In our setup, changes made in the database are turned into an nsupdate >> script, so we don't need to bounce the name server and we can use >> BIND's automatic signing. > > no argument on nsupdate, but even if you copy files around...you don't > need to bounce the nameserver, unless rndc reload is what you mean (when i > hear bounce i think stop/start) since when is -SIGHUP stop/start? http://en.wikipedia.org/wiki/Unix_signal SIGHUP Many daemons will reload their configuration files and reopen their logfiles instead of exiting when receiving this signal.[4] nohup is a command to make a command ignore the signal. [root@srv-rhsoft:~]$ killall -SIGHUP named [root@srv-rhsoft:~]$ cat named.log 01-Aug-2014 15:21:01.598 general: received SIGHUP signal to reload zones 01-Aug-2014 15:21:01.598 general: loading configuration from '/etc/named.conf' 01-Aug-2014 15:21:01.599 general: using default UDP/IPv4 port range: [1024, 65535] 01-Aug-2014 15:21:01.599 general: using default UDP/IPv6 port range: [1024, 65535] 01-Aug-2014 15:21:01.599 network: no IPv6 interfaces found 01-Aug-2014 15:21:01.613 general: sizing zone task pool based on 9 zones signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc (and now nsupdate too)
-Original Message- From: Reindl Harald Organization: the lounge interactive design Date: Friday, August 1, 2014 at 9:23 AM To: "bind-users@lists.isc.org" Subject: Re: rndc (and now nsupdate too) > >Am 01.08.2014 um 15:14 schrieb Mike Hoskins (michoski): >> From: Tony Finch >> Date: Friday, August 1, 2014 at 5:31 AM >> To: Reindl Harald >> Cc: "bind-users@lists.isc.org" >> Subject: Re: rndc (and now nsupdate too) >> >>> Reindl Harald wrote: Am 31.07.2014 um 21:08 schrieb /dev/rob0: > > The proper tool to manage zone data is nsupdate(8). Likewise well > suited for automation. zone file *editing*? sorry, no, i developed 2008 a interface to create all zone files based on database records, write the complete zone content in a main table with a textfiled and a second textfiled where translation for NAT/WAN zones happens and so there is and never was a reason to *edit* a zone file it is created from scratch when changes in a zone happen and cronjobs only pull zones with the "updated-field" set to 1 >>> >>> In our setup, changes made in the database are turned into an nsupdate >>> script, so we don't need to bounce the name server and we can use >>> BIND's automatic signing. >> >> no argument on nsupdate, but even if you copy files around...you don't >> need to bounce the nameserver, unless rndc reload is what you mean >>(when i >> hear bounce i think stop/start) > >since when is -SIGHUP stop/start? i suspect a language barrier, since if you read what i typed i never said that. in fact, i'm not sure you read what Tony typed either. "bouncing a daemon" often means stop/start. whether you rndc reload or HUP, such a restart is not needed on zone changes. my entire point is that a costly full restart is not needed, even without nsupdate. i'm sure Tony knows this, and simply wanted to clarify for posterity in the thread archive. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc (and now nsupdate too)
Am 01.08.2014 um 15:44 schrieb Mike Hoskins (michoski): >>> no argument on nsupdate, but even if you copy files around...you don't >>> need to bounce the nameserver, unless rndc reload is what you mean >>> (when i >>> hear bounce i think stop/start) >> >> since when is -SIGHUP stop/start? > > i suspect a language barrier, since if you read what i typed i never said > that. in fact, i'm not sure you read what Tony typed either. > > "bouncing a daemon" often means stop/start. whether you rndc reload or > HUP, such a restart is not needed on zone changes. my entire point is > that a costly full restart is not needed, even without nsupdate. > > i'm sure Tony knows this, and simply wanted to clarify for posterity in > the thread archive. no it is *not* a language barrier you are simply missing the context the whole discussion about rndc or not rndc follow up therads and side-threads startet after that reply below from me yesterday and whoever brought "bounce" in the game did also not understand the context of the discussion all the threads about "rndc" refer to that below! Weitergeleitete Nachricht Betreff: Re: rndc (and now nsupdate too) Datum: Thu, 31 Jul 2014 14:08:48 -0500 Von: /dev/rob0 Antwort an: bind-users@lists.isc.org Organisation: RTFM An: bind-users@lists.isc.org On Thu, Jul 31, 2014 at 05:56:08PM +0200, Reindl Harald wrote: > Am 31.07.2014 um 17:41 schrieb /dev/rob0: > > On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote: > >> i am doing reloads of named with "killall -HUP named" just > >> because i disabled rndc completly for security reasons and > >> configurations are generated with own software only needs > >> named to reload Weitergeleitete Nachricht Betreff: Re: Reload BIND to listen on additional interface? Datum: Thu, 31 Jul 2014 13:32:03 +0200 Von: Reindl Harald An: bind-users@lists.isc.org Am 31.07.2014 um 13:24 schrieb Johannes Kastl: > in the quest to use a master behind a Router with changing IPs, I set > up a VPN and told bind on both sides to listen on the additional VPN-IPs. > > But, sometimes they are not available at bind startup or the VPN loses > connection. So, when the VPN connection is ready again, I can let > OpenVPN run a script. My idea was to use this script to tell bind, > that it can now bind to the interface again. > > Question now is, which (rndc) command does that? Does a ârndc > reconfigâ tell BIND to newly bind to the interfaces? i am doing reloads of named with "killall -HUP named" just because i disabled rndc completly for security reasons and configurations are generated with own software only needs named to reload pretty sure it will also force look for new interfaces or gone ones [root@srv-rhsoft:~]$ tail named.log #31-Jul-2014 13:30:05.016 general: automatic empty zone: D.F.IP6.ARPA 31-Jul-2014 13:30:05.016 general: automatic empty zone: 8.E.F.IP6.ARPA 31-Jul-2014 13:30:05.016 general: automatic empty zone: 9.E.F.IP6.ARPA 31-Jul-2014 13:30:05.016 general: automatic empty zone: A.E.F.IP6.ARPA 31-Jul-2014 13:30:05.016 general: automatic empty zone: B.E.F.IP6.ARPA 31-Jul-2014 13:30:05.016 general: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA 31-Jul-2014 13:30:05.037 general: reloading configuration succeeded 31-Jul-2014 13:30:05.039 general: reloading zones succeeded 31-Jul-2014 13:30:05.057 general: all zones loaded 31-Jul-2014 13:30:05.057 general: running [root@srv-rhsoft:~]$ killall -HUP named [root@srv-rhsoft:~]$ tail named.log 31-Jul-2014 13:30:26.443 general: automatic empty zone: D.F.IP6.ARPA 31-Jul-2014 13:30:26.443 general: automatic empty zone: 8.E.F.IP6.ARPA 31-Jul-2014 13:30:26.443 general: automatic empty zone: 9.E.F.IP6.ARPA 31-Jul-2014 13:30:26.443 general: automatic empty zone: A.E.F.IP6.ARPA 31-Jul-2014 13:30:26.443 general: automatic empty zone: B.E.F.IP6.ARPA 31-Jul-2014 13:30:26.443 general: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA 31-Jul-2014 13:30:26.446 general: reloading configuration succeeded 31-Jul-2014 13:30:26.447 general: reloading zones succeeded 31-Jul-2014 13:30:26.464 general: all zones loaded 31-Jul-2014 13:30:26.464 general: running signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc (and now nsupdate too)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, On 01.08.14 15:58 Reindl Harald wrote: > the whole discussion about rndc or not rndc follow up therads and > side-threads startet after that reply below from me yesterday and > whoever brought "bounce" in the game did also not understand the > context of the discussion Calm down, everyone. Please. I did not intend to start a thread that long and, uhm, intense... My (simplified) conclusion: In most setups, using rndc is the right way, because most people do not know its advantages or the disadvantages of killing the daemon. But there is a german saying "Ausnahmen bestätigen die Regel", which could be translated as 'exceptions prove the rule'. So, those (exceptions) who really do know what they are doing can workaround rndc. Regards, Johannes - -- Multiple exclamation marks are a sure sign of diseased mind. (Terry Pratchett) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlPbpn0ACgkQzi3gQ/xETbK4qACeLHAGdp/yPjidlOHlMHpO+gw9 HjIAoIyYpqXq4MOuNCu6OkpHuvWbsFwL =FrGZ -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND and listening on interfaces
the thread yesterday reminded me on my Fedora bugrpeort
https://bugzilla.redhat.com/show_bug.cgi?id=1073038#c3
https://bugzilla.redhat.com/show_bug.cgi?id=1073038#c8
i don't buy "Note that destination IP address must be
known and set correctly in reply, otherwise clients
will be confused" because how does it survive NAT
if listen-on {0.0.0.0;}; would work a lot of problems
could go away - keep in mind that on modern systemd
systems a service can bind to 0.0.0.0 even before
the network is started
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and listening on interfaces
In article , Reindl Harald wrote: > the thread yesterday reminded me on my Fedora bugrpeort > https://bugzilla.redhat.com/show_bug.cgi?id=1073038#c3 > https://bugzilla.redhat.com/show_bug.cgi?id=1073038#c8 > > i don't buy "Note that destination IP address must be > known and set correctly in reply, otherwise clients > will be confused" because how does it survive NAT What's meant is that the source address of the reply must match the destination address of the request. This is the how TCP behaves automatically, since it involves connections, but all UDP packets are independent. When BIND sends a reply message, the stack doesn't know that it's related to a particular incoming message whose IPs should be flipped. It survives NAT because the router remembers how it translated the incoming packet. When it sees an outgoing packet with the translated IP and port, it undoes the translation. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and listening on interfaces
Am 01.08.2014 um 17:16 schrieb Barry Margolin: > In article , > Reindl Harald wrote: > >> the thread yesterday reminded me on my Fedora bugrpeort >> https://bugzilla.redhat.com/show_bug.cgi?id=1073038#c3 >> https://bugzilla.redhat.com/show_bug.cgi?id=1073038#c8 >> >> i don't buy "Note that destination IP address must be >> known and set correctly in reply, otherwise clients >> will be confused" because how does it survive NAT > > What's meant is that the source address of the reply must match the > destination address of the request. This is the how TCP behaves > automatically, since it involves connections, but all UDP packets are > independent. When BIND sends a reply message, the stack doesn't know > that it's related to a particular incoming message whose IPs should be > flipped. > > It survives NAT because the router remembers how it translated the > incoming packet. When it sees an outgoing packet with the translated IP > and port, it undoes the translation yes and no iptables knows the concept of " -p udp -m conntrack --ctstate NEW" so the stack somehow knows, not the same way as TCP but it knows other UDP services like OpenVPN, dhcpd, avahi or mediathomb just listening on UDP 0.0.0.0:port and just working signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and listening on interfaces
On 01/08/14 15:46, Reindl Harald wrote:
if listen-on {0.0.0.0;}; would work a lot of problems
could go away - keep in mind that on modern systemd
systems a service can bind to 0.0.0.0 even before
the network is started
Most people just use "rndc reconfig". In bind 9.10 the routing socket,
on platforms that support it, will work instantly without being told.
As noted in the bug, the v4 socket API lacks support for setting UDP
source IP on replies. So doing this requires platform-specific hacks.
They don't always work - FreeRADIUS has "udpfromto" code in it, and
people used to report a lot of problems getting it to compile and work
properly.
Binding separate sockets per IP is IMO just as reliable, and is well
tested. If you weren't so opposed to "rndc", you could just call "rndc
reconfig" in whatever network system/dispatch tool you have after IPs -
or wait for bind 9.10.
This is a non-issue IMO.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc (and now nsupdate too)
Mike Hoskins (michoski) wrote: > Tony Finch wrote: > > > >In our setup, changes made in the database are turned into an nsupdate > >script, so we don't need to bounce the name server and we can use > >BIND's automatic signing. > > no argument on nsupdate, but even if you copy files around...you don't > need to bounce the nameserver, unless rndc reload is what you mean (when i > hear bounce i think stop/start). Sorry, I was being imprecise. When I said "bounce" I meant any kind of config change action that makes named do more work than is necessary to change the contents of the zone. Tony. -- f.anthony.n.finchhttp://dotat.at/ FitzRoy: Westerly or southwesterly veering northwesterly, 4 or 5, increasing 6 or 7 for a time in east. Slight or moderate, becoming moderate or rough in east. Rain or thundery showers. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and listening on interfaces
In article , Reindl Harald wrote: > Am 01.08.2014 um 17:16 schrieb Barry Margolin: > > In article , > > Reindl Harald wrote: > > > >> the thread yesterday reminded me on my Fedora bugrpeort > >> https://bugzilla.redhat.com/show_bug.cgi?id=1073038#c3 > >> https://bugzilla.redhat.com/show_bug.cgi?id=1073038#c8 > >> > >> i don't buy "Note that destination IP address must be > >> known and set correctly in reply, otherwise clients > >> will be confused" because how does it survive NAT > > > > What's meant is that the source address of the reply must match the > > destination address of the request. This is the how TCP behaves > > automatically, since it involves connections, but all UDP packets are > > independent. When BIND sends a reply message, the stack doesn't know > > that it's related to a particular incoming message whose IPs should be > > flipped. > > > > It survives NAT because the router remembers how it translated the > > incoming packet. When it sees an outgoing packet with the translated IP > > and port, it undoes the translation > > yes and no > > iptables knows the concept of " -p udp -m conntrack --ctstate NEW" > so the stack somehow knows, not the same way as TCP but it knows > > other UDP services like OpenVPN, dhcpd, avahi or mediathomb just > listening on UDP 0.0.0.0:port and just working Works fine on single-homed hosts, can break on multi-homed hosts. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc (and now nsupdate too)
This recent thread, in which people are describing their scripts and GUI provisioning systems makes me think we should recruit a few of you who think you have a sweet provisioning system, to do a WebEX and describe it for everyone else who is looking for a better system. At the RIPE meeting in Poland I saw a GUI front end for updating resource records that a French university network team had created and a very impressive system using Ansible to rapidly transform a NSD auth server into a BIND auth server and back again (including translating zone files). There are a number of tools and cookbooks out there, if the tool you use is not one you developed, but it is public domain, open source or otherwise freely available and you think it is really helpful, it would be useful for others to hear about that too. If you have a reasonably full-featured, effective, free provisioning system that could be shared and successfully used in another environment, and you are willing to do a presentation on it (perhaps share an hour slot with one other person), please email me unicast. If we get any volunteers, we’ll schedule something and advertise it back here on bind-users. Vicky Product Manager, isc.org On Aug 1, 2014, at 9:09 AM, Tony Finch wrote: > Mike Hoskins (michoski) wrote: >> Tony Finch wrote: >>> >>> In our setup, changes made in the database are turned into an nsupdate >>> script, so we don't need to bounce the name server and we can use >>> BIND's automatic signing. >> >> no argument on nsupdate, but even if you copy files around...you don't >> need to bounce the nameserver, unless rndc reload is what you mean (when i >> hear bounce i think stop/start). > > Sorry, I was being imprecise. When I said "bounce" I meant any kind of > config change action that makes named do more work than is necessary to > change the contents of the zone. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > FitzRoy: Westerly or southwesterly veering northwesterly, 4 or 5, increasing 6 > or 7 for a time in east. Slight or moderate, becoming moderate or rough in > east. Rain or thundery showers. Good, occasionally poor. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reload BIND to listen on additional interface?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31.07.14 13:55 Mark Andrews wrote: > > 9.10 also has "rndc scan" for platforms without a routing socket or > if you want to do it manually. As I have not found a working RPM of bind 9.10 for openSUSE this far, I have to ask: How to handle this using 9.9.5? Just try and see what happens? Regards, Johannes - -- `Three Dementor attacks in a week, and all Romilda Vane does is ask me if it's true you've got a Hippogriff tattooed across your chest´ [...] `I told her it's a hungarian Horntail,´ said Ginny, turning a page of her newspaper idly.`Much more Macho´ (Ginny Weasley in Harry Potter 6) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlPbxfwACgkQzi3gQ/xETbJr7ACfUV7pu0PQPuzoTQtPFbLnTASS /bkAn1SUkmElmO1dqpSDGHIUI1/n62F0 =lmp5 -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and listening on interfaces
Am 01.08.2014 um 18:06 schrieb Phil Mayers:
> Binding separate sockets per IP is IMO just as reliable, and is well tested.
> If you
> weren't so opposed to "rndc", you could just call "rndc reconfig" in whatever
> network system/dispatch tool you have after IPs - or wait for bind 9.10.
it's not a matter of "rndc" or not
it's a matter of parallelism boot and start services before network at all
> This is a non-issue IMO
depends on the environment
Am 01.08.2014 um 18:13 schrieb Sam Wilson:
> Works fine on single-homed hosts, can break on multi-homed hosts
yes, and that's why listen-on {0.0.0.0;}; on a single-homed host
could do that, named start at any point in time, not need to
care about changing interfaces and without behave as now
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and listening on interfaces
In message <53dba84d.8030...@thelounge.net>, Reindl Harald writes:
>
> the thread yesterday reminded me on my Fedora bugrpeort
> https://bugzilla.redhat.com/show_bug.cgi?id=3D1073038#c3
> https://bugzilla.redhat.com/show_bug.cgi?id=3D1073038#c8
>
> i don't buy "Note that destination IP address must be
> known and set correctly in reply, otherwise clients
> will be confused" because how does it survive NAT
>
> if listen-on {0.0.0.0;}; would work a lot of problems
> could go away - keep in mind that on modern systemd
> systems a service can bind to 0.0.0.0 even before
> the network is started
Named does not bind to 0.0.0.0 because the replies may not come
from the correct address. If you have multiple addresses on a
interface or multiple interfaces then there is no guarentee that
the address the stack uses to source a UDP reply packet will match
the address the query arrived on.
This is not a issue for TCP where the local address in stored in
the PCB.
For IPv6 we have in6_pktinfo and if the OS supports in6_pktinfo we
use it and bind to :: if the listen-on-v6 acl is "any;". If the
OS does not support in6_pktinfo then we bind to every interface.
If named is only listening on a subset of interface we bind to each
interface so that the one can run multiple instances and also so
that the correct ICMP messages are emitted.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
php-library added -> Re: rndc (and now nsupdate too)
> This recent thread, in which people are describing their scripts and > GUI provisioning systems makes me think we should recruit a few of > you who think you have a sweet provisioning system at least i add the library i developed to maintain zone-files which needs translation of the comments, to be cleaned from some hacks depending on our domain and a replaced database layer which i can't publish watch for '$this->db' and $GLOBALS['cl_api']->log() using a global log-api from the CMS-system wrapped around it feel free to use the code for whatever you want, adopt it, laugh about it, delete it :-) sorry no way to make the GUI parts public they are hard wired with internal CMS software and libs i fear the "it seems that no one with an adequate understanding of BIND has written and released a good management frontend" comes because they which did wrapped it around existing infrastructure and can't make it public nor is it written in a generic way then there comes the security point of view - keep the code tiny and only support what you really need avoids a lot of complexity leading in questionable security decisions but makes it also less useable for other environments at least i post the table-structure below and maybe give some ideas helping others, 6 years production and survive a global IP change on the network showed the ideas working great surely, if you have thounds of really large zones it may not scale that perfect, not the case here, up to 1000 zones a no-brainer my development as example started because there is no software out there which supports the grade of automatism i wanted while they make no sense in a different environment and it was developed after FTP/Apache/Asterisk backends all using a inhouse framework startet 2003 and extended with dns functionality 2008 one of the primary design decisions was to also generate PTR-records and feed pseudo-static DHCP ranges by add the MAC to a name/ip-pair and generate the dhcpd.conf with that which gone that far to discover the network with arp commands and add the MAC to the existing A-records made by hand, new machine: change that MAC field and there things start to get "hackish", "thelounge.net" itself has the complete structure seperated and needs to be maintained twice and only the internal cronjobs care about MAC/DHCP on the other hand the basic tool to generate complete zone files out of a single table and write them in the "zone-table" was AFIR written in one night (followed by fine-tuning and extended with special record-types like TXT/SPF and zone delegation on-demand) later automatic generation of SPF records where added if there is a MX pointing to a machine inside our own domain or create or "v=spf1 -all" if there is no MX, special handling of subdomains with MX records if they point inside our domain and skip them if point outside the next thing which is "hackish" -> maintain email-autodiscovery with means DNS records as well as a apache-vhost, if you want to have all that features most working fully automated and just send cron-mails in the style of "i did this and that, below the diff of the config" you need to design much more carefully and invest a lot of more work by carry repsonsiblity in case of changes after you publish it and 3rd parties started to rely on not break their setup *that* responsibility makes it so hard to publish backends because you lose the freedom of "we re-design our infrastructure for whatever reason and add as much hacks as needed temporary in the code for automatic transitions and cleanup later frankly you can test that stuff by make a DB dump, stop the cronjobs while play around with "live-data", re-play whatever you plan and finally -> restore the sql-dump, fire the changes again and start cronjobs "named.conf" is a mix of "template" for most configurations and contains a [panel_records] line which finally is replaced by all the zones to load and if they are slave/master that template exists 4 times LAN master LAN slave WAN master WAN slave the configuration of the cronjob also needs to exist 4 times since it must define master/slave and in case of slave who is the master that's perfect as it is, but makes it less generic for other environments, here the appeal is you can practically write any option you need in the configuration without refelect it in the admin-backend, the webinterface is only used for create a new zone with the most used default records and magage records 'dns_meta': the 'changes'-fields are first fetched by the cronjobs and if the are 0 nothing else is done, 'gui_lock' is set to 1 by start apply changes so if two people work at the same time in a backend (two admins here) no collisions ___
