# Trouble setting up secondary servers



## baronobeefdip (Feb 26, 2012)

I am crating a DNS environment with FreeBSD 9 boxes. I made a primary and secondary server and the secondary doesn't seem to be getting any zone information from the primary.
I have the named.conf file set up on the primary server like this:

```
options {
directory "/etc/namedb";
allow-query { any; };
listen-on port 53 { any; };
};
zone "baronobeefdip.com: {
type master;
file "zones/baronobeefdip.com";
};

zone "1.168.192.in-addr.arpa" {
type master;
file "zones/192.168.1.db";
};
```
And here is the named.conf file for the secondary server:

```
options {
directory "/etc/namedb";
allow-query { any; };
listen-on port 53 { any; };
};
zone "ns2.baronobeefdip.com: {
type slave;
file "zones/baronobeefdip.com";
masters { 192.168.1.77;};
};

zone "1.168.192.in-addr.arpa" {
type slave;
file "zones/192.168.1.db";
masters { 192.168.1.77; };
};
```
The primary DNS IP address is 192.168.1.77
The secondary is 192.168.1.66

So now I started running *nslookup* commands, When *I* attempted to run an *nslookup* to my primary DNS server I get an error. It says that the server can't be found even though I am able to ping the primary DNS from the secondary. What could be wrong here?


----------



## DutchDaemon (Feb 26, 2012)

Look in your logging, the nameservers probably aren't even running, since there are syntax errors in named.conf.

E.g.:

```
listen-on port 53 [B]{ any; }[/B];
```
is not the correct syntax. See named.conf(5) and http://www.isc.org/software/bind/documentation.

Also, the primary DNS needs allow-transfer and also-notify statements to allow the secondary nameserver to pull zone files from it.


----------



## baronobeefdip (Feb 26, 2012)

So I'm assuming that the named.conf file I presented for the secondary server is correct and that the primary file needs some revising. Here is what I got so far.

```
options {
directory "/etc/namedb";
allow-query { any; };
listen-on port 53 { any; };
[b]allow-transfer { 192.168.1.77; };
also-notify port 53 { 192.168.1.77; };
[/b]
};
zone "baronobeefdip.com: {
type master;
file "zones/baronobeefdip.com";
};

zone "1.168.192.in-addr.arpa" {
type master;
file "zones/192.168.1.db";
};
```
And now since the *allow-transfer* declaration is in there and has only one address, I am assuming that it won't allow transfers from other servers but the one that corresponds with the address provided. I was also looking into implementing dnssec zone tranfers between servers, I already understand dnssec to an extent, I just had some trouble with this piece.


----------



## kpa (Feb 26, 2012)

BIND includes a tool to check the syntax of the configuration files named-checkconf(8), there's also a tool to validate the zone files in the same way, named-checkzone(8).


----------



## baronobeefdip (Feb 26, 2012)

kpa said:
			
		

> BIND includes a tool to check the syntax of the configuration files named-checkconf(8), there's also a tool to validate the zone files in the same way, named-checkzone(8).



I did those already and it returned fine I just didn't have any declarations that would tell it to allow zone transfer like DutchDaemon mentioned earlier. So the syntax doesn't seem to be the problem as much as the fact that I didn't provide the options necessary to make BIND do these things that I want it to do. But I won't know if it works until I try it which will be soon. I'll post what I get once I try it again.


----------



## vand777 (Feb 26, 2012)

For secondary DNS server:

```
...

options {
        // All file and path names are relative to the chroot directory,
        // if any, and should be fully qualified.
        directory       "/etc/namedb/working";
        pid-file        "/var/run/named/pid";
        dump-file       "/var/dump/named_dump.db";
        statistics-file "/var/stats/named.stats";
[color="Red"]        recursion no;                      // Do not provide recursive service[/color]

// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
[color="Red"]//      listen-on       { 127.0.0.1; };[/color]

// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver.  To give access to the network, specify
// an IPv6 address, or the keyword "any".
[color="Red"]//      listen-on-v6    { ::1; };[/color]

...

zone "your.domain.com" {
   type slave;
[color="Red"]   file "/etc/namedb/slave/your.domain.com";
[/color]   masters { [color="Red"]XXX.XXX.XXX.XXX[/color]; };
};
```

Please make sure to have the full path to your.domain.com file. Pay attention to lines in red.

XXX.XXX.XXX.XXX is the IP of your master DNS server.


----------



## vand777 (Feb 26, 2012)

For primary DNS server:

```
options {
        // All file and path names are relative to the chroot directory,
        // if any, and should be fully qualified.
        directory       "/etc/namedb/working";
        pid-file        "/var/run/named/pid";
        dump-file       "/var/dump/named_dump.db";
        statistics-file "/var/stats/named.stats";
[color="Red"]        allow-query { any; };              // This is the default
        recursion no;                      // Do not provide recursive service
[/color]

// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
[color="Red"]//      listen-on       { 127.0.0.1; };[/color]

// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver.  To give access to the network, specify
// an IPv6 address, or the keyword "any".
[color="Red"]//      listen-on-v6    { ::1; };[/color]

...

zone "your.domain.com" {
   type master;
[color="Red"]   file "/etc/namedb/master/your.domain.com";
[/color]   allow-transfer { YYY.YYY.YYY.YYY; };
   allow-update { key rndc-key; };
};
```

Where YYY.YYY.YYY.YYY is the IP of your secondary server.

Pay attention to full path to your.domain.com file.


----------



## baronobeefdip (Feb 26, 2012)

Now I guess I have to put in all of the IP addresses of my secondary servers in the primary, Like if i had a zone declaration and two secondary servers, I would have something like this in the primary?


```
zone "baronobeefdip.com" {
type master;
file "zones/baronobeefdip.com";
allow-transfer { 192.168.1.20, 192.168.1.30; };
};
```
Primary 192.168.1.10
SecondaryA 192.168.1.20
SecondaryB 192.168.1.30

Or can I simply put *any* in the *allow-transfer* declaration instead of the IP addresses of the slaves and establish a chain of trust later so I don't have to set anything in the primary.


----------



## DutchDaemon (Feb 26, 2012)

No, don't use 'any', even though these machines appear not to be on the Internet. When you *do* place a DNS server on the Internet, this should not be a setting you put in routinely. No one but your secondary DNS server(s) should be allowed to download your zone files, ever.


----------



## baronobeefdip (Feb 27, 2012)

So if I am following correctly, You can prevent unauthorized transfers from your DNS servers with the allow-transfer and masters options without implementing DNSSEC so now I have another question. If you can achieve the type of security that you can with DNSSEC without it then what is the point of doing it in the first place. You are only allowing transfers to the machines that you tell it to do so and DNSSEC also prevents zone records from being transferred to DNS servers that it shouldn't transfer, The what is the point of implementing it.


----------



## SirDice (Feb 27, 2012)

http://helpwiki.easydns.com/index.php/What_is_DNSSEC


----------



## baronobeefdip (Feb 27, 2012)

Alright after doing a little more research I have found and now hopefully fully understand the objective of which *I* am trying to achieve, I am not trying to prevent servers from communicating with my master (although this information may prove to be useful in the future) I am trying to implement DNSSEC with the ability to sense poisoned requests from servers that shouldn't be touching my primary server. What allow-query and allow-transfer (might just be irrelevant right now) didn't sense the poisoned requests. *S*o now I have found the way of creating the ksk and zsk keys for signing the zone file. And I have also found out how to get the server to serve the records on the zone file that are signed and show the keys to confirm it is working with the *dig* command. I also found out how to get the primary server to detect poisoning but the problem is this, While the dnssec-validation and the trusted-keys declaration are doing just the I am faced with the problem that the way to retrieve the keys to put inside of the trusted-keys declaration with the *dig +dnssec sim.cyber.net dnskey* *I* am able to view the key out in the open where anyone can see it and will be able to put this inside of a request and get through without detection of poisoning. How do *I* make this key invisible to those that attempt to get it with the *dig* command?

*H*ere is my source
http://blog.dustintrammell.com/2008/08/01/configuring-dnssec-in-bind/


----------



## baronobeefdip (Mar 1, 2012)

Alright, simpler question: how do _I_ make a secondary server into a forwarder? In the sense that whenever I nslookup a query that the secondary server doesn't have (which is the one that all the clients are set to as their primary DNS server) it will forward the query to the primary server (when the pimary server's address is provided in the secondary's named.conf file). And it will resolve the name once it finds it on the primary server. I want the forwarding function to only happen whenever an unknown A or PTR record isn't on the secondary server and the secondary server should automatically forward the query to the primary to resolve it.


----------



## throAU (Mar 2, 2012)

As mentioned, you weren't allowing zone-transfers.

Now, the way dns works:  you do not need to allow DNS zone transfers to any and all DNS servers - only your secondaries.  Queries from elsewhere will be for individual records, not the entire zone.

To allow queries that the DNS can not answer itself, you need to allow recursion - I would allow recursion only for your local subnet(s).

To direct these queries to a specific DNS server (e.g., your primary) you need to set a forwarder in your config file.  I wouldn't bother using a forwarder to go to your primary NS though, as it will simply increase load and dependency on that machine - somewhat nullifying the point of having primary/secondary DNS servers.  Your secondary should be as independent from your primary as possible, save for sourcing authoritative zone files from it when the zones are updated.

I'd suggest setting the forwarder(s) on both your name-servers to be the name-servers provided by your ISP.  This will prevent your name servers having to query the root or authoritative name-servers every time they need to look up a record they don't have cached, or host locally.  There's a good chance your ISP will have those records cached, and hitting their name-servers should be faster.


----------



## kpa (Mar 2, 2012)

You could also set up a completely separate DNS forwarder (doesn't even have to BIND) to handle the bulk of the DNS queries from the client machines and leave your authoritative DNS server and its secondary to handle only your own domains.


----------



## baronobeefdip (Mar 2, 2012)

So recursion would do what I am trying to do, What the forwarders did that *I* really didn't like is that it checked the root DNS for the records first instead of the server itself that will be resolving the request. Now with the recursion feature it will do the opposite. Instead of checking an external DNS server first it will check its own zone files before discovering that it couldn't find what the client was looking for and then forward the query to the root DNS server in hopes that it will be there for resolving.

I better start google searching recursion if I want to achieve what I am doing here now that I know what it's called. But theres one last thing to mention. I don't want to use caching.


----------



## kpa (Mar 2, 2012)

http://www.zytrax.com/books/dns/ch2/#recursive

Probably the best reference material for BIND and DNS I've seen so far


----------



## throAU (Mar 3, 2012)

kpa said:
			
		

> http://www.zytrax.com/books/dns/ch2/#recursive
> 
> Probably the best reference material for BIND and DNS I've seen so far



Yup, I definitely second that recommendation.

It sounds like what you want is:

Allow-transfer:  for your secondary DNS server only, in your primary's config file.  Your secondary does not need to allow transfers
Allow-recursion: for your local subnets only
Forwarders:  set on both your name-servers, pointing at your ISP's name-servers to improve response time and not have to query the root servers.


----------



## baronobeefdip (Mar 3, 2012)

throAU said:
			
		

> Yup, I definitely second that recommendation.
> 
> It sounds like what you want is:
> 
> ...



Thanks I'm starting to understand this a little bit at a time.Is this how you put it in

primary
192.168.1.10

```
allow-transfer { 192.168.1.20; };
allow-recursion { 192.168.1.0/24; };
forwarders { 192.168.1.20, 8.8.8.8; };

zone "baronobeefdip.com" {
type master;
file "zones/baronobeefdip.com";
};

zone "1.168.192.in-addr.arpa" {
type master;
file "zones/192.168.1.db";
};
```

secondary 
192.168.1.20

```
allow-recursion { 192.168.1.0.24; };
forwarders { 192.168.1.10. 8.8.8.8; };

zone "me.baronobeefdip.com" {
type slave;
file "zones/me.baronobeefdip.com";
masters { 192.168.1.10; };
};
```
I don't plan on pointing the forwarders clause at the ISP's name server since this set up won't be connected to the internet and I intend to keep it that way for testing purposes, When this is up and running then I might connect it to the internet. But for now I just want the two servers to talk.


----------



## throAU (Mar 13, 2012)

See corrections below...



			
				baronobeefdip said:
			
		

> primary
> 192.168.1.10
> 
> ```
> ...




Remove the forwarder lines - your name servers do NOT need to have each other as a forwarder.  The secondary will already know to transfer your locally hosted zone from the primary due to the configuration for the zone.  The primary has the zone hosted locally, it is authoritative, and has no need for a forwarder to work.

All a forwarder line does is tells the BIND instance to forward all queries it does not know how to answer to the server listed, instead of the DNS root servers.  

Thus, if you are not connected to the internet, there is no need to have any forwarder line.  If you ARE connected to the internet, you should use forwarders that have a better idea of what is out there than you do (e.g., ISP's servers, Google, etc).  

Pointing your DNS servers at each other for zones you do not host will not help and *may *even end up causing them to go into an infinite loop attempting to do DNS resolution for non-local zones (I haven't tried this before, but if name server A tries to look up a zone and forwards to name server B, and name server B is set to name server A, well, you can see where things are going...

Further - your zone file names are different between primary and secondary servers!  They need to both be the same, the only statements that should be different between the primary and secondary servers in the zone file definition should be the "type", and the secondary should have a "masters" directive to tell it where to retrieve the zone file from. The "zone" and "file" directives should be the same.  Well, on my secondary, I like to put zones in a "slave" directory and master zones in a "master" directory on my primary, but zone file names should be identical.


----------



## olav (Mar 16, 2012)

Isn't DNS data public anyway? Isn't allow-transfer{some.ip.address;} just security by obscurity?

I use view instead.


----------



## DutchDaemon (Mar 17, 2012)

There is no reason to hand your entire network infrastructure with hostnames and IP addresses (and possible clues about how they interrelate) to a possible attacker on a plate. DNS information is available on a need-to-know basis.


----------

