Zone Record Order

Kevin Darcy kcd at daimlerchrysler.com
Fri Oct 6 20:13:50 UTC 2006


An RRset is a group of RRs all having the same owner name, class and 
type. example.com/IN/MX, for example, defines a unique RRset. 
example.com/IN, on the other hand, defines only a *name*, and there 
could be multiple RRsets owned by that name (A, MX, NS, SOA, etc.)

I hope you understand that a zone transfer is not a *file* transfer, so 
the fact that the file format -- including the record order -- may look 
different between the master and slave is completely irrelevant, as long 
as the *data* (including the TTL values of the records) is the same.

Also, I question why your mail-related records (MX record and associated 
A record) have a 15-minute TTL at all. Do you have some sort of failover 
mechanism in place and want to be able to switch those records quickly 
to point to some other mail server(s)? The proper way to do that is have 
multiple MX records at different preference values. Then the failover is 
automatic and you wouldn't have to thrash your DNS and everyone else's 
DNS with a 15-minute TTL value. Just a suggestion.

                                                                         
                                 - Kevin

Josh Hyles wrote:
> I am not sure what RRSet is, but the slave server does seem to
> re-order the record, howerver, the master which i edit, does not
> change at all. is that still ok?
>
> On 10/6/06, Josh Hyles <josh.maillists at gmail.com> wrote:
>   
>> Good point...
>>
>> One other question.. do I need the "IN" option when doing these? I'm
>> not sure what it is for, but I've been able to get things working for
>> the last years with no problem without it.
>>
>> Josh
>>
>> On 10/6/06, Chris Buxton <cbuxton at menandmice.com> wrote:
>>     
>>> There's nothing wrong with putting the two records at the end - other
>>> than having the SOA record first, the order of records in a zone is
>>> usually unimportant. (If you disable RRSet reordering, then order of
>>> records in an RRSet becomes important.)
>>>
>>> Is there a reason not to simply specify a TTL in the two records?
>>> Like this:
>>>
>>> @       900     MX      5  mail.cvlsoft.net.
>>> mail    900     A       12.45.64.7
>>>
>>> Chris Buxton
>>> Men & Mice
>>> Take control of your network
>>>
>>> On Oct 6, 2006, at 11:21 AM, Josh Hyles wrote:
>>>
>>>       
>>>> Sent this out as the wrong subject line, sorry.
>>>>
>>>> On 10/6/06, Josh Hyles <josh.maillists at gmail.com> wrote:
>>>>         
>>>>> Here is my record....
>>>>>
>>>>> $TTL 86400      ; 1 day
>>>>> @                       IN  SOA ns1.goatinatree.com.
>>>>> root.cvlsoft.net. (
>>>>>                                 2006100605   ; serial number
>>>>>                                 3600         ; refresh
>>>>>                                 7200         ; retry
>>>>>                                 604800       ; expire
>>>>>                                 86400      ) ; default TTL
>>>>>
>>>>> ;
>>>>> ;  Zone NS records
>>>>> ;
>>>>>
>>>>> @                       NS      ns1.goatinatree.com.
>>>>> @                       NS      ns2.goatinatree.com.
>>>>>
>>>>> ;
>>>>> ;  Zone records
>>>>> ;
>>>>>
>>>>> @                       TXT     "v=spf1 a mx ip4:12.45.64.8 ~all"
>>>>> @                       A       63.247.73.122
>>>>> ftp                     A       63.247.73.122
>>>>> www                     A       63.247.73.122
>>>>> sqlsrv                  A       216.180.229.66
>>>>> websrv                  A       216.180.229.67
>>>>> $TTL 900        ; 15 minutes
>>>>> @                       MX      5       mail.cvlsoft.net.
>>>>> mail                    A       12.45.64.7
>>>>>
>>>>> #####################################################
>>>>>
>>>>>
>>>>> I am writing today because I'm trying to see if there is anything
>>>>> wrong with putting the MX record at the bottom like I did in order to
>>>>> only have 1 section for 15 minute TTL.
>>>>>
>>>>> Any help would be much appreciated
>>>>>
>>>>> Josh
>>>>>
>>>>>           
>>>>
>>>>         
>>>       
>
>
>
>
>
>   



More information about the bind-users mailing list