Re: Slaving from DNS masters behind LVS

[WBrown]

Nick wrote on 02/12/2013 10:00:27 PM:

> We have a pair of DNS servers running BIND behind a direct routing LVS
> director pair running keepalived.  Let's call these two DNS servers A
> and B, and the VIP V.

Several years ago I was lucky enough to take the ISC class on bind. One of 
my questions going into the class was about using a load balancer in front 
to our name servers.  We have two VMs for internal resolution and two more 
for external. 

The instructor said not to use a load balancer as the DNS protocol had the 
resilience to handle a server going down and the load balancer adds to the 
complexity of troubleshooting problems.  We had never had a problem with 
either BIND crashing or network issues making them all unavailable, so the 
load balancer was really a solution looking for a problem.

Recently, we had to take the slave name servers (1 internal, 1 external) 
down to move the VMs to a different storage pool.  There were no issues 
with everyone continuing to use the masters only.

My current goals are to restructure our DNS, but load balancing is not in 
the future here. 

-- 

Bill




Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.
___
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: Slaving from DNS masters behind LVS

[Nick Urbanik]

Dear WBrown,

Thank you for your helpful reply.

On 13/02/13 08:11 -0500, wbr...@e1b.org wrote:

Nick wrote on 02/12/2013 10:00:27 PM:


We have a pair of DNS servers running BIND behind a direct routing LVS
director pair running keepalived.  Let's call these two DNS servers A
and B, and the VIP V.


Several years ago I was lucky enough to take the ISC class on bind.


Jealous!


One of my questions going into the class was about using a load
balancer in front to our name servers.  We have two VMs for internal
resolution and two more for external.

The instructor said not to use a load balancer as the DNS protocol had the
resilience to handle a server going down and the load balancer adds to the
complexity of troubleshooting problems.  We had never had a problem with
either BIND crashing or network issues making them all unavailable, so the
load balancer was really a solution looking for a problem.

Recently, we had to take the slave name servers (1 internal, 1 external)
down to move the VMs to a different storage pool.  There were no issues
with everyone continuing to use the masters only.

My current goals are to restructure our DNS, but load balancing is not in
the future here.


I think that it is not necessarily always true that you should avoid a
load balancer.  Every day, our DNS caches are answering about 140,000
queries per second.  I think that it is rather hard to configure
resolvers to query only three machines yet still meet the demand
unless you either use very massive, expensive machines, or use load
balancers.

So the questions remain.
--
Nick Urbanik http://nicku.org 808-71011 nick.urba...@optusnet.com.au
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24  ID: BB9D2C24
I disclaim, therefore I am.
___
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: Slaving from DNS masters behind LVS

[Phil Mayers]

On 13/02/13 14:30, Nick Urbanik wrote:



I think that it is not necessarily always true that you should avoid a
load balancer.  Every day, our DNS caches are answering about 140,000
queries per second.  I think that it is rather hard to configure
resolvers to query only three machines yet still meet the demand
unless you either use very massive, expensive machines, or use load
balancers.

So the questions remain.


My rule of thumb is this:

 1. For client->DNS comms (resolv.conf, DHCP-supplied DNS IPs, etc.) I 
use a VIP. This allows for future scalability and adds/moves/changes 
without time-consuming reconfiguring of clients, and avoid the problem 
where some clients have poor/slow failover between DNS servers (unix 
systems without nscd/lwresd).


 2. For DNS->DNS comms I use real IPs. This includes "forwarders", NS 
records, "masters" statements and so on. The rationale is that DNS 
servers, when talking to other DNS servers, almost universally have 
fast, intelligent detection of failures, and thus don't need the benefit 
of a VIP.


However - as with all things, "it depends". There are circumstances 
where VIPs (possibly only backed by one real server) are suitable for 
DNS->DNS, and real IPs for client->DNS (e.g. resolv.conf on the DNS 
server itself).


There's no one definitively "right" answer, since it depends on what 
you're trying to achieve, and what architecture your network and 
supporting systems have.

___
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: Slaving from DNS masters behind LVS

[Tony Finch]

Nick Urbanik  wrote:
>
> I think that it is not necessarily always true that you should avoid a
> load balancer.  Every day, our DNS caches are answering about 140,000
> queries per second.  I think that it is rather hard to configure
> resolvers to query only three machines yet still meet the demand
> unless you either use very massive, expensive machines, or use load
> balancers.

Another option is to use anycast.
http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
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: Slaving from DNS masters behind LVS

[Phil Mayers]

On 13/02/13 15:34, Tony Finch wrote:

Nick Urbanik  wrote:


I think that it is not necessarily always true that you should avoid a
load balancer.  Every day, our DNS caches are answering about 140,000
queries per second.  I think that it is rather hard to configure
resolvers to query only three machines yet still meet the demand
unless you either use very massive, expensive machines, or use load
balancers.


Another option is to use anycast.
http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=


In fact, you can do both. Our recursive DNS server is accessible via two 
IPs - one virtual IP, hosted on a load-balancer, and one anycast IP 
advertised conditionally (on port 53 being open locally) using BGP from 
each DNS server. This means you've got some diversity.

___
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

chroot/etc/named/ directory?

[Robert Moskowitz]

I am upgrading my server from bind-9.3.6 via Centos 5.5 to 9.8.2 in 
Centos 6.3.


I have and will run bind chrooted and on my test setup I noticed a 'new' 
subdirectory in the chroot tree:


/var/named/chroot/etc/named/

I cannot find any documentation as what is indended to be placed in this 
subdirectory.  my includes for named.conf?


I am assuming the pki subdirectory is for DNSSEC related files, but I 
have not found any documentation indicating so.  But then I have not 
plowed through DNSSEC documention in depth yet.



___
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

SOA issue

[Paul A]

Can anyone tell help me figure out why this SOA is not changing no matter
what I do. The zone was edited and has a new SOA but no matter what I do
bind doesn't reload the zone with the new SOA. I tried rndc freeze/unfreeze
and still nothing. Short of reloading bind what else can I do.

 

TIA, Paul

 

named-compilezone -o - sturdymemorial.org db.sturdymemorial

zone sturdymemorial.org/IN: loaded serial 2013021307

sturdymemorial.org.   86400 IN SOA
reuben.meganet.net. postmaster.naisp.net. 2013021307 10800 3600 604800 600

OK

 

rndc reload sturdymemorial.org

zone reload up-to-date

 

 

dig @localhost  sturdymemorial.org soa

 

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57470

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

 

;; QUESTION SECTION:

;sturdymemorial.org.IN  SOA

 

;; ANSWER SECTION:

sturdymemorial.org. 600 IN  SOA reuben.meganet.net.
postmaster.naisp.net. 2012011801 10800 3600 604800 600

 

from the log file

 

named[26675]: received control channel command 'reload sturdymemorial.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

Re: chroot/etc/named/ directory?

[Mike Hoskins (michoski)]

-Original Message-

From: Robert Moskowitz 
Date: Wednesday, February 13, 2013 10:53 AM
To: "bind-users@lists.isc.org" 
Subject: chroot/etc/named/ directory?

>I am upgrading my server from bind-9.3.6 via Centos 5.5 to 9.8.2 in
>Centos 6.3.
>
>I have and will run bind chrooted and on my test setup I noticed a 'new'
>subdirectory in the chroot tree:
>
>/var/named/chroot/etc/named/
>
>I cannot find any documentation as what is indended to be placed in this
>subdirectory.  my includes for named.conf?
>
>I am assuming the pki subdirectory is for DNSSEC related files, but I
>have not found any documentation indicating so.  But then I have not
>plowed through DNSSEC documention in depth yet.

If you installed bind*-chroot, it will populate the /var/named/chroot
hierarchy.  It's not strictly required (though I would suggest it), but if
you intend to run BIND chrooted "/var/named/chroot" is essentially "/".
You'll have to place the usual things BIND needs to operate under that
directory -- configs, zones, etc.  Assuming this came from the chroot RPM,
you'll already have other essential pieces for chroot such as your
null/random/zero devices.  Since you mention CentOS, you'll likely also
want to pay attention to things like ROOTDIR in /etc/sysconfig/named.

Having said all that, you might search the archives (SRPMS have been
provided by community members) or other sources for a newer BIND while
you're at it...9.8.2 isn't ancient, but also not technically "up to date"
now.  I am personally waiting for 9.9.3 to leave beta, but 9.8.4-P1
probably makes sense for you today.  This won't affect your chroot setup,
just something worth considering since you're upgrading.

___
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: Slaving from DNS masters behind LVS

[Chris Buxton]

On Feb 12, 2013, at 7:00 PM, Nick Urbanik wrote:
> We have a pair of DNS servers running BIND behind a direct routing LVS
> director pair running keepalived.  Let's call these two DNS servers A
> and B, and the VIP V.
> 
> They slave from a hidden master; let's call it M.
> 
> I want to allow another machine S to slave from A and B, the pair of
> DNS servers that are behind LVS.
> 
> Another machine F will forward to the DNS servers behind the load
> balancer, A and B.
> 
> [There is another similar setup at another location, so there will
> be a V1 and V2, A1, A2, B1, B2; all of A1, A2, B1, B2 slave from M.]
> 
> 1. Should the machine in the SOA be V, or A or B?
> 2. Should the NS records for the zones be A, B and V, or just V?
> 3, Should S slave from A and B, or should it slave from V?
> 4. Should F forward to V, or to both A and B?

Generally speaking, if you're going to use a load balancer, use it. Don't go 
around it. I assume your VIP will actually float between two load balancers, 
for redundancy.

Why is forwarding involved? Forwarding is a recursive server behavior, but your 
other questions relate to authoritative service. Mixing the two, especially in 
a high-traffic environment, is a recipe for disaster. (Not that I haven't 
implemented that for even very large customers -- the customer is always right 
unless you can convince them otherwise. Use of multiple views, with 
match-recursive-only enabled in one of them, can somewhat alleviate the 
problem.)

1. Your choice. Mine would be M. My second choice would be either V1 or V2, if 
there was some need to truly conceal the identity of M.
2. V1 and V2.
3. V1 and V2.
4. V1 and V2.

But as others have pointed out, unless you're getting huge numbers of queries, 
I wouldn't bother with load balancers for authoritative service. I would only 
start looking for this type of solution if 6 individual name servers were 
insufficient to handle the load. And in that case, my first choice would be 
anycast, because that also gives you geographic redundancy, routing redundancy, 
etc. That's how the root server clusters are set up, for the most part.

For recursive service, where clients can't be relied upon to effectively use 
any server beyond the first one they query, load balancers make good sense. But 
in that case, you (ideally) shouldn't have any zones configured on the name 
servers other than (possibly) RPZs, stub zones, and (if you really must) 
conditional forwarding zones.

Chris Buxton
BlueCat Networks
___
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: SOA issue

[Chris Buxton]

On Feb 13, 2013, at 9:22 AM, Paul A wrote:

> Can anyone tell help me figure out why this SOA is not changing no matter 
> what I do. The zone was edited and has a new SOA but no matter what I do bind 
> doesn’t reload the zone with the new SOA. I tried rndc freeze/unfreeze and 
> still nothing. Short of reloading bind what else can I do.
>  
> TIA, Paul
>  
> named-compilezone -o - sturdymemorial.org db.sturdymemorial
> zone sturdymemorial.org/IN: loaded serial 2013021307
> sturdymemorial.org.   86400 IN SOA  
> reuben.meganet.net. postmaster.naisp.net. 2013021307 10800 3600 604800 600
> OK

Your zone only has an SOA record. A zone without NS records will not load.

If that's not really the issue, because you've edited the output above, a 
couple of hints:

- rndc reload  is unnecessary if rndc freeze  executes correctly. A 
dynamic zone (one that you would freeze and thaw) cannot be reloaded. Thawing 
the zone effectively reloads it.

- Do not edit a dynamic zone's zone file without first freezing it. Otherwise, 
when you freeze it, the data in memory will be written to disk, overwriting 
your changes.

- Are you sure you're editing the right file?

Chris Buxton
BlueCat Networks

> rndc reload sturdymemorial.org
> zone reload up-to-date
>  
>  
> dig @localhost  sturdymemorial.org soa
>  
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57470
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
>  
> ;; QUESTION SECTION:
> ;sturdymemorial.org.IN  SOA
>  
> ;; ANSWER SECTION:
> sturdymemorial.org. 600 IN  SOA reuben.meganet.net. 
> postmaster.naisp.net. 2012011801 10800 3600 604800 600
>  
> from the log file
>  
> named[26675]: received control channel command 'reload sturdymemorial.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

___
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: chroot/etc/named/ directory?

[Lightner, Jeff]

Haven't done it on RHEL/CentOS 6.x yet but in RHEL5 with the bind-chroot 
installed I've always had:
/var/named/chroot as the jail for BIND.
/var/named/chroot/etc = Location of global config files such as named.conf
/var/named/chroot/var/named = Location of the zone files.

I don't see a /var/named/chroot/etc/named in RHEL5 but then again that is based 
on BIND 9.3.  RHEL6 is almost certainly based on a higher upstream version.   
Since CentOS is built from RHEL source it would have that higher version as 
well.






-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org 
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Mike 
Hoskins (michoski)
Sent: Wednesday, February 13, 2013 12:44 PM
To: bind-users@lists.isc.org
Subject: Re: chroot/etc/named/ directory?

-Original Message-

From: Robert Moskowitz 
Date: Wednesday, February 13, 2013 10:53 AM
To: "bind-users@lists.isc.org" 
Subject: chroot/etc/named/ directory?

>I am upgrading my server from bind-9.3.6 via Centos 5.5 to 9.8.2 in
>Centos 6.3.
>
>I have and will run bind chrooted and on my test setup I noticed a 'new'
>subdirectory in the chroot tree:
>
>/var/named/chroot/etc/named/
>
>I cannot find any documentation as what is indended to be placed in
>this subdirectory.  my includes for named.conf?
>
>I am assuming the pki subdirectory is for DNSSEC related files, but I
>have not found any documentation indicating so.  But then I have not
>plowed through DNSSEC documention in depth yet.

If you installed bind*-chroot, it will populate the /var/named/chroot 
hierarchy.  It's not strictly required (though I would suggest it), but if you 
intend to run BIND chrooted "/var/named/chroot" is essentially "/".
You'll have to place the usual things BIND needs to operate under that 
directory -- configs, zones, etc.  Assuming this came from the chroot RPM, 
you'll already have other essential pieces for chroot such as your 
null/random/zero devices.  Since you mention CentOS, you'll likely also want to 
pay attention to things like ROOTDIR in /etc/sysconfig/named.

Having said all that, you might search the archives (SRPMS have been provided 
by community members) or other sources for a newer BIND while you're at 
it...9.8.2 isn't ancient, but also not technically "up to date"
now.  I am personally waiting for 9.9.3 to leave beta, but 9.8.4-P1 probably 
makes sense for you today.  This won't affect your chroot setup, just something 
worth considering since you're upgrading.

___
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




Athena(r), Created for the Cause(tm)
Making a Difference in the Fight Against Breast Cancer

-
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
information and is for the sole use of the intended recipient(s). If you are 
not the intended recipient, any disclosure, copying, distribution, or use of 
the contents of this information is prohibited and may be unlawful. If you have 
received this electronic transmission in error, please reply immediately to the 
sender that you have received the message in error, and delete it. Thank you.
--

___
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: SOA issue

[Lightner, Jeff]

Also make sure you’ve incremented the serial number in the zone file by at 
least 1.





From: bind-users-bounces+jlightner=water@lists.isc.org 
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of 
Chris Buxton
Sent: Wednesday, February 13, 2013 12:58 PM
To: Paul A
Cc: bind-us...@isc.org
Subject: Re: SOA issue

On Feb 13, 2013, at 9:22 AM, Paul A wrote:


Can anyone tell help me figure out why this SOA is not changing no matter what 
I do. The zone was edited and has a new SOA but no matter what I do bind 
doesn’t reload the zone with the new SOA. I tried rndc freeze/unfreeze and 
still nothing. Short of reloading bind what else can I do.

TIA, Paul

named-compilezone -o - sturdymemorial.org 
db.sturdymemorial
zone sturdymemorial.org/IN: loaded serial 
2013021307
sturdymemorial.org.   86400 
IN SOA  reuben.meganet.net. 
postmaster.naisp.net. 2013021307 10800 3600 
604800 600
OK

Your zone only has an SOA record. A zone without NS records will not load.

If that's not really the issue, because you've edited the output above, a 
couple of hints:

- rndc reload  is unnecessary if rndc freeze  executes correctly. A 
dynamic zone (one that you would freeze and thaw) cannot be reloaded. Thawing 
the zone effectively reloads it.

- Do not edit a dynamic zone's zone file without first freezing it. Otherwise, 
when you freeze it, the data in memory will be written to disk, overwriting 
your changes.

- Are you sure you're editing the right file?

Chris Buxton
BlueCat Networks


rndc reload sturdymemorial.org
zone reload up-to-date


dig @localhost  sturdymemorial.org soa

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57470
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;sturdymemorial.org.IN  SOA

;; ANSWER SECTION:
sturdymemorial.org. 600 IN  SOA 
reuben.meganet.net. 
postmaster.naisp.net. 2012011801 10800 3600 
604800 600

from the log file

named[26675]: received control channel command 'reload 
sturdymemorial.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






Athena®, Created for the Cause™

Making a Difference in the Fight Against Breast Cancer





How and Why I Should Support Bottled Water!
Do not relinquish your right to choose bottled water as a healthy alternative 
to beverages that contain sugar, calories, etc. Your support of bottled water 
will make a difference! Your signatures count! Go to 
http://www.bottledwatermatters.org/luv-bottledwater-iframe/dswaters and sign a 
petition to support your right to always choose bottled water. Help fight 
federal and state issues, such as bottle deposits (or taxes) and organizations 
that want to ban the sale of bottled water. Support community curbside 
recycling programs. Support bottled water as a healthy way to maintain proper 
hydration. Our goal is 50,000 signatures. Share this petition with your friends 
and family today!



-
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
information and is for the sole use of the intended recipient(s). If you are 
not the intended recipient, any disclosure, copying, distribution, or use of 
the contents of this information is prohibited and may be unlawful. If you have 
received this electronic transmission in error, please reply immediately to the 
sender that you have received the message in error, and delete it. Thank you.
--


___
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: chroot/etc/named/ directory?

[Robert Moskowitz]

On 02/13/2013 12:43 PM, Mike Hoskins (michoski) wrote:

-Original Message-

From: Robert Moskowitz 
Date: Wednesday, February 13, 2013 10:53 AM
To: "bind-users@lists.isc.org" 
Subject: chroot/etc/named/ directory?


I am upgrading my server from bind-9.3.6 via Centos 5.5 to 9.8.2 in
Centos 6.3.

I have and will run bind chrooted and on my test setup I noticed a 'new'
subdirectory in the chroot tree:

/var/named/chroot/etc/named/

I cannot find any documentation as what is indended to be placed in this
subdirectory.  my includes for named.conf?

I am assuming the pki subdirectory is for DNSSEC related files, but I
have not found any documentation indicating so.  But then I have not
plowed through DNSSEC documention in depth yet.

If you installed bind*-chroot, it will populate the /var/named/chroot
hierarchy.


I have been running chrooted since. Well probably when I switched from 
NT to Linux in '98. At first it was Whitehat, then Centos. I installed 
bind-chroot and though it built the /var/named/chroot tree, the only 
file is ~/etc/localtime, nothing else prepopulated. Well I DO have all 
my files from my current server to rsync over (over SSH so I don't have 
to actually run rsyncd), so it is no loss, just a question of "where is 
everything". I seem to recall this tree in previous attempts to not be 
empty. Maybe they learned it is better for someone working here to do it 
all themselves...


There are 'standard bind' files under /etc/nam* and /var/named to copy 
over if I choose (and find them more current than what I have from 2 
years ago).



It's not strictly required (though I would suggest it), but if
you intend to run BIND chrooted "/var/named/chroot" is essentially "/".


Learned that some years ago. Familiar with how the tree is mounted.


You'll have to place the usual things BIND needs to operate under that
directory -- configs, zones, etc.


Just seems that prior rpms came with a FEW files preset, like 
named.rfc1912.zones. But that was years ago and me brain is probably a 
little weak in the memory department.



Assuming this came from the chroot RPM, you'll already have other essential 
pieces for chroot such as your
null/random/zero devices.


Yes. And there are a few under ~/dev/


Since you mention CentOS, you'll likely also
want to pay attention to things like ROOTDIR in /etc/sysconfig/named.


Came preset. I am assuming handled by the bind-chroot rpm.


Having said all that, you might search the archives (SRPMS have been
provided by community members) or other sources for a newer BIND while
you're at it...9.8.2 isn't ancient, but also not technically "up to date"
now.


I am not up to building on my own and the few extra repos I work with 
(EPEL and rpmfusion) do not have a newer version all ready for Centos 6.3.


How bad is it? :)


I am personally waiting for 9.9.3 to leave beta, but 9.8.4-P1
probably makes sense for you today.  This won't affect your chroot setup,
just something worth considering since you're upgrading.


I would want to find it already in an rpm. Once on the build it yourself 
carousel you are set there and I have other things I am suppose to be doing.



___
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: chroot/etc/named/ directory?

[Robert Moskowitz]

On 02/13/2013 01:44 PM, Lightner, Jeff wrote:

Haven't done it on RHEL/CentOS 6.x yet but in RHEL5 with the bind-chroot 
installed I've always had:
/var/named/chroot as the jail for BIND.
/var/named/chroot/etc = Location of global config files such as named.conf
/var/named/chroot/var/named = Location of the zone files.


These I am use to and have used them for years.


I don't see a /var/named/chroot/etc/named in RHEL5 but then again that is based 
on BIND 9.3.  RHEL6 is almost certainly based on a higher upstream version.   
Since CentOS is built from RHEL source it would have that higher version as 
well.


Yes. I am going from Centos (RHEL) 5.5 to 6.3, so the new directory just 
has me wondering. I found it also as /etc/named/ so it is part of their 
base bind rpm, but no documentation on what they expected to be place 
there. Just here is something new and I want to know why so that I am 
not supprised.



-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org 
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Mike 
Hoskins (michoski)
Sent: Wednesday, February 13, 2013 12:44 PM
To: bind-users@lists.isc.org
Subject: Re: chroot/etc/named/ directory?

-Original Message-

From: Robert Moskowitz 
Date: Wednesday, February 13, 2013 10:53 AM
To: "bind-users@lists.isc.org" 
Subject: chroot/etc/named/ directory?


I am upgrading my server from bind-9.3.6 via Centos 5.5 to 9.8.2 in
Centos 6.3.

I have and will run bind chrooted and on my test setup I noticed a 'new'
subdirectory in the chroot tree:

/var/named/chroot/etc/named/

I cannot find any documentation as what is indended to be placed in
this subdirectory.  my includes for named.conf?

I am assuming the pki subdirectory is for DNSSEC related files, but I
have not found any documentation indicating so.  But then I have not
plowed through DNSSEC documention in depth yet.

If you installed bind*-chroot, it will populate the /var/named/chroot hierarchy.  It's not strictly 
required (though I would suggest it), but if you intend to run BIND chrooted 
"/var/named/chroot" is essentially "/".
You'll have to place the usual things BIND needs to operate under that 
directory -- configs, zones, etc.  Assuming this came from the chroot RPM, 
you'll already have other essential pieces for chroot such as your 
null/random/zero devices.  Since you mention CentOS, you'll likely also want to 
pay attention to things like ROOTDIR in /etc/sysconfig/named.

Having said all that, you might search the archives (SRPMS have been provided by 
community members) or other sources for a newer BIND while you're at it...9.8.2 isn't 
ancient, but also not technically "up to date"
now.  I am personally waiting for 9.9.3 to leave beta, but 9.8.4-P1 probably 
makes sense for you today.  This won't affect your chroot setup, just something 
worth considering since you're upgrading.

___



___
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 does not answer

[Christian Tardif]

On 10/24/2012 11:56 AM, Chris Buxton wrote:

On Oct 23, 2012, at 5:17 PM, Christian Tardif wrote:


Hi,

I have a strange BIND behaviour I don't know how to handle. As I don't exactly 
know how to describe it, I'll rather explain what I did and what happens. But 
not quite easy to follow.

In my tests, I have two servers with BIND installed on them: SiteA (BIND 
9.8.2rc1 on CentOS 6.3), and SiteB (BIND 9.5.0-P2, on Mandriva 2008.1). A third 
environment helps me for diagnostics.

SiteA is a recursive name server. I've been able to prove that it does not 
behave correctly under certain circumstances by hitting it with a simple 
request: asking it to give me NS records for a certain subdomain for which it's 
primary for the base domain (dig @SiteA NS sub.domain.tld, SiteA being 
authoritative for domain.tld). It just times out. There are glue records on 
SiteA for the sub.domain.tld master BIND). In order to try to figure out what 
was going on, I try, directly from SiterA, to send a request, as a client, 
directly to the master of sub.domain.tld. Times out again. At this moment, I 
can't tell which server is faulty. But I ge the same behaviour trying to get an 
answer from a completely different server (SiteB). In that case as well, no 
answer. But still starting from SiteA.

I then tried to get a response for the request I made from SiteA to SiteB (as I 
control both), but this time, starting for my third environment. Then, SiteB 
answers to my request. So SiteB looks like it's working. But how come it does 
not answer my request from SiteA?  From BIND logs on siteB, there's no trace of 
SiteA-to-SiteB' request. In order to prove that my UDP packets actually reaches 
their destination, and are not modified during transit, I opened a tcpdump 
session on SiteA and on SiteB. Packets come through in good shape, but didn't 
find their way to BIND application, as it seems. In my opinion, SiteB is not 
part of the problem, as it answers normally to every other it receives from 
anywhere else than SiteA. If I try again SiteA-to-SiteB request, I can see with 
TCPDUMP that packets gets out of SiteA, and enters SiteB. But BIND doesn't 
react. Even if I try to enable debugging on SiteB, I don't see anything.

What could be wrong, and how do I solve it? What tools are available to help 
out? If I try to ask for recursive request (let's say www.google.com) from 
anywhere, pointing at SiteA, I get a proper answer.

What happens if you use 'dig +norec' in your tests? That is, use iterative 
queries. Does that change the behavior you see?

Chris Buxton
BlueCat Networks

Hi Chris,

Back to a DNS problem, I  came back to this thread. If I do a "dig 
+norec", I still don't get the final answer but then, I get a whole 
bunch of information (the NS records for the requested zone, and the A 
records relativey to these NS records)


Christian Tardif

___
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: chroot/etc/named/ directory?

[Mike Hoskins (michoski)]

-Original Message-

From: Robert Moskowitz 
Date: Wednesday, February 13, 2013 2:15 PM
To: Mike Hoskins 
Cc: "bind-users@lists.isc.org" 
Subject: Re: chroot/etc/named/ directory?

>>Having said all that, you might search the archives (SRPMS have been
>> provided by community members) or other sources for a newer BIND while
>> you're at it...9.8.2 isn't ancient, but also not technically "up to
>>date"
>> now.
>
>I am not up to building on my own and the few extra repos I work with
>(EPEL and rpmfusion) do not have a newer version all ready for Centos 6.3.
>
>How bad is it? :)

That's for you to decide:

https://www.isc.org/software/bind/security/matrix

Of course RHEL/CentOS make it somewhat hard to know what "9.8.2" means
without reading change logs.  They tend to select stable software versions
at release time, then backport fixes with their own version numbering.  So
"Red Hat's 9.8.2" likely has fixes for a lot of the "ISC 9.8.2"
issues...but you might want to confirm vs assume that.

>I would want to find it already in an rpm. Once on the build it yourself
>carousel you are set there and I have other things I am suppose to be
>doing.

Understood.  Happily, running secure DNS infra is one of the things that
pays my mortgage.  :-)

___
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: chroot/etc/named/ directory?

[Robert Moskowitz]

On 02/13/2013 03:40 PM, Mike Hoskins (michoski) wrote:

-Original Message-

From: Robert Moskowitz 
Date: Wednesday, February 13, 2013 2:15 PM
To: Mike Hoskins 
Cc: "bind-users@lists.isc.org" 
Subject: Re: chroot/etc/named/ directory?


Having said all that, you might search the archives (SRPMS have been
provided by community members) or other sources for a newer BIND while
you're at it...9.8.2 isn't ancient, but also not technically "up to
date"
now.

I am not up to building on my own and the few extra repos I work with
(EPEL and rpmfusion) do not have a newer version all ready for Centos 6.3.

How bad is it? :)

That's for you to decide:

https://www.isc.org/software/bind/security/matrix


So not SOOO bad, just Badenough (said the Moose to Rocky).


Of course RHEL/CentOS make it somewhat hard to know what "9.8.2" means
without reading change logs.  They tend to select stable software versions
at release time, then backport fixes with their own version numbering.  So
"Red Hat's 9.8.2" likely has fixes for a lot of the "ISC 9.8.2"
issues...but you might want to confirm vs assume that.


There is that. Just a check shows that #49 is fixed in what I have 
installed:


https://rhn.redhat.com/errata/RHSA-2012-1268.html

And #50:

https://rhn.redhat.com/errata/RHSA-2012-1363.html

So I would ASSuME that I can work with keeping my install current and 
will stay on top of things. At least for a while.


And getting back to the start of this thread, until something shows up, 
I will just ignore that ~/etc/named/ directory


thanks




I would want to find it already in an rpm. Once on the build it yourself
carousel you are set there and I have other things I am suppose to be
doing.

Understood.  Happily, running secure DNS infra is one of the things that
pays my mortgage.  :-)

___
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

Check out my profile on LinkedIn

[Michel BESNARD]

LinkedIn




I'd like to include you in my network to share updates and stay in touch.

- Michel

Michel BESNARD
Network Architect for Access Networks at Orange France / FT
Paris Area, France

Confirm that you know Michel BESNARD:
https://www.linkedin.com/e/m1ka4g-hd4zjblg-5i/isd/11062051864/pmChag80/?hs=false&tok=1sGxj7wvIx4lE1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/m1ka4g-hd4zjblg-5i/VbVwaBW4xLDjPZ8RCnhw7nQ4xt7iUUpshDAdSpQxxcal6uZ/goo/comp-protocols-dns-bind%40isc%2Eorg/20061/I3662745921_1/?hs=false&tok=1-cnSaJG0x4lE1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.


  
___
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: SOA issue

[Paul A]

Chris this is not a dynamic zone, I do have NS RR. I had to completely
restart bind for it to work. No matter what I did with the serial it
wouldn't change. Never had to do this before so it's a bit odd.

 

Named-checkzone gave me no errors and rndc reload worked fine but the zone
wouldn't update.

 

 

paul

 

From: bind-users-bounces+pamaral=meganet@lists.isc.org
[mailto:bind-users-bounces+pamaral=meganet@lists.isc.org] On Behalf Of
Chris Buxton
Sent: Wednesday, February 13, 2013 12:58 PM
To: Paul A
Cc: bind-us...@isc.org
Subject: Re: SOA issue

 

On Feb 13, 2013, at 9:22 AM, Paul A wrote:





Can anyone tell help me figure out why this SOA is not changing no matter
what I do. The zone was edited and has a new SOA but no matter what I do
bind doesn't reload the zone with the new SOA. I tried rndc freeze/unfreeze
and still nothing. Short of reloading bind what else can I do.

 

TIA, Paul

 

named-compilezone -o - sturdymemorial.org 
db.sturdymemorial

zone sturdymemorial.org/IN: loaded serial 2013021307

sturdymemorial.org  .
86400 IN SOA  reuben.meganet.net  .
postmaster.naisp.net  . 2013021307 10800 3600
604800 600

OK

 

Your zone only has an SOA record. A zone without NS records will not load.

 

If that's not really the issue, because you've edited the output above, a
couple of hints:

 

- rndc reload  is unnecessary if rndc freeze  executes
correctly. A dynamic zone (one that you would freeze and thaw) cannot be
reloaded. Thawing the zone effectively reloads it.

 

- Do not edit a dynamic zone's zone file without first freezing it.
Otherwise, when you freeze it, the data in memory will be written to disk,
overwriting your changes.

 

- Are you sure you're editing the right file?

 

Chris Buxton

BlueCat Networks





rndc reload sturdymemorial.org  

zone reload up-to-date

 

 

dig @localhost  sturdymemorial.org   soa

 

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57470

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

 

;; QUESTION SECTION:

;sturdymemorial.org.IN  SOA

 

;; ANSWER SECTION:

sturdymemorial.org  . 600 IN  SOA
reuben.meganet.net  . postmaster.naisp.net
 . 2012011801 10800 3600 604800 600

 

from the log file

 

named[26675]: received control channel command 'reload sturdymemorial.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

 

___
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: SOA issue

[Alan Clegg]

On Feb 13, 2013, at 6:10 PM, Paul A  wrote:

> Chris this is not a dynamic zone, I do have NS RR. I had to completely 
> restart bind for it to work. No matter what I did with the serial it wouldn’t 
> change. Never had to do this before so it’s a bit odd.
>  
> Named-checkzone gave me no errors and rndc reload worked fine but the zone 
> wouldn’t update.

Can you send us the ZONE entry from the named.conf that relates to this zone?

Thanks,
AlanC
-- 
Alan Clegg | +1-919-355-8851 | a...@clegg.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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: SOA issue

[Mark Andrews]

In message <00f701ce0a3f$5cc75db0$16561910$@net>, "Paul A" writes:
> 
> Chris this is not a dynamic zone, I do have NS RR. I had to completely
> restart bind for it to work. No matter what I did with the serial it
> wouldn't change. Never had to do this before so it's a bit odd.
> 
>  
> 
> Named-checkzone gave me no errors and rndc reload worked fine but the zone
> wouldn't update.
> 
>  
> 
>  
> 
> paul
> 
>  
> 
> From: bind-users-bounces+pamaral=meganet@lists.isc.org
> [mailto:bind-users-bounces+pamaral=meganet@lists.isc.org] On Behalf Of
> Chris Buxton
> Sent: Wednesday, February 13, 2013 12:58 PM
> To: Paul A
> Cc: bind-us...@isc.org
> Subject: Re: SOA issue
> 
>  
> 
> On Feb 13, 2013, at 9:22 AM, Paul A wrote:
> 
> 
> 
> 
> 
> Can anyone tell help me figure out why this SOA is not changing no matter
> what I do. The zone was edited and has a new SOA but no matter what I do
> bind doesn't reload the zone with the new SOA. I tried rndc freeze/unfreeze
> and still nothing. Short of reloading bind what else can I do.
> 
>  
> 
> TIA, Paul
> 
>  
> 
> named-compilezone -o - sturdymemorial.org 
> db.sturdymemorial
> 
> zone sturdymemorial.org/IN: loaded serial 2013021307
> 
> sturdymemorial.org  .
> 86400 IN SOA  reuben.meganet.net  .
> postmaster.naisp.net  . 2013021307 10800 3600
> 604800 600
> 
> OK
> 
>  
> 
> Your zone only has an SOA record. A zone without NS records will not load.
> 
>  
> 
> If that's not really the issue, because you've edited the output above, a
> couple of hints:
> 
>  
> 
> - rndc reload  is unnecessary if rndc freeze  executes
> correctly. A dynamic zone (one that you would freeze and thaw) cannot be
> reloaded. Thawing the zone effectively reloads it.
> 
>  
> 
> - Do not edit a dynamic zone's zone file without first freezing it.
> Otherwise, when you freeze it, the data in memory will be written to disk,
> overwriting your changes.
> 
>  
> 
> - Are you sure you're editing the right file?
> 
>  
> 
> Chris Buxton
> 
> BlueCat Networks
> 
> 
> 
> 
> 
> rndc reload sturdymemorial.org  
> zone reload up-to-date

"zone reload up-to-date" means that the modification time on the
zone has not changed.  Named records the time it starts loading the
zone and won't reload it unless the modification time is later than
that time.

Also turn off the "add a URL" option in your mail client.  All it
does is make it harder for people to read your email.

Mark

> dig @localhost  sturdymemorial.org   soa
> 
>  
> 
> ; (1 server found)
> 
> ;; global options: +cmd
> 
> ;; Got answer:
> 
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57470
> 
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
> 
>  
> 
> ;; QUESTION SECTION:
> 
> ;sturdymemorial.org.IN  SOA
> 
>  
> 
> ;; ANSWER SECTION:
> 
> sturdymemorial.org  . 600 IN  SOA
> reuben.meganet.net  . postmaster.naisp.net
>  . 2012011801 10800 3600 604800 600
> 
>  
> 
> from the log file
> 
>  
> 
> named[26675]: received control channel command 'reload sturdymemorial.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
-- 
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

Re: chroot/etc/named/ directory?

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 2013-02-13 at 14:15 -0500, Robert Moskowitz wrote:
> I am not up to building on my own and the few extra repos I work with
> (EPEL and rpmfusion) do not have a newer version all ready for Centos
> 6.3.

You might try
http://www.five-ten-sg.com/util/bind-9.9.2-0.3.P1.fc18.src.rpm

which builds on centos 6.3 - that is what I am using. It is plain ISC
9.9.2, packaged for fedora/redhat/centos.

EL6:
  rpmbuild --rebuild --define 'dist .el6' \
  bind-9.9.2-0.3.P1.fc18.src.rpm

Or I can provide binary rpms if you don't want to do the build from
source.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlEcRQoACgkQL6j7milTFsFn7gCfVY8susLbv64oVchrBdbZgqOT
koUAn3iPIBnq06I0YJK/9844siBbKcB1
=kxns
-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