Odd response from upstream DNS servers

Adrian Beaudin Adrian.Beaudin at nominum.com
Tue Jan 6 20:31:18 UTC 2015


Hi Levi,

Are you able to use dig to make sure that the server is responding properly?

fwiw, I have seen mobile/voice equipment in the past that had oddly written dns resolvers  - some caused weird issues even with valid responses.

-a

Adrian Beaudin
Principal Architect, Special Projects
Nominum, Inc.<http://www.nominum.com>
o: +1.650.587.1513
adrian.beaudin at nominum.com


________________________________
From: bind-users-bounces at lists.isc.org [bind-users-bounces at lists.isc.org] on behalf of Levi Pederson [levipederson at mankatonetworks.net]
Sent: Tuesday, January 06, 2015 3:25 PM
To: Evan Hunt
Cc: bind-users at lists.isc.org
Subject: Re: Odd response from upstream DNS servers

Alrighty,

There could be a lot of sensitive information in the wire shark and I'm looking at how to parse that now.  Currently here is the RESPONSE.log and default.log information

RESPONSE.log
<code>
16-Dec-2014 23:11:21.417 fetch 0x7f9d85d591d0 (fctx 0x7f9d7f856010(Domain-request/NAPTR)): created
16-Dec-2014 23:11:21.417 fctx 0x7f9d7f856010(Domain-request/NAPTR'): start
16-Dec-2014 23:11:21.417 fctx 0x7f9d7f856010(Domain-request/NAPTR'): try
16-Dec-2014 23:11:21.418 fctx 0x7f9d7f856010(Domain-request/NAPTR'): cancelqueries
16-Dec-2014 23:11:21.418 fctx 0x7f9d7f856010(Domain-request/NAPTR'): getaddresses
16-Dec-2014 23:11:21.418 fctx 0x7f9d7f856010(Domain-request/NAPTR'): query
16-Dec-2014 23:11:21.418 resquery 0x7f9d7f85d010 (fctx 0x7f9d7f856010(Domain-request/NAPTR)): send
16-Dec-2014 23:11:21.418 resquery 0x7f9d7f85d010 (fctx 0x7f9d7f856010(Domain-request/NAPTR)): sent
16-Dec-2014 23:11:21.418 resquery 0x7f9d7f85d010 (fctx 0x7f9d7f856010(Domain-request/NAPTR)): udpconnected
16-Dec-2014 23:11:21.419 resquery 0x7f9d7f85d010 (fctx 0x7f9d7f856010(Domain-request/NAPTR)): senddone
16-Dec-2014 23:11:21.489 resquery 0x7f9d7f85d010 (fctx 0x7f9d7f856010(Domain-request/NAPTR)): response
;Domain-request.        IN NAPTR

UPSTREAM RESPONSES

UPSTREAM-RESPONSE 86400 IN A Correct-IP#1
UPSTREAM-RESPONSE 86400 IN A Correct-IP#2
UPSTREAM-RESPONSE 86285 IN A Correct-IP#3
16-Dec-2014 23:11:21.490 fctx 0x7f9d7f856010(Domain-request/NAPTR'): noanswer_response
16-Dec-2014 23:11:21.490 log_ns_ttl: fctx 0x7f9d7f856010: noanswer_response: Domain-request (in 'domain-name'?): 1 86285
16-Dec-2014 23:11:21.490 fctx 0x7f9d7f856010: trimming ttl of domain-name/NS for Domain-request/NAPTR: 86400 -> 86285
16-Dec-2014 23:11:21.490 DNS format error from upstreamServer#53 resolving Domain-request/NAPTR for client CLIENT-IP#15000: non-improving referral
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): cancelquery
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): add_bad
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): try
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): cancelqueries
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): getaddresses
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): no addresses
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): done
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): stopeverything
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): cancelqueries
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): sendevents
16-Dec-2014 23:11:21.492 fetch 0x7f9d85d591d0 (fctx 0x7f9d7f856010(Domain-request/NAPTR)): destroyfetch
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): shutdown
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): doshutdown
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): stopeverything
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): cancelqueries
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): unlink
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): destroy

</code>

Default.LOG

17-Dec-2014 00:07:38.205 query-errors: debug 2: fetch completed at resolver.c:3073 for domain-name/A in 0.071177: failure/success [domain:domain-name,referral:0,restart:2,qrysent:1,timeout:0,lame:0,neterr:0,badresp:1,adberr:0,findfail:0,valfail:0]


While I know the Time stamps are different the same thing happens with each request.  Now onto the wireshark parse.

Levi Pederson
Mankato Networks LLC
cell | 612.481.0769
work | 612.787.7392
levipederson at mankatonetworks.net<mailto:levipederson at mankatonetworks.net>
[http://www.mankatonetworks.com/images/mn_logo_email.png]

On Tue, Jan 6, 2015 at 1:48 PM, Evan Hunt <each at isc.org<mailto:each at isc.org>> wrote:
On Tue, Jan 06, 2015 at 01:03:10PM -0600, Levi Pederson wrote:
> However I can see the request come back to my server only to be rejected as
> FORMERR  and DNS format error badresp:1

It looks like the upstream server send a badly formatted response.  We'd be
better equipped to diagnose the problem if you told us what query you were
trying to resolve, and what version of BIND you're running.

--
Evan Hunt -- each at isc.org<mailto:each at isc.org>
Internet Systems Consortium, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150106/3c44990e/attachment-0001.html>


More information about the bind-users mailing list