Best way to handle multiple zones

Ryan McCain Ryan.McCain at dss.state.la.us
Thu Sep 20 17:20:52 UTC 2007


I started to implement this and got to a point that stopped  me.

Lets say my /etc/named.conf looks like this:

zone "dss.state.la.us" in {
        file "include/dss.state.la.us";
        type master;
};

... and my include/dss.state.la.us looks like this:


$TTL 3601       ; 1 hour
@               IN SOA  dssns rmccain.dss.state.la.us. (
                                2007092003
                                1200        ; refresh (20 minutes)
                                600        ; retry (10 minutes)
                                1209600    ; expire (2 weeks)
                                3600       ; minimum (1 hour)
                                )
                        NS      dssns
                        NS      dssns2
                        MX      10 smtp-ext1
                        MX      20 smtp-ext2
$INCLUDE include/shared.zone

How will BIND know that the DNS records in include/shared.zone should resolve to dss.state.la.us, dss.louisiana.gov and dss.la.gov?

I understand that BIND will know all records in include/dss.state.la.us resolve to the domain dss.state.la.us because it is identified that way in named.conf.  However, how does BIND know to resolve the DNS records in the shared.zone to dss.la.gov and dss.louisiana.gov?

What am I overlooking?

>>> On Wed, Sep 19, 2007 at  5:50 PM, in message
<3B7ED8B5-AB2F-44F6-8B31-78F9BCAB6BF9 at menandmice.com>, Chris Buxton
<cbuxton at menandmice.com> wrote: 
> It's not so much a matter of confusion, and it's not going to affect  
> your services directly. Rather, a PTR record check is often performed  
> by another mail server when deciding whether they like you enough to  
> either accept your mail or deliver mail to you. (The former is more  
> common.)
> 
> If that PTR record doesn't match your MX record name, there's a  
> chance they won't like you. (It's uncommon for a mail server's logic  
> to compare the PTR record and MX record, but it has been known to  
> happen.)
> 
> As for name servers, it's really just a matter of tradition and  
> aesthetics. I personally would have just one name for the DNS service  
> on a box, rather than variously calling it "dssns.dss.la.gov",  
> "dssns.dss.louisiana.gov", and "dssns.dss.state.la.us". But there's  
> no real reason you couldn't.
> 
> Chris Buxton
> Men & Mice
> 
> On Sep 19, 2007, at 3:02 PM, Ryan McCain wrote:
> 
>> So, the MX records have to be hard-coded to one of the 3 domains  
>> because the application will get confused otherwise? While records  
>> for static web servers can be in the $INCLUDE file because it  
>> doesn't rely on on the PTR records in most cases?  Essentially,  
>> only records that will be affected by touchy PTR records need to be  
>> in the master and hard-coded to one of the 3 domains which will be  
>> our master/main domain?
>>
>> Ryan
>>
>>
>>>>> On Wed, Sep 19, 2007 at  4:27 PM, in message
>> <84C3F5EE-D9E9-41E5-BAAC-0825AD6CCC79 at menandmice.com>, Chris Buxton
>> <cbuxton at menandmice.com> wrote:
>>> On Sep 19, 2007, at 2:11 PM, Ryan McCain 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?
>>>>
>>>> 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".
>>>
>>> Right, exactly.
>>>
>>>> Also, what do you mean by 'break out the apex records by zone'?  I
>>>> find nothing on apex records.
>>>
>>> The apex of a zone is the node at the top of its tree structure. In
>>> other words, the apex is the name of the zone's SOA record, but is
>>> not limited to just the SOA record. In your example, this is the  
>>> apex:
>>>
>>> @               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
>>>
>>> You don't have to put the entire apex into the different zone files -
>>> you could certainly move the A record for the web server into the
>>> $INCLUDE'd file. You would also, of course, put the definitions of
>>> the 4 servers shown above into the starting point file for the "main"
>>> zone.
>>>
>>> Chris Buxton
>>> Men & Mice
>>>
>>>>>>> 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