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 <k...@chrysler.com
<mailto:k...@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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
