slave server
I I create this configuration for my secondary server:
options {
forward only;
forwarders { serverA ; } ;
} ;
zone "example.com"{
type slave;
file "zone.db";
masters{ serverA; };
};
1- If I query to this server "example.com" (it's authoritative for
this domain) server first tries to retrieves info from its zone file
(zone.db, which has copied from master) or from its cache ?
2- if I query to this server external domain, it will forward request
to serverA ?
3- This server will work acting as also caching server ?
4- If serverA doesn't know query answer, this server will return
domain "domain is not exist" ?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: root and in-addr.arpa zone transfers
In article , Michael Monnerie wrote: > On Freitag 11 September 2009 Joseph S D Yao wrote: > > However, as M. Bortzmeyer has said, why do this? > > Faster queries after a named restart. ... How often do you restart named? We hit our master once a day, in the early hours but that's just habit and I've always thought we were a bit hyperactive. The slaves only get hit for upgrades or problems. > ... Reverse lookups faster too, good > for the spam filters. Only the first few, until the relevant X.in-addr.arpa NS records are cached. How many X in *.X.in-addr.arpa do you get spam from? Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: slave server
> I I create this configuration for my secondary server:
>
> options {
> forward only;
> forwarders { serverA ; } ;
> } ;
>
> zone "example.com"{
> type slave;
> file "zone.db";
> masters{ serverA; };
> };
On 11.09.09 00:21, Riccardo wrote:
> 1- If I query to this server "example.com" (it's authoritative for
> this domain) server first tries to retrieves info from its zone file
> (zone.db, which has copied from master) or from its cache ?
from the zone as/if it was loaded/transferred. It's not cache, nor the zone
file (the zone will be saved to a file but it will only be read on restart).
> 2- if I query to this server external domain, it will forward request
> to serverA ?
if you allowed recursion, yes.
> 3- This server will work acting as also caching server ?
unless you turned off caching...
> 4- If serverA doesn't know query answer, this server will return
> domain "domain is not exist" ?
what do you mean "query answer"? You server will send what it has in the
cache or what will serverA return, or an error if serverA is not accessible.
--
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.
Posli tento mail 100 svojim znamim - nech vidia aky si idiot
Send this email to 100 your friends - let them see what an idiot you are
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Restarting named [was: Re: root and in-addr.arpa zone transfers]
On Sep 11 2009, Sam Wilson wrote: In article , Michael Monnerie wrote: On Freitag 11 September 2009 Joseph S D Yao wrote: > However, as M. Bortzmeyer has said, why do this? Faster queries after a named restart. ... How often do you restart named? $ ps -o user,zone,pid,stime,time,comm -U namesrvr USER ZONE PIDSTIMETIME COMMAND namesrvr testdns0 104 Jul_28 00:16 /usr/local/BIND/bind/sbin/named namesrvr authdns0 1169 Jul_2907:11:15 /usr/local/BIND/bind/sbin/named namesrvr recdns0 1611 Jul_29 3-08:01:37 /usr/local/BIND/bind/sbin/named $ ps -o user,zone,pid,stime,time,comm -U namesrvr USER ZONE PIDSTIMETIME COMMAND namesrvr authdns1 13248 Jul_2905:03:41 /usr/local/BIND/bind/sbin/named namesrvr fakedns 12389 Jul_29 02:29 /usr/local/BIND/bind/sbin/named namesrvr testdns1 13981 Jul_29 00:17 /usr/local/BIND/bind/sbin/named namesrvr recdns1 13748 Jul_29 1-13:48:35 /usr/local/BIND/bind/sbin/named That was from the (somewhat urgent) upgrade from BIND 9.6.1 to 9.6.1-P1. It's not unusual for them to run for months without interruption. We hit our master once a day, in the early hours but that's just habit and I've always thought we were a bit hyperactive. I think so too. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
AUTO: Yong Bo Hu is out of the office. (returning 2009-09-26)
I am out of the office until 2009-09-26. I will be on my vacation from 09-11 to 09-26, and I will respond to your message when I return. Note: This is an automated response to your message "bind-users Digest, Vol 285, Issue 1" sent on 9/11/09 20:00:00. This is the only notification you will receive while this person is away.___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root and in-addr.arpa zone transfers
Slaving root is certainly not something I would recommend to everyone.
In fact, I don't even use it on all of our name servers. I was just
answering the question regarding how one would go about doing
something rather than why or why not to do it.
Here is why I do it and why I'm fairly comfortable with it.
We have 6 geographically separated servers that are only used for
recursive resolution for residential customers. 90% of the traffic to
those boxes (about 30k queries per second, per machine, during peak
hours) is crap. Having a locally slaved root zone cuts down on the
amount of crap we in turn forward out to the world (especially to the
root servers). Being able to answer (reject, in a way) these queries
locally also helps save CPU cycles on boxes that run at around 75% of
CPU capacity.
These are also boxes that are heavily monitored and that I am logged
in to every day.
Insofar as extra load on the root servers is concerned, I think I am
using far less root server resources by doing a few TCP connections
that help me avoid sending tons of crap to them via UDP.
Like I said earlier. Not something I would recommend for everyone,
but it seems to work well for what I use it for.
-rich
On Sep 10, 2009, at 8:16 PM, Joseph S D Yao wrote:
On Thu, Sep 10, 2009 at 11:27:27AM +0200, Michael Monnerie wrote:
On Mittwoch 09 September 2009 Rich Goodson wrote:
zone "." {
zone "arpa" {
zone "in-addr.arpa" {
Thank you Rich, and the others. Can anyone confirm that this is the
way
to do? Or should I stay with ftp updates from the websites? Is
there an
"officially supported" or "recommended" way to do this or that?
RFC 2870, "Root Name Server Operational Requirements", says:
2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
queries from clients other than other root servers. This
restriction is intended to, among other things, prevent
unnecessary load on the root servers as advice has been heard
such as "To avoid having a corruptible cache, make your server a
stealth secondary for the root zone." The root servers MAY put
the root zone up for ftp or other access on one or more less
critical servers.
You may take from that what you will. It sounds like discouragement
to
me.
However, as M. Bortzmeyer has said, why do this? I was doing it on a
smaller internet, and came back to find that transfers for "." had
been
turned off [but not in-addr.arpa [???]], and lookups were slowed down
because they were looking at our local "root" first. (It fixed itself
"by magic" when I complained, but nobody else had thought to do that.)
--
/
*\
**
** Joe Yao j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: root and in-addr.arpa zone transfers
On 11.09.09 09:13, Rich Goodson wrote: > Slaving root is certainly not something I would recommend to everyone. > In fact, I don't even use it on all of our name servers. I was just > answering the question regarding how one would go about doing something > rather than why or why not to do it. > > Here is why I do it and why I'm fairly comfortable with it. > We have 6 geographically separated servers that are only used for > recursive resolution for residential customers. 90% of the traffic to > those boxes (about 30k queries per second, per machine, during peak > hours) is crap. Having a locally slaved root zone cuts down on the > amount of crap we in turn forward out to the world (especially to the > root servers). Being able to answer (reject, in a way) these queries > locally also helps save CPU cycles on boxes that run at around 75% of > CPU capacity. Yesterdey I read (again, first time a ~year ago) the whole (hopefully) thread and I'll try to summarize what I've remembered: - too many "." slaves can cause overload of root nameservers - it's much easier to handle many UDP requests than a few TCP requests. - it's not good to have that by default. There are many DNS recursive servers in the world (I'd say most) that only have a few clients, and are not generating enough of traffic so they wouldn't spare anything but it could overload root servers. - if you have enough of different clients (which appears to be your case), it's apparently acceptable for you to slave the root zone, although it's recommended not to do from all of your servers. Local axfr hierarchy could do that. - the crap sent to TLD servers (yes, there's much of it but they can handle it) changes at time and their operators are finding reasons what's happening and contacting companies that are responsible for it. - only a few roots allow AXFR of root zone, despite RFC discourages that. ISC servers (and possibly others) do that for diagnostic reason, not for "ordinary" people doing that. - it's quite risky if server(s) in the "masters" directive would stop providing AXFR, the zone could expire which would lead to troubles. - there are scripts fetching the root zone via FTP from rs.internic.net, unluckily not all of them asre verifying all those check for its signature, which may lead to problems. Expiration doesn't happen here which can otoh cause problem when scripts fail to fetch the zone and new TLDs will appear or the root servers' IPs will change. - it's quite useless to cache the .arpa and .in-addr.arpa since unlike other TLD's they are hierarchically organised so there won't be any valuable benefit from slaving them, only risks (see above). - there's no way of slaving huge domains like .com .net (they aren't apparently slaved even by verisign's servers). -- 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. Linux IS user friendly, it's just selective who its friends are... ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
SELinux / bind conflict
Hello, I'm having a bit of difficulty setting up bind on FC11 (x64) which I'm using in a standalone network environment (i.e. no external network connectivity; essentially a closed dev network). I loaded the package from Red Hat and started it running as a service after building my zone files and /etc/named.conf. I'm not using chroot, just vanilla bind. I've read a number of posts about conflicts with bind and SELinux which seems to be the issue here. When I set the named_write_master_zones flag in SELinux, any actions related to starting or stopping the named service seem to set the flag back to false. > restorecon -R -v /var/named > setsebool -P named_write_master_zones=1 Message log entry: Sep 11 17:13:11 netmgr setsebool: The named_write_master_zones policy boolean was changed to 1 by root > service named restart Message log entry: Sep 11 17:13:19 netmgr setsebool: The named_write_master_zones policy boolean was changed to 0 by root Sep 11 17:13:19 netmgr named[3198]: received control channel command 'stop' Sep 11 17:13:19 netmgr named[3198]: shutting down: flushing changes Sep 11 17:13:19 netmgr named[3198]: stopping command channel on 127.0.0.1#953 Sep 11 17:13:19 netmgr named[3198]: stopping command channel on ::1#953 Sep 11 17:13:19 netmgr named[3198]: no longer listening on 127.0.0.1#53 Sep 11 17:13:19 netmgr named[3198]: no longer listening on 192.168.2.0#53 Sep 11 17:13:19 netmgr named[3198]: no longer listening on ::1#53 Sep 11 17:13:19 netmgr named[3198]: exiting Sep 11 17:13:20 netmgr named[3270]: starting BIND 9.6.1-P1-RedHat-9.6.1-4.P1.fc11 -u named Sep 11 17:13:20 netmgr named[3270]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE' Sep 11 17:13:20 netmgr named[3270]: adjusted limit on open files from 1024 to 1048576 Sep 11 17:13:20 netmgr named[3270]: found 4 CPUs, using 4 worker threads Sep 11 17:13:20 netmgr named[3270]: using up to 4096 sockets Sep 11 17:13:20 netmgr named[3270]: loading configuration from '/etc/named.conf' Sep 11 17:13:20 netmgr named[3270]: using default UDP/IPv4 port range: [1024, 65535] Sep 11 17:13:20 netmgr named[3270]: using default UDP/IPv6 port range: [1024, 65535] Sep 11 17:13:20 netmgr named[3270]: listening on IPv4 interface lo, 127.0.0.1#53 Sep 11 17:13:20 netmgr named[3270]: listening on IPv4 interface eth0, 192.168.2.0#53 Sep 11 17:13:20 netmgr named[3270]: listening on IPv6 interface lo, ::1#53 Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: 127.IN-ADDR.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: 254.169.IN-ADDR.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: 2.0.192.IN-ADDR.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic 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 Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: D.F.IP6.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: 8.E.F.IP6.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: 9.E.F.IP6.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: A.E.F.IP6.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: B.E.F.IP6.ARPA Sep 11 17:13:20 netmgr named[3270]: command channel listening on 127.0.0.1#953 Sep 11 17:13:20 netmgr named[3270]: command channel listening on ::1#953 Sep 11 17:13:20 netmgr named[3270]: the working directory is not writable Sep 11 17:13:20 netmgr named[3270]: zone 0.in-addr.arpa/IN: NS '0.in-addr.arpa' has no address records (A or ) Sep 11 17:13:20 netmgr named[3270]: zone 0.in-addr.arpa/IN: loaded serial 0 Sep 11 17:13:20 netmgr named[3270]: zone 1.0.0.127.in-addr.arpa/IN: NS '1.0.0.127.in-addr.arpa' has no address records (A or ) Sep 11 17:13:20 netmgr named[3270]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 Sep 11 17:13:20 netmgr named[3270]: zone 2.168.192.in-addr.arpa/IN: NS 'netmgr.2.168.192.in-addr.arpa' has no address records (A or ) Sep 11 17:13:20 netmgr named[3270]: zone 2
Re: SELinux / bind conflict
On Fri, 11 Sep 2009, Andrews, Harold G CTR USAF HQ AF GCIC/CT wrote: I’m having a bit of difficulty setting up bind on FC11 (x64) which I’m using in a standalone network environment (i.e. no external network connectivity; essentially a closed dev network). I loaded the package from Red Hat and started it running as a service after building my zone files and /etc/named.conf. I’m not using chroot, just vanilla bind. I’ve read a number of posts about conflicts with bind and SELinux which seems to be the issue here. When I set the named_write_master_zones flag in SELinux, any actions related to starting or stopping the named service seem to set the flag back to false. Adam is the person to ask about SElinux and Bind. I've CC:ed him and included the message for him. Adam, can you help Harold? Paul > restorecon –R –v /var/named > setsebool -P named_write_master_zones=1 Message log entry: Sep 11 17:13:11 netmgr setsebool: The named_write_master_zones policy boolean was changed to 1 by root > service named restart Message log entry: Sep 11 17:13:19 netmgr setsebool: The named_write_master_zones policy boolean was changed to 0 by root Sep 11 17:13:19 netmgr named[3198]: received control channel command 'stop' Sep 11 17:13:19 netmgr named[3198]: shutting down: flushing changes Sep 11 17:13:19 netmgr named[3198]: stopping command channel on 127.0.0.1#953 Sep 11 17:13:19 netmgr named[3198]: stopping command channel on ::1#953 Sep 11 17:13:19 netmgr named[3198]: no longer listening on 127.0.0.1#53 Sep 11 17:13:19 netmgr named[3198]: no longer listening on 192.168.2.0#53 Sep 11 17:13:19 netmgr named[3198]: no longer listening on ::1#53 Sep 11 17:13:19 netmgr named[3198]: exiting Sep 11 17:13:20 netmgr named[3270]: starting BIND 9.6.1-P1-RedHat-9.6.1-4.P1.fc11 -u named Sep 11 17:13:20 netmgr named[3270]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE' Sep 11 17:13:20 netmgr named[3270]: adjusted limit on open files from 1024 to 1048576 Sep 11 17:13:20 netmgr named[3270]: found 4 CPUs, using 4 worker threads Sep 11 17:13:20 netmgr named[3270]: using up to 4096 sockets Sep 11 17:13:20 netmgr named[3270]: loading configuration from '/etc/named.conf' Sep 11 17:13:20 netmgr named[3270]: using default UDP/IPv4 port range: [1024, 65535] Sep 11 17:13:20 netmgr named[3270]: using default UDP/IPv6 port range: [1024, 65535] Sep 11 17:13:20 netmgr named[3270]: listening on IPv4 interface lo, 127.0.0.1#53 Sep 11 17:13:20 netmgr named[3270]: listening on IPv4 interface eth0, 192.168.2.0#53 Sep 11 17:13:20 netmgr named[3270]: listening on IPv6 interface lo, ::1#53 Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: 127.IN-ADDR.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: 254.169.IN-ADDR.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: 2.0.192.IN-ADDR.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic 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 Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: D.F.IP6.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: 8.E.F.IP6.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: 9.E.F.IP6.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: A.E.F.IP6.ARPA Sep 11 17:13:20 netmgr named[3270]: automatic empty zone: B.E.F.IP6.ARPA Sep 11 17:13:20 netmgr named[3270]: command channel listening on 127.0.0.1#953 Sep 11 17:13:20 netmgr named[3270]: command channel listening on ::1#953 Sep 11 17:13:20 netmgr named[3270]: the working directory is not writable Sep 11 17:13:20 netmgr named[3270]: zone 0.in-addr.arpa/IN: NS '0.in-addr.arpa' has no address records (A or ) Sep 11 17:13:20 netmgr named[3270]: zone 0.in-addr.arpa/IN: loaded serial 0 Sep 11 17:13:20 netmgr named[3270]: zone 1.0.0.127.in-addr.arpa/IN: NS '1.0.0.127.in-addr.arpa' has no address records (A or ) Sep 11 17:13:20 netmgr named[3270]: zone 1.0.0.12
