FORMERR on packet received from Forwarder

2014-06-16 Thread Levi Pederson 
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 | 612.787.7392
levipeder...@mankatonetworks.net
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

Re: FORMERR on packet received from Forwarder

2014-06-16 Thread Tony Finch 
Levi Pederson levipeder...@mankatonetworks.net wrote:

 I have an authoritative DNS server that is supposed to forward any
 unknowns to a specific upstream server.

You are mixing authoritative and recursive service in a way that is not
going to work well.

Forwarding is designed for recursive clients. It doesn't make sense to
forward queries on an authoritative server.

When BIND forwards to an upstream server it makes recursive queries and
expects the upstream server to return a complete response. Your upstream
server is not a recursive server: there is no RA bit set in the response,
and the response is a referral. BIND is objecting to a non-improving
referral which means that BIND thinks the server is authoritative for
zone X but the referral says zone X is elsewhere.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Fisher: North or northwest 5 to 7, occasionally gale 8 at first. Moderate or
rough. Fair. Good.
___
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