Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Odd response from upstream DNS servers
228 views
Skip to first unread message
Levi Pederson
Jan 6, 2015, 2:03:16 PM1/6/15
to bind-...@lists.isc.org
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,
Evan Hunt
Jan 6, 2015, 2:48:16 PM1/6/15
to Levi Pederson, bind-...@lists.isc.org
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
> However I can see the request come back to my server only to be rejected as
> FORMERR and DNS format error badresp:1
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 -- ea...@isc.org
Internet Systems Consortium, Inc.
Warren Kumari
Jan 6, 2015, 2:56:27 PM1/6/15
to Evan Hunt, bind-...@lists.isc.org
On Tue, Jan 6, 2015 at 2:48 PM, Evan Hunt <ea...@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.
... and if you send the "have wire sharked and can see the response
> 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.
packet come back to my servers outside interface and the rejection"
bit.
W
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@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
Levi Pederson
Jan 6, 2015, 3:01:18 PM1/6/15
to Warren Kumari, bind-...@lists.isc.org
I'll see about getting that information colluded and sent.
Thank you,
Levi Pederson
Jan 6, 2015, 3:25:21 PM1/6/15
to Evan Hunt, bind-...@lists.isc.org
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.
On Tue, Jan 6, 2015 at 1:48 PM, Evan Hunt <ea...@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.
Adrian Beaudin
Jan 6, 2015, 3:31:25 PM1/6/15
to Levi Pederson, bind-...@lists.isc.org
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
From: bind-user...@lists.isc.org [bind-user...@lists.isc.org] on behalf of Levi Pederson [levipe...@mankatonetworks.net]
Sent: Tuesday, January 06, 2015 3:25 PM
To: Evan Hunt
Cc: bind-...@lists.isc.org
Subject: Re: Odd response from upstream DNS servers
Sent: Tuesday, January 06, 2015 3:25 PM
To: Evan Hunt
Cc: bind-...@lists.isc.org
Subject: Re: Odd response from upstream DNS servers
Levi Pederson
Jan 6, 2015, 3:43:38 PM1/6/15
to Adrian Beaudin, bind-...@lists.isc.org
All,
Bind is version :
root@ns1:~# named -v
BIND 9.8.4-rpz2+rl005.12-P1
And here is the Packet Disection
Packet 838 Client ---> Local Name Server
Packet 839 Local-NS ---> Upstream NS
Packet 840 Upstream-NS ---> Local-NS
Packet 841 Local-NS ---> Client
<code>
No. Time Source Destination Protocol Length Info
838 06:11:21.064388 CLIENT LOCAL-DNS-SERVER DNS 114 Standard query 0x0479 NAPTR DOMAIN-NAME-REQUEST
Frame 838: 114 bytes on wire (912 bits), 114 bytes captured (912 bits)
Ethernet II, Src: Cisco_b9:31:c0 (1c:e6:c7:b9:31:c0), Dst: Vmware_a0:18:f3 (00:50:56:a0:18:f3)
Internet Protocol Version 4, Src: CLIENT (CLIENT), Dst: LOCAL-DNS-SERVER (LOCAL-DNS-SERVER)
User Datagram Protocol, Src Port: hydap (15000), Dst Port: domain (53)
Domain Name System (query)
[Response In: 3400]
Transaction ID: 0x0479
Flags: 0x0100 Standard query
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data: Unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
DOMAIN-NAME-REQUEST: type NAPTR, class IN
No. Time Source Destination Protocol Length Info
839 06:11:21.066859 LOCAL-DNS-SERVER UPSTREAM-DNS-SERVER DNS 125 Standard query 0xb83c NAPTR DOMAIN-NAME-REQUEST
Frame 839: 125 bytes on wire (1000 bits), 125 bytes captured (1000 bits)
Ethernet II, Src: Vmware_a0:18:f3 (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: UPSTREAM-DNS-SERVER (UPSTREAM-DNS-SERVER)
User Datagram Protocol, Src Port: 23175 (23175), Dst Port: domain (53)
Domain Name System (query)
[Response In: 840]
Transaction ID: 0xb83c
Flags: 0x0110 Standard query
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...1 .... = Non-authenticated data: Acceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
DOMAIN-NAME-REQUEST: type NAPTR, class IN
Additional records
<Root>: type OPT
No. Time Source Destination Protocol Length Info
840 06:11:21.154523 UPSTREAM-DNS-SERVER LOCAL-DNS-SERVER DNS 245 Standard query response 0xb83c
Frame 840: 245 bytes on wire (1960 bits), 245 bytes captured (1960 bits)
Ethernet II, Src: Cisco_b9:31:c0 (1c:e6:c7:b9:31:c0), Dst: Vmware_a0:18:f3 (00:50:56:a0:18:f3)
Internet Protocol Version 4, Src: UPSTREAM-DNS-SERVER (UPSTREAM-DNS-SERVER), Dst: LOCAL-DNS-SERVER (LOCAL-DNS-SERVER)
User Datagram Protocol, Src Port: domain (53), Dst Port: 23175 (23175)
Domain Name System (response)
[Request In: 839]
[Time: 0.087664000 seconds]
Transaction ID: 0xb83c
Flags: 0x8100 Standard query response, No error
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
.... .... 0... .... = Recursion available: Server can't do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... ...0 .... = Non-authenticated data: Unacceptable
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 0
Authority RRs: 3
Additional RRs: 4
Queries
DOMAIN-NAME-REQUEST: type NAPTR, class IN
Authoritative nameservers
CORRECT-DNS-SERVER#1: type NS, class IN, ns CORRECT-DNS-SERVER#1
CORRECT-DNS-SERVER#2: type NS, class IN, ns CORRECT-DNS-SERVER#2
CORRECT-DNS-SERVER#3: type NS, class IN, ns CORRECT-DNS-SERVER#3
Additional records
CORRECT-DNS-SERVER#1: type A, class IN, addr IP1
CORRECT-DNS-SERVER#2: type A, class IN, addr IP2
CORRECT-DNS-SERVER#3: type A, class IN, addr IP3
<Root>: type OPT
No. Time Source Destination Protocol Length Info
841 06:11:21.157804 LOCAL-DNS-SERVER CLIENT DNS 114 Standard query response 0x0479 Server failure
Frame 841: 114 bytes on wire (912 bits), 114 bytes captured (912 bits)
Ethernet II, Src: Vmware_a0:18:f3 (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
</code>
Any and all help would be appreciated
Thank you,
Evan Hunt
Jan 6, 2015, 5:44:44 PM1/6/15
to Levi Pederson, bind-...@lists.isc.org
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
[...]
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.
> domain
Levi Pederson
Jan 6, 2015, 6:05:20 PM1/6/15
to Evan Hunt, bind-...@lists.isc.org
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,
0 new messages