Diagnostic help part 2

Eli Heady eli.heady at gmail.com
Wed Oct 1 03:14:38 UTC 2014


On Sep 30, 2014 7:11 PM, "John Anderson" <johna <johna at ccbill.com>@
<johna at ccbill.com>ccbill.com <johna at ccbill.com>> wrote:
>
> >If named is running and doesn't respond on the external interface, it's
> >possible that your listen-on {}; directive is set to only localhost.
>
> >TCP connections to 205.238.182.102 come back "Connection refused", so
> >it's possible that BIND just isn't listening on the interface or perhaps
> >you're filtering the inbound queries.   Do you see the queries come in to
> >the box, either via packet dump or query logs?
>
>
> Is your BIND server behind a firewall?  Is it only listening on
localhost, or on an internal interface?  If '~]$ netstat -nlp | grep named'
tells you that named is only listening on127.0.0.1 <http://127.0.0.1:53>:53
<http://127.0.0.1:53>, then you need to adjust listen-on in named.conf.  If
you are running iptables, you need to allow at least UDP/53 in, if this is
a master transferring to slaves, it might be a good idea to allow TCP/53 in
as well.   If you are behind a firewall, you need to open up UDP/53 or port
forward UDP/53 to your bind server.
>

I know Bill's issue is solved, but I want to point out that anyone running
DNS would be wise to not block TCP/53. TCP service for queries is specified
in the protocol design, and not just for transfers. Failing UDP queries
should result in retries over TCP

With response sizes growing (dnssec, ipv6), answers are more likely to be
too large for UDP.

If you enable response rate limiting (try it, you'll like it), you must
also respond to TCP queries. The RRL implementation is designed to cause
legitimate clients to retry queries over TCP.

There are a variety of reasons UDP  responses won't make it to clients,
many of which are outside your control. Not offering TCP service means
clients that can't reliably get UDP responses likely won't get any answer
from your servers at all.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140930/c491fcff/attachment.html>


More information about the bind-users mailing list