Doubt with towiresorted

[Kevin Darcy]

On 7/6/2011 4:36 AM, Vignesh Gadiyar wrote:
> Got your point. I meant answer sections in the Response from the DNS 
> server itself. It contains 4 sections namely Question, Answer, 
> Authoritative and Additional sections right. I used the rrset-order in 
> named.conf to set order to random which was normally Cyclic. The 
> result was that only the answer section records were getting sorted in 
> the random order and all other records were cyclic. Is this the 
> behavior if we set order to any order we want.
>
> -Vignesh.
>
> On Mon, Jul 4, 2011 at 9:38 PM, Kevin Darcy <kcd at chrysler.com 
> <mailto:kcd at chrysler.com>> wrote:
>
>     On 7/1/2011 2:40 AM, Vignesh Gadiyar wrote:
>>     I have created a static zone file for "www.abcd.com
>>     <http://www.abcd.com>" with the Answer section entries 
>
>     Hold it right there. A zone file doesn't contain "answer
>     sections", it contains zone data. That's an important, fundamental
>     distinction. "Answer sections" sometimes form part of "responses",
>     which are produced through the name-resolution process/algorithm,
>     and then rendered in "wire format" for passing back to the client.
>     Hopefully you understand both the differences and
>     interrelationship of a nameserver's "private" data structures and
>     data storage mechanisms, on the one hand, and, on the other hand,
>     the standards-defined network protocol for sending bits and bytes
>     of data between the server and the client. Any given RRset is
>     going to be formatted differently, depending on whether it's in
>     text form in a zone file (defined by standard), held in binary
>     form in some sort of organized data structure in volatile memory
>     while named is running (proprietary to BIND), or "on the wire"
>     being passed between a nameserver and one of its clients (also
>     defined by standard).
>
>
>>     containing 2 IP addresses like 1.1.1.1 and 2.2.2.2. I tried to
>>     print these addresses in the towiresorted function for the random
>>     order like ->
>>
>>     for(i=0;i<count;i++)
>>     {
>>                     char adstr[40];
>>                     isc_uint32_t ip_host=(*(isc_uint32_t
>>     *)sorted[i].rdata->data);
>>                     inet_ntop(AF_INET,&(ip_host),adstr,adstr,40);
>>                     printf("%s  \n",adstr);
>>     }
>>
>>
>>     thinking that rdata->data contains the IP addresses of the answer
>>     section. But i am getting different IP addresses when i'm running
>>     named and using dig www.abcd.com <http://www.abcd.com>. Some help
>>     as to what exactly stores the IPs contained in the Answer section
>>     would be really great.
>     towiresorted() is just an internal BIND conversion function, and
>     the product of towiresorted() would *not* be suitable, I don't
>     think, for feeding directly to inet_ntop(), since inet_ntop()
>     won't be able to handle DNS-style label compression (it doesn't
>     have the whole context of the response packet, so how could it?).
>
>     What exactly are you trying to do here?
>
>     If you just want a program to read a text file containing IP
>     addresses and then spit them out in random order, then that's not
>     even DNS-related and you don't need BIND libraries for that. Heck,
>     you could just use the "sort" command.
>
>     If you're trying to query some particular DNS name and then
>     present the results in random order, then I think the modern
>     algorithm -- although I haven't done any network programming in C
>     for years now -- would be to call getaddrinfo(), which will return
>     a linked list of addrinfo structures. Parse through that linked
>     list and randomize to your heart's content. Please understand,
>     however, that the vast majority of DNS resolver implementations
>     will *already* randomize the results (with a notable exception
>     being Windows' default, but de-configurable behavior of "subnet
>     prioritization"), so re-randomizing in a client program may be
>     wasted effort.
>
I don't believe rrset-order or sortlist act on any records other than 
the ones in the Answer Section. There really isn't any reason to sort 
records in any other section of the response, because those records are 
almost always chosen according to some defined algorithm: if they are NS 
records, or address records associated with NS records, then they are 
selected based on historical RTT observations/calculations (if 
available, otherwise random, and then RTTs histories are built up over 
time); if they are Additional Section address records related to the 
targets of MX or SRV records in the Answer Section, then any desired 
ordering can be implemented by the domain owner via distinct Answer 
Section records using "preference" as defined in the respective 
specification of the MX or SRV record type.

Of course, if QNAME happens to match a CNAME, then address records 
associated with the target of that CNAME may appear in the response, but 
they'll be in the Answer Section, so rrset-order/sortlist would apply.

Offhand, I can't imagine what other record type - besides the ones I've 
already mentioned above -- might result in address records appearing in 
a non-Answer Section of the response. PTR records, although they contain 
FQDNs in their RDATA, explicitly *don't* trigger Additional-Section 
processing, for instance. Do you have some particular record type in mind?

On the other side, there is plenty of reason to *not* sort records in 
any other section besides Answer Section. Simply put, such sorting would 
consume processing and/or memory resources, for no discernible benefit.

                                                                         
                                                                         
                                                                         
                             - Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110706/fb0d9741/attachment.html>