Best way to handle multiple zones

Ryan McCain Ryan.McCain at dss.state.la.us
Wed Sep 19 21:11:15 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?

Thats a great point that I didn't take into account.

> 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.

When you say pick one name as my main domain, do you mean just use one of the three as the main?  It doesn't really matter which I use, just one needs to be the "main".

Also, what do you mean by 'break out the apex records by zone'?  I find nothing on apex records.

Ryan
  
>>> On Wed, Sep 19, 2007 at  3:49 PM, in message
<7ABA21A4-75A8-41DC-BDDD-55F87D7D38A1 at menandmice.com>, Chris Buxton
<cbuxton at menandmice.com> wrote: 
> 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