a death loop with DNS query
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: a death loop with DNS query
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
Re: a death loop with DNS query
On Wed, Jul 06, 2011 at 08:23:45AM -0500, Lyle Giese l...@lcrcomputer.net 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
named web statistics
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.edumailto: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: named web statistics
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
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 jr...@isc.org 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: update bind
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
Re: update bind
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: Doubt with towiresorted
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;icount;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
Re: Key foo: Delaying activation to match the DNSKEY TTL.
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
about AUTHORITY SECTION
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 foo: Delaying activation to match the DNSKEY TTL.
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
