Recursive Query.

kalpesh varyani kalpesh.link at gmail.com
Wed Aug 12 00:18:52 UTC 2009


 thanks for reply.

 This issue is seen only on hp-ux 11.11/11.23 env. I have checked the
configuration and
 environment issue not finding anything wrong.

Regards
Kalpesh

On Tue, Aug 11, 2009 at 11:20 PM, Cathy Almond <cathya at isc.org> wrote:

> I would recommend tracing or similar to find out why your named daemon
> is not able to send to the IP address being logged.  You may find that
> there are network connectivity issues or that the remote IP is sending
> back an ICMP response.
>
> The reason this particular logged error is seen on HP-UX is seemingly a
> feature of the sockets implementation whereby the set-up of the
> destination address may fail, but it isn't trapped until the send fails
> with EDESTADDRREQ.
>
> The underlying failure to send is a configuration/environmental issue
> and this is what needs to be investigated.
>
> Cathy
>
>
> Kevin Darcy wrote:
> > Well, you could file a bug report, but I'm not aware of this error
> > happening on other platforms, so it might end up being a kernel issue of
> > some sort.
> >
> >
> >                                          - Kevin
> >
> > kalpesh varyani wrote:
> >> Hi Kevin,
> >>
> >> Thanks a lot.
> >>
> >> Please find the more details for the same.
> >>
> >> BIND version  : 9.3.6
> >>
> >> OS version : HP-UX 11.23
> >>
> >> I have look at the *socket.c* file and seen that "
> >>
> >> This error indicates that sendmsg(2) failed with EDESTADDREG ".
> >>
> >>
> ----------------------------------------------------------------------------------------------------------
> >>
> >>
> >>      cc = sendmsg(sock->fd, &msghdr, 0);
> >>               send_errno = errno;
> >>
> >>
> >>     /*
> >>                          * The other error types depend on whether or
> >> not the
> >>                          * socket is UDP or TCP.  If it is UDP, some
> >> error
> >>                          * that we expect to be fatal under TCP are
> merel
> >>                          * annoying, and are really soft errors.
> >>                          *
> >>                          * However, these soft errors are still
> >> returned as
> >>                          * a status.
> >>                          */
> >>
> >>                         isc_sockaddr_format(&dev->address, addrbuf,
> >> sizeof(addrbuf));\
> >>                         isc__strerror(send_errno, strbuf,
> >> sizeof(strbuf));
> >>                         UNEXPECTED_ERROR(__FILE__, __LINE__,
> >> "internal_send: %s: %s",
> >>                                                  addrbuf, strbuf);
> >>                         dev->result = isc__errno2result(send_errno);\
> >>                         return (DOIO_HARD);
> >>
> >>
> --------------------------------------------------------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >> Note : This same is also seen on BIND-9.4.3-P3
> >>
> >> Regards
> >> Kalpesh
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Aug 11, 2009 at 10:30 PM, Kevin Darcy <kcd at chrysler.com
> >> <mailto:kcd at chrysler.com>> wrote:
> >>
> >>     "#53" designates *port* 53. Nothing unusual about that.
> >>
> >>     To me, this looks more like a kernel issue-- EDESTADDRREQ is what
> >>     you get if you try to send data via a UDP socket that's not
> >>     connect()ed. BIND keeps good track of what's connect()ed and what
> >>     isn't; it's like the kernel is losing the association somehow.
> >>
> >>     Without knowing what OS this is running on, or what version of
> >>     BIND, it's kind of hard to troubleshoot further than that.
> >>
> >>
> >>            - Kevin
> >>
> >>     kalpesh varyani wrote:
> >>
> >>         thanks for your quick reply
> >>          I am seen below error msg " once per 60sec" and no  seen any
> >>         query failure.
> >>          general: error: internal_send: 192.168.2.222#53: Destination
> >>         address required
> >>         general: error: /lib/isc/unix/errno2result.c:116: unexpected
> >>         error:
> >>          general: error: unable to convert errno to isc_result: 217:
> >>         Destination address required
> >>          general: error: /lib/isc/unix/socket.c:1533: unexpected error
> >>         :
> >>          general: error: internal_send: 192.168.2.222#53: Destination
> >>         address required
> >>          general: error: /isc/unix/errno2result.c:116: unexpected
> >>         error:
> >>         Regards
> >>         Hiro Lalwani
> >>
> >>
> >>          On Tue, Aug 11, 2009 at 10:14 PM, donovan jeffrey j
> >>         <donovan at beth.k12.pa.us <mailto:donovan at beth.k12.pa.us>
> >>         <mailto:donovan at beth.k12.pa.us
> >>         <mailto:donovan at beth.k12.pa.us>>> wrote:
> >>
> >>
> >>            On Aug 11, 2009, at 12:39 PM, kalpesh varyani wrote:
> >>
> >>                Hi,
> >>                    I have below configuration.
> >>                    DNS server1 -- Forwarder
> >>                    DNS server2-- Authoritative
> >>                    I am seeing following errors on server1.
> >>                    ----------------------------
> >>                general: error: internal_send: 192.168.2.222#53:
> >>             Destination
> >>                address required
> >>                general: error: /lib/isc/unix/errno2result.c:116:
> >>             unexpected
> >>                error:
> >>                 general: error: unable to convert errno to isc_result:
> >>             217:
> >>                Destination address required
> >>                 general: error: /lib/isc/unix/socket.c:1533:
> >>             unexpected error
> >>                :
> >>                 general: error: internal_send: 192.168.2.222#53:
> >>             Destination
> >>                address required
> >>                 general: error: /isc/unix/errno2result.c:116: unexpected
> >>                error:
> >>                    Could any of help me, to resolve this issue.
> >>
> >>
> >>            sounds like a routing or firewall issue. Although from the
> >>         limited
> >>            post " #53 " doesn't look right.
> >>
> >>            -j
> >>
> >>
> >>
> >> ------------------------------------------------------------------------
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
>  https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20090812/dd41c329/attachment.html>


More information about the bind-users mailing list