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.beau...@nominum.com ________________________________ From: bind-users-boun...@lists.isc.org [bind-users-boun...@lists.isc.org] on behalf of Levi Pederson [levipeder...@mankatonetworks.net] Sent: Tuesday, January 06, 2015 3:25 PM To: Evan Hunt Cc: bind-users@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 levipeder...@mankatonetworks.net<mailto:levipeder...@mankatonetworks.net> [http://www.mankatonetworks.com/images/mn_logo_email.png] On Tue, Jan 6, 2015 at 1:48 PM, Evan Hunt <e...@isc.org<mailto:e...@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 -- e...@isc.org<mailto: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