<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 7/6/2011 4:36 AM, Vignesh Gadiyar wrote:
<blockquote
cite="mid:CALn8B2iUUGN=XhXBVk3T17W+_UwV+j42tV6vJAOvAXmNyn4xNA@mail.gmail.com"
type="cite">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.
<div>
<br>
</div>
<div>-Vignesh.<br>
<br>
<div class="gmail_quote">On Mon, Jul 4, 2011 at 9:38 PM, Kevin
Darcy <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:kcd@chrysler.com">kcd@chrysler.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff">
<div class="im"> On 7/1/2011 2:40 AM, Vignesh Gadiyar
wrote:
<blockquote type="cite">I have created a static zone
file for "<a moz-do-not-send="true"
href="http://www.abcd.com" target="_blank">www.abcd.com</a>"
with the Answer section entries </blockquote>
<br>
</div>
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).
<div class="im"><br>
<br>
<blockquote type="cite">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
->
<div><br>
</div>
<div>for(i=0;i<count;i++)</div>
<div>{<br>
char adstr[40];</div>
<div> isc_uint32_t
ip_host=(*(isc_uint32_t *)sorted[i].rdata->data);</div>
<div>
inet_ntop(AF_INET,&(ip_host),adstr,adstr,40);</div>
<div> printf("%s \n",adstr);</div>
<div>}</div>
<div><br>
</div>
<div><br>
</div>
<div>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 <a moz-do-not-send="true"
href="http://www.abcd.com" target="_blank">www.abcd.com</a>.
Some help as to what exactly stores the IPs
contained in the Answer section would be really
great.</div>
</blockquote>
</div>
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?).<br>
<br>
What exactly are you trying to do here?<br>
<br>
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.<br>
<br>
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.<br>
<br>
</div>
</blockquote>
</div>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
- Kevin<br>
</body>
</html>