transfer of 'example.com/IN' from 9.10.11.12#53: failed while receiving responses: connection reset

Luis Eduardo C. Clemente luisecclemente at yahoo.com.br
Fri Dec 4 19:08:09 UTC 2015


Hello Grant,

   Thanks for your response, I will take care of domain and IP ranges names and numbers next time to be obfuscate, thanks to let me know.

   Regarding RR I not sure what it is, could be the lines of zone file? If yes, one has 2.380 lines (zone with issues) and the other one has 1.318 lines (zone that transfers properly). 

   I will try capture with tcpdump something in the next days between the master and this slave and let you know.

Regard's

Luis


-----------------------------------------------------------------------

Date: Tue, 1 Dec 2015 19:10:29 -0700
From: Grant Taylor <gtaylor at tnetconsulting.net>
To: bind-users at lists.isc.org
Subject: Re: transfer of 'example.com/IN' from 9.10.11.12#53: failed
    while    receiving responses: connection reset
Message-ID: <565E5315.9050803 at tnetconsulting.net>
Content-Type: text/plain; charset=windows-1252; format=flowed


On 12/01/2015 08:30 AM, Luis Eduardo C. Clemente wrote:
>    Here is the issue. We currently have 2 zones (example.com and
> sample.com - not real names due confidential purposes).

F.Y.I. If you are obfuscating names, please use (fairly) well documented
documentation domains.  "example.com" (like you have) or "example.net"
or "example.org".  The same goes for IPs, 192.0.2.0/24 - Test Net 1,
198.51.100.0/24 - Test Net 2, and 203.0.113.0/24 - Test Net 3.  ;-)

>    The thing is that both zones are on the same Master DNS and have the
> same configuration on named.conf. Both zones can be transferred to other
> slaves normally but only to a specific server only one zone is
> transferred and return the connection reset to the other zone.

Presuming that the problem is not configuration related, I would
immediately wonder if there is something in the network that is
preventing the transfer of the problematic zone.

How big (# of RR) is the zone that transfers properly?  What about the
problematic zone?

I'd probably go for TCPDump and / or Wireshark to analyze the transfer
that is failing.  You will probably want to check both ends.  It would
be really nice if you can capture from both ends at the same time to
compare them.

I half way expect that something is different about your problematic
zone.  Either you can't successfully send large (> 512 Byte) queries /
responses, or TCP is filtered.  This would be evident by the server end
sending the data but the receiver not seeing it.



-- 
Grant. . . .
unix || die
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20151204/9c27fcf5/attachment.html>


More information about the bind-users mailing list