Best way to handle multiple zones

Chris Buxton cbuxton at menandmice.com
Wed Sep 19 20:49:50 UTC 2007


Hmmm... Bad. How can you have one PTR record for a mail server's  
address that matches the name used in the MX records, when each MX  
record referring to that server uses a different FQDN?

It would be better to pick one name as your main domain, and break  
out the apex records by zone. Then use $INCLUDE directives to bring  
in the rest of the zone.

Chris Buxton
Men & Mice

On Sep 19, 2007, at 1:36 PM, Ryan McCain wrote:

> To put this into context we are currently using dss.state.la.us and  
> are migrating to dss.la.gov and dss.louisiana.gov. Those are the 3  
> zones that need to stay in sync.
>
> I have changed named.conf to look like this:
>
> zone "dss.state.la.us" in {
>         file "shared/shared.zone";
>         type master;
> };
> zone "dss.la.gov" in {
>         file "shared/shared.zone";
>         type master;
> };
> zone "dss.louisiana.gov" in {
>         file "shared/shared.zone";
>         type master;
> };
>
> --SNIP--
>
> /var/lib/named/shared/shared.zone looks like this:
>
> $TTL 3600       ; 1 hour
> @               IN SOA  dssns rmccain (
>                                 2007091906        ; serial
>                                 1200        ; refresh (20 minutes)
>                                 600        ; retry (10 minutes)
>                                 1209600    ; expire (2 weeks)
>                                 3600       ; minimum (1 hour)
>                                 )
>                         NS      dssns
>                         NS      dssns2
>                         A       205.172.49.49
>                         MX      10 smtp-ext1
>                         MX      20 smtp-ext2
> acess                   A       205.172.49.23
> acess-info              A       205.172.49.23
> acspoc                  A       205.172.49.9
> b2b                     CNAME   mvs
> bankrecon               A       205.172.49.29
> chatblazer              CNAME   dss-sa9928951
>
>
> --SNIP--
>
> ..It seems to be working.  Will that not hold up?
>
>>>> On Wed, Sep 19, 2007 at  3:22 PM, in message
> <62F72AEA-3927-4B7E-87D0-FE1D0191B4B7 at menandmice.com>, Chris Buxton
> <cbuxton at menandmice.com> wrote:
>> No. This zone file is not for your main domain, and your name server
>> and mail server hostnames should fall into your main domain. For
>> example, here are some (very short) complete zone files, one for the
>> main zone and the other for all other zones:
>>
>> ____________________________
>>
>> ; $ORIGIN maindomain.
>> @	SOA	a.ns hostmaster 2007091900 1h 5m 6w 1h
>> 	NS	a.ns
>> 	NS	b.ns
>> 	MX	10  a.mx
>> 	A	192.0.2.4
>> www	A	192.0.2.4
>> a.ns	A	192.0.2.1
>> b.ns	A	192.0.2.2
>> a.mx	A	192.0.2.3
>> ____________________________
>>
>> ; share zone file, $ORIGIN value indeterminate from this point
>> @	SOA	a.ns.maindomain. hostmaster.maindomain. 2007091900 1h 5m 6w 1h
>> 	NS	a.ns.maindomain.
>> 	NS	b.ns.maindomain.
>> 	MX	10  a.mx.maindomain.
>> 	A	192.0.2.4
>> www	A	192.0.2.4
>> ____________________________
>>
>> Chris Buxton
>> Men & Mice
>>
>> On Sep 19, 2007, at 11:29 AM, Ryan McCain wrote:
>>
>>> One more thing..
>>>
>>> Wouldn't it look like this:
>>>
>>>> In shared.zone:
>>>> -----------------------------------
>>>> $TTL 1d
>>>> @	SOA	[... 7 data fields ...]
>>>> 	NS	a.ns
>>>> 	NS	b.ns
>>>> 	MX	10  a
>>>> host1	A	10.0.0.1
>>>> host2	A	10.0.0.2
>>>> -----------------------------------
>>>
>>> rather than
>>>
>>>> In shared.zone:
>>>> -----------------------------------
>>>> $TTL 1d
>>>> @	SOA	[... 7 data fields ...]
>>>> 	NS	a.ns.maindomain.
>>>> 	NS	b.ns.maindomain.
>>>> 	MX	10  a.mx.maindomain.
>>>> host1	A	10.0.0.1
>>>> host2	A	10.0.0.2
>>>> -----------------------------------
>>>
>>> thanks...
>>>
>>>
>>>>>> On Mon, Aug 27, 2007 at  3:14 PM, in message
>>> <634EB382-69D9-4DAF-9173-BDFE6F911062 at menandmice.com>, Chris Buxton
>>> <cbuxton at menandmice.com> wrote:
>>>> Either use the same zone file for all three zones, or put an  
>>>> $INCLUDE
>>>> directive into each zone pointing to a common file.
>>>>
>>>> Here is an example of using the first method, which requires  
>>>> that the
>>>> three zones be completely identical other than zone name:
>>>>
>>>> In named.conf (not the whole file):
>>>> -----------------------------------
>>>> zone "domain1.com" { type master; file "shared.zone"; };
>>>> zone "domain2.com" { type master; file "shared.zone"; };
>>>> zone "domain3.com" { type master; file "shared.zone"; };
>>>> -----------------------------------
>>>> In shared.zone:
>>>> -----------------------------------
>>>> $TTL 1d
>>>> @	SOA	[... 7 data fields ...]
>>>> 	NS	a.ns.maindomain.
>>>> 	NS	b.ns.maindomain.
>>>> 	MX	10  a.mx.maindomain.
>>>> host1	A	10.0.0.1
>>>> host2	A	10.0.0.2
>>>> -----------------------------------
>>>>
>>>> The key here is to not reference the domain name itself  
>>>> anywhere. "@"
>>>> stands in for the zone name, as specified in each zone  
>>>> statement. All
>>>> other domain names are carefully written unqualified unless they
>>>> should not change between zones.
>>>>
>>>> Whenever a change is made to the shared zone file, be sure to issue
>>>> 'rndc reload <domain>' for each of these domains, or else use 'rndc
>>>> reload' without specifying a domain argument.
>>>>
>>>> Chris Buxton
>>>> Men & Mice
>>>>
>>>> On Aug 27, 2007, at 10:45 AM, Ryan McCain wrote:
>>>>
>>>>> I have 3 zones that need to stay in sync.  For example
>>>>> host1.domain1.com needs to be the same as host1.domain2.com and
>>>>> host1.domain3.com.  What is the best way to handle this?
>>>>>
>>>>> I was thinking of writing a script to update the domain2 and
>>>>> domain3 zone files when I update the domain1 zone file but figured
>>>>> there has to be something in built into BIND that handles this as
>>>>> I'm not the only one who does this.
>>>>>
>>>>> Thanks..
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>



More information about the bind-users mailing list