Re: about AUTHORITY SECTION

[Torinthiel]

On 07/07/11 04:56, pa...@laposte.net wrote:
> 
> Hello,
> 
> I got two different forms of AUTHORITY SECTION from the dig, for example,
> 
> $ dig mydots.net @ns7.dnsbed.com 
> 
> ; <<>> DiG 9.4.2-P2.1 <<>> mydots.net @ns7.dnsbed.com
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36520
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
> 
> ;; QUESTION SECTION:
> ;mydots.net. IN A
> 
> ;; AUTHORITY SECTION:
> mydots.net. 3600 IN SOA ns7.dnsbed.com. support.dnsbed.com. 6 10800 3600 
> 604800 3600

This one means that there's no such record. Your answer is empty. See,
you don't have answer section and RFCs state that authorative
nameservers should send SOA record in authority section if there's no data.

> 
> ;; Query time: 90 msec
> ;; SERVER: 58.22.107.162#53(58.22.107.162)
> ;; WHEN: Thu Jul 7 09:54:07 2011
> ;; MSG SIZE rcvd: 86
> 
> 
> 
> $ dig www.mydots.net @ns7.dnsbed.com
> 
> ; <<>> DiG 9.4.2-P2.1 <<>> www.mydots.net @ns7.dnsbed.com
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3327
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
> 
> ;; QUESTION SECTION:
> ;www.mydots.net. IN A
> 
> ;; ANSWER SECTION:
> www.mydots.net. 900 IN A 61.144.56.101
> 
> ;; AUTHORITY SECTION:
> mydots.net. 3600 IN NS ns7.dnsbed.com.
> mydots.net. 3600 IN NS ns8.dnsbed.com.


And this one has correct answer, and the NS records are there just in
case - to notify you that you got your answer from authorative ns and
what other authorative ns'es are.
Torinthiel



signature.asc
Description: OpenPGP digital signature
___
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

Re: "Key : Delaying activation to match the DNSKEY TTL."

[Evan Hunt]

> Hmm, thanks for the explanation. However, for this case, while the
> activation date was in the near future, the *publish* date was far in
> the past.

Apparently it thought this was the first time it was being published,
anyway.  That information doesn't come from the publication date but
from before-and-after comparison of the DNSKEY RRset.

If this message came from dnssec-signzone, I guess maybe you were
signing the raw zone, rather than re-signing a zone that was already
signed?

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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

about AUTHORITY SECTION

[pangj]

Hello,

I got two different forms of AUTHORITY SECTION from the dig, for example,

$ dig mydots.net @ns7.dnsbed.com 

; <<>> DiG 9.4.2-P2.1 <<>> mydots.net @ns7.dnsbed.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36520
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;mydots.net. IN A

;; AUTHORITY SECTION:
mydots.net. 3600 IN SOA ns7.dnsbed.com. support.dnsbed.com. 6 10800 3600 604800 
3600

;; Query time: 90 msec
;; SERVER: 58.22.107.162#53(58.22.107.162)
;; WHEN: Thu Jul 7 09:54:07 2011
;; MSG SIZE rcvd: 86



$ dig www.mydots.net @ns7.dnsbed.com

; <<>> DiG 9.4.2-P2.1 <<>> www.mydots.net @ns7.dnsbed.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3327
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.mydots.net. IN A

;; ANSWER SECTION:
www.mydots.net. 900 IN A 61.144.56.101

;; AUTHORITY SECTION:
mydots.net. 3600 IN NS ns7.dnsbed.com.
mydots.net. 3600 IN NS ns8.dnsbed.com.

;; Query time: 90 msec
;; SERVER: 58.22.107.162#53(58.22.107.162)
;; WHEN: Thu Jul 7 09:54:20 2011
;; MSG SIZE rcvd: 94



what does the two forms of AUTHORITY SECTION mean?

Thanks.

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net
___
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

Re: "Key : Delaying activation to match the DNSKEY TTL."

[Paul B. Henson]

On Tue, Jul 05, 2011 at 07:34:22PM -0700, Evan Hunt wrote:
 
> The key is being published now, and its activation date (i.e., when it
> will start to be used to sign records) is in the near future: less than
> the TTL of the DNSKEY record from now.
> 
> When the key starts signing, then someone could get an RRSIG generated by
> that key... but, if that same someone had a cached copy of the DNSKEY
> record from *before* the key was published, then validation could fail.
> 
> So, what it's telling you is that named won't start signing records with
> this key until after the old DNSKEY record is guaranteed to have expired
> out of all the resolver caches.

Hmm, thanks for the explanation. However, for this case, while the
activation date was in the near future, the *publish* date was far in
the past.

Per the log output from my update script (which runs dnssec-signzone
behind the scenes):

Jun 30 17:07:26 dns_update[8373]: warning: Key
csupomona.edu/RSASHA256/17755: Delaying activation to match the DNSKEY
TTL. (sign_zone)
Jun 30 17:07:26 dns_update[8373]: warning: Key
csupomona.edu/RSASHA256/1161: Delaying activation to match the DNSKEY
TTL. (sign_zone)

And the corresponding key timing info:

$ dnssec-settime -p all Kcsupomona.edu.+008+17755.key 
Created: Thu Jul  8 19:05:30 2010
Publish: Thu Jul  8 19:05:30 2010
Activate: Fri Jul  1 00:00:00 2011
Revoke: UNSET
Inactive: Sun Jul  1 00:00:00 2012
Delete: Tue Jul  3 00:00:00 2012

$ dnssec-settime -p all Kcsupomona.edu.+008+01161.key 
Created: Wed Jun  1 00:02:02 2011
Publish: Wed Jun  1 00:02:02 2011
Activate: Fri Jul  1 00:00:00 2011
Revoke: UNSET
Inactive: Mon Aug  1 00:00:00 2011
Delete: Wed Aug  3 00:00:00 2011

I was rolling both the ZSK and my KSK, the first should have been
published for the last month, the second for the last year?

Wait, how does dnssec-signzone know whether or not a key has been
published or not? I could have created a key 10 seconds ago and set a
publication date of last year, and what would distingish that from a key
actually created and published last year?


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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

Re: 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 > wrote:


On 7/1/2011 2:40 AM, Vignesh Gadiyar wrote:

I have created a static zone file for "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;idata);
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 . 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 the

Re: update bind

[Evan Hunt]

> Can I upgrade our existing version 9.5 to 9.8 directly or do I have to do
> multiple updates.

You should have no trouble with a direct update, but if you want to be
cautious, get 9.8.0-P4, build it but don't install it, and from within
the build tree, run "bin/check/named-checkconf -z" on your existing
configuration.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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

Re: update bind

[Eivind Olsen]

saravanan subramani wrote:

> Can I upgrade our existing version 9.5 to 9.8 directly or do I have to do
> multiple updates.

You shouldn't need to do intermediate / multiple updates, no. You might
need to go quickly over your named.conf, zonefiles etc., to make sure they
still work with the new version - just in case (I don't know your setup,
whether you use anything "odd" like the DLZ and so on).

Regards
Eivind Olsen


___
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

update bind

[saravanan subramani]

Hi,

Can I upgrade our existing version 9.5 to 9.8 directly or do I have to do
multiple updates.


Thanks
___
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

Re: named web statistics

[King, Harold Clyde (Hal)]

Thanks!

-- 
Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Systems: Business Information Systems

The University of Tennessee
135D Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone: 974-1599





On 7/6/11 11:15 AM, "Jeremy C. Reed"  wrote:

>On Wed, 6 Jul 2011, King, Harold Clyde (Hal) wrote:
>
>> I know there is a web front end to DNS stats, but I can not remember the
>> option in the named.conf that defines the port.
>> I'm running 9.8.0-P4 (just now being able to upgrade to a version that
>> supports the statistics)
>
>statistics-channels  has optional "port"
>


___
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

Re: named web statistics

[Jeremy C. Reed]

On Wed, 6 Jul 2011, King, Harold Clyde (Hal) wrote:

> I know there is a web front end to DNS stats, but I can not remember the
> option in the named.conf that defines the port.
> I'm running 9.8.0-P4 (just now being able to upgrade to a version that
> supports the statistics)

statistics-channels  has optional "port"
___
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

named web statistics

[King, Harold Clyde (Hal)]

Hi;
I know there is a web front end to DNS stats, but I can not remember the option 
in the named.conf that defines the port.
I'm running 9.8.0-P4 (just now being able to upgrade to a version that supports 
the statistics)

Does anyone remember this?
--
Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Systems: Business Information Systems

The University of Tennessee
135D Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
___
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

Re: a death loop with DNS query

[Stephane Bortzmeyer]

On Wed, Jul 06, 2011 at 08:23:45AM -0500,
 Lyle Giese  wrote 
 a message of 56 lines which said:

> That is not a loop at all.  

I disagree. As dig clearly says, there is an horizontal referral: the
name servers are supposed to be authoritative for blogchina.org and
mytest.blogchina.org but keep sending back the delegation (and with AA
set).

% dig @112.90.143.36 s1.mytest.blogchina.org

; <<>> DiG 9.7.1 <<>> @112.90.143.36 s1.mytest.blogchina.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56637
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;s1.mytest.blogchina.org.   IN  A

;; AUTHORITY SECTION:
mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.

> However at least from here and it appears from where you are doing
> the querys, these name servers are not responding. 

Wrong. They do reply but incorrectly.
___
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

Re: a death loop with DNS query

[Lyle Giese]

On 7/6/2011 5:52 AM, Feng He wrote:

When I dig this:

dig s1.mytest.blogchina.org +trace

I got many these info:

mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 95 bytes from 183.60.59.217#53(ns1.dnsv5.com) in 6 ms

mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 95 bytes from 112.90.143.36#53(ns1.dnsv5.com) in 116 ms

mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 95 bytes from 180.153.162.153#53(ns2.dnsv5.com) in 27 ms

mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 95 bytes from 221.130.12.61#53(ns2.dnsv5.com) in 165 ms

mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 95 bytes from 122.225.217.194#53(ns2.dnsv5.com) in 24 ms

mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.



What does this death loop mean? How it happened?

Thanks.


That is not a loop at all.  If you do an A record query for 
ns1.dnsv5.com and ns2.dnsv5.com, you get four A records returned each.


However at least from here and it appears from where you are doing the 
querys, these name servers are not responding.  So Dig is just trying 
all A records returned.


Lyle Giese
LCR Computer Services, Inc.
___
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

a death loop with DNS query

[Feng He]

When I dig this:

dig s1.mytest.blogchina.org +trace

I got many these info:

mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 95 bytes from 183.60.59.217#53(ns1.dnsv5.com) in 6 ms

mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 95 bytes from 112.90.143.36#53(ns1.dnsv5.com) in 116 ms

mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 95 bytes from 180.153.162.153#53(ns2.dnsv5.com) in 27 ms

mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 95 bytes from 221.130.12.61#53(ns2.dnsv5.com) in 165 ms

mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 95 bytes from 122.225.217.194#53(ns2.dnsv5.com) in 24 ms

mytest.blogchina.org.   600 IN  NS  ns1.dnsv5.com.
mytest.blogchina.org.   600 IN  NS  ns2.dnsv5.com.



What does this death loop mean? How it happened?

Thanks.
___
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

Re: Doubt with towiresorted

[Vignesh Gadiyar]

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  wrote:

> **
> On 7/1/2011 2:40 AM, Vignesh Gadiyar wrote:
>
> I have created a static zone file for "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 {
> 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. 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.
>
>
> - 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
>



-- 
ƃɔʌ
___
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