Re: Odd response from upstream DNS servers
All, I understand this would be easier if it were not obfuscated. But alas that is not something that can be done. Thank you to all who have responded. A lot of the information I'm receiving is indicating something on the authority level. Who has it, Who is supposed to have it, and the like. I'm going to continue in that skein until I have found an answer. case closed : Thank you to all for your help and additions and your time. Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipeder...@mankatonetworks.net On Tue, Jan 6, 2015 at 4:44 PM, Evan Hunt wrote: > This would really be a lot easier if it were not anonymized. However... > > On Tue, Jan 06, 2015 at 02:43:30PM -0600, Levi Pederson wrote: > > Packet 840 Upstream-NS ---> Local-NS > [...] > > Frame 840: 245 bytes on wire (1960 bits), 245 bytes captured (1960 bits) > [...] > > .0.. = Authoritative: Server is not an authority > for > > domain > > Bad delegation, I guess. The "authoritative" server says it isn't. > > -- > 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: Odd response from upstream DNS servers
00:50:56:a0:18:f3), Dst: Cisco_b9:31:c0 (1c:e6:c7:b9:31:c0) Internet Protocol Version 4, Src: LOCAL-DNS-SERVER (LOCAL-DNS-SERVER), Dst: CLIENT (CLIENT) User Datagram Protocol, Src Port: domain (53), Dst Port: hydap (15000) Domain Name System (response) [Request In: 3379] [Time: -271.132014000 seconds] Transaction ID: 0x0479 Flags: 0x8182 Standard query response, Server failure 1... = Response: Message is a response .000 0... = Opcode: Standard query (0) .0.. = Authoritative: Server is not an authority for domain ..0. = Truncated: Message is not truncated ...1 = Recursion desired: Do query recursively 1... = Recursion available: Server can do recursive queries .0.. = Z: reserved (0) ..0. = Answer authenticated: Answer/authority portion was not authenticated by the server ...0 = Non-authenticated data: Unacceptable 0010 = Reply code: Server failure (2) Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries DOMAIN-NAME-REQUEST: type NAPTR, class IN Any and all help would be appreciated Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipeder...@mankatonetworks.net On Tue, Jan 6, 2015 at 2:31 PM, Adrian Beaudin wrote: > 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 > > 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
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 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 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 On Tue, Jan 6, 2015 at 1:48 PM, Evan Hunt 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 > 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: Odd response from upstream DNS servers
I'll see about getting that information colluded and sent. Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipeder...@mankatonetworks.net On Tue, Jan 6, 2015 at 1:56 PM, Warren Kumari wrote: > On Tue, Jan 6, 2015 at 2:48 PM, Evan Hunt 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. > > ... and if you send the "have wire sharked and can see the response > packet come back to my servers outside interface and the rejection" > bit. > > W > > > > > -- > > 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 > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. >---maf > ___ 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
Odd response from upstream DNS servers
All, I have an ODD issue with a request to an upstream DNS server 1. I receive the Downstream request and can't fill it locally so I send request up to upstream server 2. Upstream receives it and does it's thing and sends back a response with the proper servers for the client to query (this response goes back to my DNS server) 3. I'm then supposed to send that response back to the client to use for requests However I can see the request come back to my server only to be rejected as FORMERR and DNS format error badresp:1 Can anyone help me understand where the error in this issue exists? I have wire sharked and can see the response packet come back to my servers outside interface and the rejection Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipeder...@mankatonetworks.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
FORMERR on packet received from Forwarder
All, I'm in an odd situation. I have an authoritative DNS server that is supposed to forward any unknowns to a specific upstream server. These requests seem to process just fine till the response packet gets back to the system. Here is the resolver.log output specifics omitted. 16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): cancelquery 16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): add_bad 16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): try 16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): cancelqueries 16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): getaddresses 16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): no addresses 16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): done 16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): stopeverything 16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): cancelqueries 16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): sendevents 16-Jun-2014 09:53:54.003 fetch 0x7f92383471b0 (fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR)): destroyfetch 16-Jun-2014 09:53:54.003 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): shutdown 16-Jun-2014 09:53:54.003 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): doshutdown 16-Jun-2014 09:53:54.003 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): stopeverything 16-Jun-2014 09:53:54.003 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): cancelqueries 16-Jun-2014 09:53:54.003 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): unlink 16-Jun-2014 09:53:54.003 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): destroy 16-Jun-2014 09:53:59.611 createfetch: QUERIED-HOSTNAME NAPTR 16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): create 16-Jun-2014 09:53:59.611 log_ns_ttl: fctx 0x7f92321d1010: fctx_create: QUERIED-HOSTNAME (in 'HOSTNAME'?): 1 85178 16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): join 16-Jun-2014 09:53:59.611 fetch 0x7f92383471b0 (fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR)): created 16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): start 16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): try 16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): cancelqueries 16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): getaddresses 16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): query 16-Jun-2014 09:53:59.611 resquery 0x7f92321d8010 (fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR)): send 16-Jun-2014 09:53:59.612 resquery 0x7f92321d8010 (fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR)): sent 16-Jun-2014 09:53:59.612 resquery 0x7f92321d8010 (fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR)): udpconnected 16-Jun-2014 09:53:59.612 resquery 0x7f92321d8010 (fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR)): senddone 16-Jun-2014 09:53:59.683 resquery 0x7f92321d8010 (fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR)): response 16-Jun-2014 09:53:59.683 received packet: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45393 ;; flags: qr rd; QUESTION: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;QUERIED-HOSTNAME.IN NAPTR ;; AUTHORITY SECTION: CORRECT-UPSTREAMREAPONSE 86400 IN NS CORRECT-UPSTREAMREAPONSE CORRECT-UPSTREAMREAPONSE 86400 IN NS CORRECT-UPSTREAMREAPONSE ;; ADDITIONAL SECTION: CORRECT-UPSTREAMREAPONSE 86400 IN A CORRECT-Resolved-IP CORRECT-UPSTREAMREAPONSE 86400 IN A CORRECT-Resolved-IP 16-Jun-2014 09:53:59.683 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): noanswer_response 16-Jun-2014 09:53:59.683 log_ns_ttl: fctx 0x7f92321d1010: noanswer_response: QUERIED-HOSTNAME (in 'HOSTNAME'?): 1 85178 16-Jun-2014 09:53:59.683 fctx 0x7f92321d1010: trimming ttl of HOSTNAME/NS for QUERIED-HOSTNAME/NAPTR: 86400 -> 85178 16-Jun-2014 09:53:59.683 DNS format error from 65.119.117.13#53 resolving QUERIED-HOSTNAME/NAPTR for client 66.171.30.193#15000: non-improving referral 16-Jun-2014 09:53:59.683 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): cancelquery 16-Jun-2014 09:53:59.683 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): add_bad 16-Jun-2014 09:53:59.683 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): try 16-Jun-2014 09:53:59.683 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): query The big thing to NOTE is we're recieving the UPSTREAM packet back with the correct information! But alas our system says there is a formatting error. Does anyone have a quick response to this odd issue? Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 61
