System Resolver Test App?
da...@from525.com
All,
It has been a long day so please excuse me if I am over looking something trivial. I am wondering if anyone knows of an app similar to nslookup or dig that actually uses the system resolver. I spent a decent amount of time this morning trouble shooting an issue where a third invalid nameserver entry within the /etc/resolv.conf (CentOS) cause me much grief. My trusty tools nslookup & dig failed me because they worked as expected while the system resolver did not. I am basically trying to uinderstand why the system resolver was getting stuck on the third entry within the resolv.conf while it should have tried one of the first two working DNS servers first.
Thanks,
David Porsche
Barry Margolin
"da...@from525.com" <da...@from525.com> wrote:
I'm not sure if there is one, but it should be pretty easy to write a
program that calls res_query().
But it doesn't seem like this would be much help in troubleshooting,
because when it gets an error you won't be able to tell why. There's no
way for it to indicate that the error is because it was stuck on the
third server.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Stephane Bortzmeyer
da...@from525.com <da...@from525.com> wrote
> I am wondering if anyone knows of an app similar to nslookup or
> dig that actually uses the system resolver.
C source attached. Compile, for instance, with:
gcc -o resolve-name resolve-name.c
> I am basically trying to uinderstand why the system resolver was
> getting stuck on the third entry within the resolv.conf while it
> should have tried one of the first two working DNS servers first.
Not sure it will help.
Stephane Bortzmeyer
tcpdump ?
Stephane Bortzmeyer
Barry Margolin <bar...@alum.mit.edu> wrote
> I'm not sure if there is one, but it should be pretty easy to write
> a program that calls res_query().
But this calls directly the DNS. The OP wanted something which called
the system resolver, which means getaddrinfo(), not res_query().
Barry Margolin
Stephane Bortzmeyer <bortz...@nic.fr> wrote:
Considering the problem he was trying to solve, I didn't think he cared
about things like /etc/hosts, he just wants to exercise the DNS stub
resolver. If you just want to do a hostname lookup, you can use
practically any network application, e.g. ping.
And how would you use getaddrinfo() to test MX lookups, for instance?
Stephane Bortzmeyer
Barry Margolin <bar...@alum.mit.edu> wrote
> If you just want to do a hostname lookup, you can use practically
> any network application, e.g. ping.
It gives you less information than the program I posted.
1) On typical OS, ping forces you to choose explicitely IPv4 or
IPv6. In that respect, telnet is better than ping for this test.
2) You see only the first IP address, not the full list.
da...@from525.com
On Thu, 12 Nov 2009 10:01:38 +0900, Stephane Bortzmeyer <bortz...@nic.fr>
wrote:
> On Wed, Nov 11, 2009 at 05:00:03PM -0600,
> da...@from525.com <da...@from525.com> wrote
> a message of 60 lines which said:
>
>> dig that actually uses the system resolver.
>
> C source attached. Compile, for instance, with:
>
> gcc -o resolve-name resolve-name.c
>
>> getting stuck on the third entry within the resolv.conf while it
>> should have tried one of the first two working DNS servers first.
>
Stephane,
Thanks for that bit of c it works great and does just what I was hoping
for. I was able to reproduce the almost 13 second delay while looking up a
specific hostname. Funny thing is, when I perform other queries for other
hostnames the third invalid DNS server mentioned in the resolv.conf does
not seem to be a problem. When I remove the third invalid entry and
perform the same query with your application the delay is non existent. I
have captured previous tcpdumps and didn't notice anything out of the norm,
but there was alot of other network chatter. The app should let me capture
a more concise tcpdump for further examination. Is there any way you could
incorporate resolver errors being sent to stdout?
Thanks,
David Porsche
Jeremy C. Reed
da...@from525.com
On Wed, 11 Nov 2009 20:06:11 -0600, "da...@from525.com" <da...@from525.com>
wrote:
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
Thanks All,
I think between Stephane's test app and some snoop data I have a better
idea of what is going on. It seems as if the local resolver starts by
issuing ipv6 requests to the three name servers mentioned in resolv.conf.
The first two valid DNS servers (not configured for ipv6) each respond
back stating they are not authoritative for the domain in question causing
the subsequent servers to be queried. The resolver finds itself querying
the third bogus name server and has to wait for the 5 second time out. The
resolver then repeats the whole process for ipv6 adding another 5 seconds
to the delay (total of 10 now). The resolver then finally starts the whole
process again for ipv4 and gets the proper answer with the first query.
Thanks,
David Porsche
Barry Margolin
"da...@from525.com" <da...@from525.com> wrote:
> I think between Stephane's test app and some snoop data I have a better
> idea of what is going on. It seems as if the local resolver starts by
> issuing ipv6 requests to the three name servers mentioned in resolv.conf.
Do you mean that it's issuing requests using IPv6, or it's using IPv4 to
send requests for AAAA records?
> The first two valid DNS servers (not configured for ipv6) each respond
> back stating they are not authoritative for the domain in question causing
> the subsequent servers to be queried. The resolver finds itself querying
Which servers are you talking about now, the servers in resolv.conf, or
the servers for the domain you're querying? The latter should not
respond that they're not authoritative. Authority is not specific to IP
versions, it just goes by names. A server is either authoritative for
foo.com or it isn't, it can't be authoritative for foo.com's IPv4 data
but not for its IPv6 data.
> the third bogus name server and has to wait for the 5 second time out. The
> resolver then repeats the whole process for ipv6 adding another 5 seconds
> to the delay (total of 10 now). The resolver then finally starts the whole
> process again for ipv4 and gets the proper answer with the first query.
If you're not actually using IPv6, you might consider disabling it on
your system. That should stop all the unnecessary v6 lookups.
da...@from525.com
On Thu, 12 Nov 2009 01:48:02 -0500, Barry Margolin <bar...@alum.mit.edu>
wrote:
> In article <mailman.971.1257996...@lists.isc.org>,
> "da...@from525.com" <da...@from525.com> wrote:
>
>> idea of what is going on. It seems as if the local resolver starts by
>> issuing ipv6 requests to the three name servers mentioned in
resolv.conf.
>>
>
> send requests for AAAA records?
>
The latter. Using IPv4 to send requests for AAAA records.
>> The first two valid DNS servers (not configured for ipv6) each respond
>> back stating they are not authoritative for the domain in question
>> causing
>> the subsequent servers to be queried. The resolver finds itself
querying
>
> Which servers are you talking about now, the servers in resolv.conf, or
> the servers for the domain you're querying? The latter should not
> respond that they're not authoritative. Authority is not specific to IP
> versions, it just goes by names. A server is either authoritative for
> foo.com or it isn't, it can't be authoritative for foo.com's IPv4 data
> but not for its IPv6 data.
I was talking about the servers mentioned in the resolv.conf.
So here goes a second try,.....
There are (were) three servers mentioned in the resolv.conf. We can
reference them going forward as nameserver1, nameserver2 & nameserver3.
Nameserver3 is a bogus invalid IP belonging to nothing, while nameserver1 &
nameserver2 are legitimate nameservers.
Now it is important to know that the resource record that was causing issue
while attempting to query is a CNAME to another resource record. The
"other" resource record lives in DNS space that has been delegated out. In
this case it has been delegated out to a Citrix Netscaler load balancing
device. I believe the issue to actually be the fault of the Netscaler as
it seems as if it does not handle the AAAA records as it should.
When the initial query is issued to the local resolver snoop data shows
that both nameserver1 & namserver2 send a response back with an error
message of "Server failure" (when the AAAA record is requested). The error
message then triggers the loop of subsequent queries and creates the delays
until the resolver issues the query for the A record. At this point
everything works as normal. I plan to do some more tests to confirm my
theory on the Netscaler.
Please let me know if I am just talking nonsense,..............
>
>> the third bogus name server and has to wait for the 5 second time out.
>> The
>> resolver then repeats the whole process for ipv6 adding another 5
seconds
>> to the delay (total of 10 now). The resolver then finally starts the
>> whole
>> process again for ipv4 and gets the proper answer with the first query.
>
> If you're not actually using IPv6, you might consider disabling it on
> your system. That should stop all the unnecessary v6 lookups.
It is not my system. I was just brought in to help find the issue. I can
suggest this to the proper system admin.
da...@from525.com
On Thu, 12 Nov 2009 08:04:35 -0600, "da...@from525.com" <da...@from525.com>
wrote:
> On Thu, 12 Nov 2009 01:48:02 -0500, Barry Margolin <bar...@alum.mit.edu>
> wrote:
>> In article <mailman.971.1257996...@lists.isc.org>,
>> "da...@from525.com" <da...@from525.com> wrote:
>>
>>> idea of what is going on. It seems as if the local resolver starts by
>>> issuing ipv6 requests to the three name servers mentioned in
> resolv.conf.
>>>
>>
>> send requests for AAAA records?
>>
>
> The latter. Using IPv4 to send requests for AAAA records.
>
>
>>> The first two valid DNS servers (not configured for ipv6) each respond
>>> back stating they are not authoritative for the domain in question
>>> causing
>>> the subsequent servers to be queried. The resolver finds itself
> querying
>>
>>> the third bogus name server and has to wait for the 5 second time out.
>>> The
>>> resolver then repeats the whole process for ipv6 adding another 5
> seconds
>>> to the delay (total of 10 now). The resolver then finally starts the
>>> whole
>>> process again for ipv4 and gets the proper answer with the first query.
>>
>> If you're not actually using IPv6, you might consider disabling it on
>> your system. That should stop all the unnecessary v6 lookups.
>
> It is not my system. I was just brought in to help find the issue. I
can
> suggest this to the proper system admin.
All,
I have confirmed the issue with the Citrix Netscaler and AAAA records which
is documented at the link bellow. Thanks for everyone's help figuring this
out.
http://support.citrix.com/article/CTX117947
Thanks,
David Porsche
Barry Margolin
"da...@from525.com" <da...@from525.com> wrote:
That article was obviously written by someone who knows little of DNS,
and also I doubt that English is his native language. Notice this
sentence from the Engineering Analysis:
When the engineers queried the BIND LDNS server for Authentication,
Authorization, Accounting and Auditing (AAAA or quad A) record, the GSLB
NetScaler appliance returned a response with root hint records and the
bind returned the SERVFAIL response.
Do they really think that the AAAA record type is an abbreviation for
that? It's just Address Address Address Address -- IPv6 addresses are
4x the length of IPv4 addresses.
Mark Andrews
In message <barmar-BDCC7D....@news.eternal-september.org>, Barry Margolin writes:
> In article <mailman.975.1258042...@lists.isc.org>,
> and also I doubt that English is his native language. Notice this
> sentence from the Engineering Analysis:
>
> When the engineers queried the BIND LDNS server for Authentication,
> Authorization, Accounting and Auditing (AAAA or quad A) record, the GSLB
> NetScaler appliance returned a response with root hint records and the
> bind returned the SERVFAIL response.
>
> Do they really think that the AAAA record type is an abbreviation for
> that? It's just Address Address Address Address -- IPv6 addresses are
> 4x the length of IPv4 addresses.
It's obviously gone from the engineer who just used SOA and AAAA
to a publisist who looked up SOA and AAAA and just used what he
found rather than verify with the engineer that it was correct.
Mark
> --
> Barry Margolin, bar...@alum.mit.edu
> Arlington, MA
> *** PLEASE don't copy me on replies, I'll read them in the group ***
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Stephane Bortzmeyer
da...@from525.com <da...@from525.com> wrote
> Is there any way you could incorporate resolver errors being sent to
> stdout?
It does, if getaddrinfo returns an error. But getaddrinfo does not
return until is has something (an answer, or an error) so it is not a
good tool to investigate resolver internal errors (tcpdump is
certainly better nere).
That's the problem with high-level routines :-)
Stephane Bortzmeyer
da...@from525.com <da...@from525.com> wrote
> I was talking about the servers mentioned in the resolv.conf.
In that case, it is pefectly normal if the answer is not
authoritative. You put recursive name servers in resolv.conf, not
authoritative ones.
> I believe the issue to actually be the fault of the Netscaler as it
> seems as if it does not handle the AAAA records as it should.
That was common at a time. See RFC 4074 "Common Misbehavior Against
DNS Queries for IPv6 Addresses".
> The error message then triggers the loop of subsequent queries and
> creates the delays until the resolver issues the query for the A
> record.
That's not normal: getaddrinfo should try only the first name server
listed in resolv.conf, since it actually replies (even if it is with
SERVFAIL.
Agarwal Vivek-RNGB36
Iam running BIND-9.3.3 on Linux Server. I have configured match-clients in the named.conf file. I added some more IPS to this and restarted the named process. The issue is its not getting updated and the new added IPs cant resolve the dns queries.
Can anyone please help me
Thanks in advance
Regards
Vivek Aggarwal
+973-36583058
Dave Sparro
<RNG...@motorola.com> wrote:
> Iam running BIND-9.3.3 on Linux Server. I have configured match-clients in the named.conf file. I added some more IPS to
>this and restarted the named process. The issue is its not getting updated and the new added IPs cant resolve the dns queries.
> Can anyone please help me
The safe bet is "You did it wrong."
If you could include your configuration and the bits from the log file
that show what happened to the queries from the new IPs you were
trying to set up might help to give you some more specific advice.
Chris Buxton
> Hi All
>
> Iam running BIND-9.3.3 on Linux Server. I have configured match-clients in the named.conf file. I added some more IPS to this and restarted the named process. The issue is its not getting updated and the new added IPs cant resolve the dns queries.
> Can anyone please help me
If you want detailed help, please post your named.conf, what you wanted to have happen, and what's happening instead.
I don't see any mention of views in your request. Match-clients only makes sense inside a view statement.
Chris Buxton
Professional Services
Men & Mice
jim.si...@tektronix.com
Most of our internal DNS zones are mastered in Microsoft DNS (2k3 R2) as AD Integrated zones. Currently, those zones are slaved from a single MS DNS server to our BIND 9 servers that handle recursion. Is there a reliable way to use multiple masters when slaving AD Integrated zones to BIND?
In the O'Reilly book "DNS on Windows Server 2003" a section on p. 324 called "BIND Secondaries for Active Directory-Integrated Zones" says serial numbers can vary on otherwise synchronized MS DNS Servers, potentially causing a server to respond with an incorrect lower serial number.
Thanks,
Jim Sifferle
Tektronix / Fluke Network Services
Chris Buxton
Hello Jim,
The book is correct. Furthermore, if using multiple AD servers as masters, they can apply updates in different orders, so the IXFR mechanism breaks.
I believe the only way to make this work would be to use the statement "multi-master true;" inside your zone statement. My understanding is that named (the slave) will not compare versions between the two servers, essentially treating each DC's copy of the zone as separate and distinct. Thus, if it has to switch over to the second-listed master, it will request a full zone transfer rather than an IXFR.
Mark Andrews
In message <B07D01C0-86C2-45E6...@menandmice.com>, Chris Buxton
writes:
> On Nov 17, 2009, at 5:01 PM, <jim.si...@tektronix.com> <jim.sifferle@tektr
multi-master true; still assumes correct zone serial number
maintenance. It just prevents the warnings about serial number
going backwards which is a normal side effect of having multiple
masters vs a master with multiple addresses.
> Chris Buxton
> Professional Services
> Men & Mice
>
Chris Buxton
> multi-master true; still assumes correct zone serial number
> maintenance. It just prevents the warnings about serial number
> going backwards which is a normal side effect of having multiple
> masters vs a master with multiple addresses.
OK, wow. I thought it was intended to permit a DR primary master, with radically different data, to take over in the event of a failure of the main primary master.
My mistake, I guess. How would one handle switchover to a DR primary master? 'rndc retransfer' on all slaves?
Mark Andrews
In message <87CE8771-DD51-47D5...@menandmice.com>, Chris Buxton
writes:
> On Nov 17, 2009, at 8:27 PM, Mark Andrews wrote:
>
> > multi-master true; still assumes correct zone serial number
> > maintenance. It just prevents the warnings about serial number
> > going backwards which is a normal side effect of having multiple
> > masters vs a master with multiple addresses.
>
> radically different data, to take over in the event of a failure of the =
> main primary master.
>
> My mistake, I guess. How would one handle switchover to a DR primary =
> master? 'rndc retransfer' on all slaves?
As part of the process of bringing a DR site online you set the
serial to be bigger than the primary site. I suspect you would
have the DR site keeping the serial at primary + delta where delta
is big enough to swallow any changes that the primary may have made
w/o the DR site being aware. The DR site would not supply ixfr
deltas initially resulting in a full axfr to all slaves.
> Chris Buxton
> Professional Services
> Men & Mice
>
bsfi...@anl.gov
>Most of our internal DNS zones are mastered in Microsoft DNS (2k3 R2)
>as AD Integrated zones. Currently, those zones are slaved from a
>single MS DNS server to our BIND 9 servers that handle recursion. Is
>there a reliable way to use multiple masters when slaving AD Integrated
>zones to BIND?
>
>In the O'Reilly book "DNS on Windows Server 2003" a section on p. 324
>called "BIND Secondaries for Active Directory-Integrated Zones" says
>serial numbers can vary on otherwise synchronized MS DNS Servers,
>potentially causing a server to respond with an incorrect lower serial
>number.
>
>Thanks,
>
>Jim Sifferle
>Tektronix / Fluke Network Services
I have seen the replies to this mail, and I have something else to add.
See MS 282826. Assume that you have a zone that is AD-integerated,
and you have the zone on two DCs, DC1 and DC2 - both are running the
MS DNS Service. Assume that both copies of the zone are identical
and have serial number, say, 1.
Now two machines send DDNS updates for the same zone at the same time;
one sends to DC1 and one sends to DC2. After each DC has processed
the update, the DCs now have serial number 2, but the zones have
different content. Somehow (under the covers of AD), the two zones are
synchronized. I do not know the algorithm, nor do I know how much time
elapses before the synchronization. With the synchronized zone, what
is the proper serial number? It can not be 2, as there could be
another DDNS packet for the same zone sent to DC1, and this results
(before the synchronization) to DC1 having serial number 2 and DC2
having serial number 1. Article 282826 describes what the MS code does;
it depends upon what MS DNS Servers are treated as masters for BIND.
With my setup, I run only ONE MS DNS Server, even though I have four
DCs. My Windows group wants two MS DNS Servers, and I will list only]
one as the master for the zone on my BIND servers.
----------------------------------------------------------------------
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone: +1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: BSFi...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994