Re: several master ip's for a slave zone
How does this feature address the risk that data provided by one master might get overwritten by another? Regards, Kalpesh On Fri, Nov 4, 2011 at 4:08 AM, Anand Buddhdev ana...@ripe.net wrote: On 03/11/2011 23:14, hugo hugoo wrote: Hi Hugo, I have seen that for a slave zone, it is possible to configure several master IP's. Why this possibility? How does it works if several master zone can be used for the zone transfer? This allows for resiliency. In case one of the master servers is unreachable, BIND can try the next master in the list. Anand Buddhdev RIPE NCC ___ 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 ___ 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
Re: bind 9.6-esv-r1 segfault
Hi,
I seem to have hit the same issue on Bind 9.7.3.
=== [Test environment] ===
- The issued system is cache server. It does not have a zone which it
can respond as a master server.
- The server which receives a recursive query asks a recursive query
from root server to the last server in order.
Then the last server returns A record, MX record, and TXT record.
Due to high inflow of queries, number of socket connections got exhausted.
general: error: socket: file descriptor exceeds limit (2048/2048)
The server received too many queries for the domain for which either they
were not authoritative or it could not find response even if they are
marked as authoritative. Thus they were marked as lame.
lame-servers: info: lame server resolving
At this point we started going out of memory.
resolver: error: could not mark server as lame: out of memory
Code and dump analysis suggest that threads were stuck in select at the
time of sending query from resolver.
Has there been any workaround or fix for this issue?
Since too many requests are pending for socket fd, I think that running the
nameserver with epoll instead of select and increasing the number of socket
connections should help in reducing the traffic.
I would very much appreciate any suggestion/ideas on this issue.
Regards,
Kalpesh
On Sun, Sep 26, 2010 at 5:53 PM, Sergey V. Lobanov ser...@lobanov.inwrote:
OK. I sent the bug the report to bind9-b...@isc.org (Ticket [ISC-Bugs
#22208])
26.09.10, 01:41, Cathy Almond cat...@isc.org:
Hi Sergey,
At the moment this doesn't sound like anything we've seen before.
Please could you report it to bind9-b...@isc.org:
https://www.isc.org/software/bind/news
We'll need the core dump, the binary that generated it and the libs
associated with the binary (ldd named should capture the list we need)
in order to analyze it.
Thanks,
Cathy
On 24/09/10 19:09, Sergey V. Lobanov wrote:
Some info from the core dump:
General info:
Core was generated by `/usr/local/sbin/named -4 -c /etc/named.conf -t
/var/lib/named -u named -n 4'.
Program terminated with signal 11, Segmentation fault.
#0 0x0813d4d7 in resquery_udpconnected (task=0x8230ef88,
event=0xa5bbf068)
at resolver.c:1202
1202QTRACE(udpconnected);
Backtrace:
#0 0x0813d4d7 in resquery_udpconnected (task=0x8230ef88,
event=0xa5bbf068)
at resolver.c:1202
#1 0x081c4916 in dispatch (manager=) at task.c:862
#2 run (manager=) at task.c:1005
#3 0xb753c725 in start_thread () from /lib/libpthread.so.0
#4 0xb73181ee in clone () from /lib/libc.so.6
Program listing:
1197resquery_udpconnected(isc_task_t *task, isc_event_t *event) {
1198resquery_t *query = event-ev_arg;
1199
1200REQUIRE(event-ev_type == ISC_SOCKEVENT_CONNECT);
1201
1202QTRACE(udpconnected);
1203
1204UNUSED(task);
1205
1206INSIST(RESQUERY_CONNECTING(query));
*event:
$7 = {ev_size = 48, ev_attributes = 0, ev_tag = 0x0, ev_type = 131076,
ev_action = 0x813d490 , ev_arg = 0x89db2c80,
ev_sender = 0x8232d180, ev_destroy = 0x81a8970 ,
ev_destroy_arg = 0x821d0e8, ev_link = {prev = 0x, next =
0x}}
*query:
$8 = {magic = 2312763280, fctx = 0xdededede, mctx = 0xdededede,
dispatchmgr = 0xdededede, dispatch = 0xdededede,
exclusivesocket = 3739147998, addrinfo = 0xdededede, tcpsocket =
0xdededede,
start = {seconds = 3739147998, nanoseconds = 3739147998}, id =
57054,
dispentry = 0xdededede, link = {prev = 0xdededede, next =
0xdededede},
buffer = {magic = 3739147998, base = 0xdededede, length =
3739147998,
used = 3739147998, current = 3739147998, active = 3739147998,
link = {
prev = 0xdededede, next = 0xdededede}, mctx = 0xdededede},
tsig = 0xdededede, tsigkey = 0xdededede, options = 3739147998,
attributes = 3739147998, sends = 3739147998, connects = 3739147998,
data =
Re: SPF implementation schedule.
Looking at zytrix and spf2 sites, it seems that SPF is yet to be implemented at functional level. RFC4408 documentation suggests method to implement SPF. However, I need to know if ISC is planning to provide support for SPF at client and/or server side. Will anyone from ISC like to comment? On Mon, Jul 11, 2011 at 7:42 PM, Eivind Olsen eiv...@aminor.no wrote: kalpesh varyani wrote: Does ISC implement SPF for server or client side currently? If yes, then where to get the libraries; if not then what is the scheduled date/release for implementation? I'm not ISC, and anything I say may be completely wrong. Ok, that's the disclaimer done with... BIND support for SPF extends as far as being allowed to put SPF records into zones. As far as I know BIND does not have any libraries or functions to actually make much sense of the content of SPF records, which is what I'm guessing you're really looking for. Perhaps something like libspf (http://www.libspf2.org) is what you want? Regards Eivind Olsen ___ 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 ___ 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
SPF implementation schedule.
Hi, As per the ARM document for bind9.7, ISC has provided support for new RR(resource record) types including SPF. Comparison of code of Bind9.3 and Bind9.7 suggests that new libraries (at src\lib\dns) have been provided for SPF identification. However, either the function definitions are absent or function call is absent for SPF related library functions. Does ISC implement SPF for server or client side currently? If yes, then where to get the libraries; if not then what is the scheduled date/release for implementation? Regards, Kalpesh ___ 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
Deallocating memory in isc code.
Hi,
Is it necessary to deallocate memory assigned using isc_mem_get() by
explicitly using isc_mem_free()?
Ref: File builtin.c is available at
ftp://1node.net/linux/bind-9.7.0b1/bin/named/*builtin*.*c*ftp://1node.net/linux/bind-9.7.0b1/bin/named/builtin.c
Following is the code snippet:
static isc_result_t builtin_create(const char *zone, int argc, char
**argv,void *driverdata, void **dbdata)
{
...
builtin_t *empty; -- Local variable.
...
empty = *isc_mem_get*(ns_g_mctx, sizeof(*empty)); -- Memory assigned using
isc_mem_get
server = isc_mem_strdup(ns_g_mctx, argv[1]);
contact = isc_mem_strdup(ns_g_mctx, argv[2]);
if (empty == NULL || server == NULL || contact == NULL) {
*dbdata = empty_builtin;
if (server != NULL)
isc_mem_free(ns_g_mctx, server);
if (contact != NULL)
isc_mem_free(ns_g_mctx, contact);
if (empty != NULL)
isc_mem_put(ns_g_mctx, empty, sizeof (*empty));
}
...
}
Here memory is assigned using isc_mem_get() however isc_mem_free() is
conditional. Thus if conditions are false then there will be no
isc_mem_free().
1. Even if *builtin_t *empty; *is local to the function *builtin_create*, can
it cause memory leak?
2. what should be the rerurn value of *isc_mem_strdup()* on success/failure?
Regards,
Kalpesh
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
2038 problem and BIND.
Hi Experts, I would just like to know, how BIND takes care of the 2038 problem. Since now DNSSEC has a lot to do with timings, there could be issues if someone would set the signature expiry time to a large value (possibly after Y2K38). This can create problems, if care is not taken in BIND code. Or does BIND code is designed so that it relies on the OS to deal with this problem? Just wanted to know how it is done or at least be assured. Thanks in advance, Kalpesh. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Switching to TCP in BIND.
Hi all, Please let me know if there is some feature in any of the versions of BIND, by which it switches to TCP when it detects spoofed replies. I am aware that BIND uses UDP for all its query / response and TCP for zone transfers. Regards, Kalpesh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Different handling of referrals by dig and nslookup
Hi Doug, Please find my response inline. On Sun, Feb 14, 2010 at 8:53 AM, Doug Barton do...@dougbarton.us wrote: On 02/13/10 18:42, kalpesh varyani wrote: Hi Rick, I am aware that it is a somewhat odd (but not incorrect, am I right ?) to put a non-recursive name server in the resolv.conf There are certain very specific circumstances where you might want to do this, but in general I can't see any reason to do this, and would not recommend it. but I am not able to understand the behavioral difference of ping/dig and nslookup. What is it that you want to understand? You seem quite focused on figuring out why they are behaving differently, is there some reason why you need to put a non-resolving name server in resolv.conf? I guess, I am in one of those specific circumstances. The reason I prefer to have non-resolving name server in resolv.conf is as follows: Name server A (the first name server with recursion no;) was not present earlier, and has been newly configured as a name server. Name server B, which was previously handling all the name resolution part has recursion yes; Also, I would like my 3rd linux system (from where I try resolving names) to send queries to its root servers, only in case my first name server fails to resolve the name and sends back a referral. This would ensure that my 3rd linux system doesnot send queries to its name server, which could have been handled by the name server B (that was specified in resolv.conf). This would ensure that the root name server's network wont have unnecesary DNS traffic. But logically shouldn't it be moving to the next name server when the first one fails even in the case of ping and dig. This is what, I think, one would expect from a resolver. dig is a DNS diagnostic tool. You asked for an answer, you got an answer. The fact that it didn't move on is not a mystery. nslookup is designed to get its answers from the system resolver, so the real question is, why did ping and nslookup behave differently? But that's really a question for your linux distro. My basic concern is that, if my 3rd linux system can resolve a name using any of the name servers specified in the resolv.conf, then it effectively means that the remote system (for which name resolution was done) is reachable from my linux system. And if that is the case, then a ping to that system should not fail in the name resolution part. Regards, Kalpesh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Different handling of referrals by dig and nslookup
Hi Rick, I am aware that it is a somewhat odd (but not incorrect, am I right ?) to put a non-recursive name server in the resolv.conf but I am not able to understand the behavioral difference of ping/dig and nslookup. But logically shouldn't it be moving to the next name server when the first one fails even in the case of ping and dig. This is what, I think, one would expect from a resolver. Can you please put some light? Regards, Kalpesh. On Sat, Feb 13, 2010 at 10:40 PM, Rick Dicaire kri...@gmail.com wrote: On Sat, Feb 13, 2010 at 12:07 PM, kalpesh varyani kalpesh.l...@gmail.com wrote: From a third linux system, I try name resolution using dig or nslookup. In this system, I have resolv.conf as: nameserver A nameserver B Just out of curiosity, why do you have a non recursing name server in resolv.conf? -- aRDy Music and Rick Dicaire present: http://www.ardynet.com http://www.ardynet.com:9000/ardymusic.ogg.m3u ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Workaround for 'rndc stop' ?
Hi all, Can anyone please tell me is there any other command by which i can stop the name-server without loosing the recent updates. I know that I can do this by issuing 'rndc stop' but for some reason I am not able to . What are the different ways by which I can have the same benefits as that of 'rndc stop'. Thanks in advance, Kalpesh. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
named does not shutdown properly while 'rndc stop'
Hi All , I have three DNS servers which are running ISC BIND version 9.4.3-P3. I have observed named hang when trying to shutdown the nameserver using rndc stop from time to time (once in two weeks). I shutdown my DNS servers each night and sometimes my named faces this hang. At that time , I do not see the 'exiting' message when I observe the shutdown message sequence as shown: named[21063]: shutting down: flushing changes named[21063]: stopping command channel on 127.0.0.1#953 named[21063]: no longer listening on 202.156.1.67#53 named[21063]: no longer listening on 127.0.0.1#53 named[21063]: no longer listening on 202.156.1.68#53 ---*-'exiting' message not shown* The 'ps' output still shows named running, but it does not respond to queries. Can anyone explain this not-so-frequent behaviour while doing the shutdown ? Regards, Kalpesh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Connect returns EINPROGRESS
Hi all,
I am using HPUX 11.23 and looking into the socket.c code of bind-9.4.3-P3.
Following is the code for isc_socket_connect() in the file:
isc_result_t
isc_socket_connect(isc_socket_t *sock, isc_sockaddr_t *addr,
isc_task_t *task, isc_taskaction_t action, const void
*arg)
{
::
/*
* Try to do the connect right away, as there can be only one
* outstanding, and it might happen to complete.
*/
sock-address = *addr;
cc = connect(sock-fd, addr-type.sa, addr-length);
if (cc 0) {
* /*
* HP-UX fails to connect a UDP socket and sets errno to
* EINPROGRESS if it's non-blocking. We'd rather regard this
as
* a success and let the user detect it if it's really an
error
* at the time of sending a packet on the socket.
*/
if (sock-type == isc_sockettype_udp errno == EINPROGRESS)
{
cc = 0;
goto success;
}*
if (SOFT_ERROR(errno) || errno == EINPROGRESS)
goto queue;
::
/*
* If connect completed, fire off the done event.
*/
success:
if (cc == 0) {
sock-connected = 1;
sock-bound = 1;
dev-result = ISC_R_SUCCESS;
isc_task_send(task, (isc_event_t **)dev);
UNLOCK(sock-lock);
return (ISC_R_SUCCESS);
}
queue:
/*
* Poke watcher here. We still have the socket locked, so there
* is no race condition. We will keep the lock for such a short
* bit of time waking it up now or later won't matter all that much.
*/
if (sock-connect_ev == NULL)
select_poke(manager, sock-fd, SELECT_POKE_CONNECT);
sock-connect_ev = dev;
UNLOCK(sock-lock);
return (ISC_R_SUCCESS);
I am noticing a strange code path here (marked in blue).My question here is,
why does the
success path being executed when errno is EINPROGRESS ?
Probably the answer is already given in the comments(/*HPUX fails */),
but I am not able to
understand the implications. Could someone please explain why EINPROGRESS is
treated as a success
case.
I see the query failing initially when errno is EINPROGRESS and after
retrying after 2 sec
it succeeds somehow. Could someone explain this behavior.
Thanks in advance,
Kalpesh.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Recursive Query.
Hi All,
I have looked into the code socket.c file and tusc output for the requirsive
query.
tusc O/P :
-
#3 connect(516, 0x347694, 16) ..
*ERR#245 EINPROGRESS*
sin_family: AF_INET
sin_port: 53
sin_addr.s_addr: 192.168.2.96
#2 write(12, A u g 1 1 1 7 : 5 5 : 3 4 . .., 61) . = 61
#5 write(7, \0\00204\0c0\0\0, 8) . = 8
#3 sendmsg2(516, \0\0\0\0\0\0\0\0z fec8\b\0\0\001.., O_RDONLY) ... = 49
--
In above tusc output, we are seen that connect is fail with the
EINPROGRESS and after then sendmsg2 call and it got failed.
Code for BIND-9.4.3-P1:
cc = connect(sock-fd, addr-type.sa, addr-length);
if (cc 0) {
if (cc 0) {
/*
* HP-UX fails to connect a UDP socket and sets errno to
* EINPROGRESS if it's non-blocking. We'd rather regard
this as
* a success and let the user detect it if it's really an
error
* at the time of sending a packet on the socket.
*/
* if (sock-type == isc_sockettype_udp errno ==
EINPROGRESS) {
cc==0;
goto success;*
succecss:
if (cc == 0) {
sock-connected = 1;
sock-bound = 1;
dev-result = ISC_R_SUCCESS;
isc_task_send(task, (isc_event_t **)dev);
UNLOCK(sock-lock);
return (ISC_R_SUCCESS);
}
-
In above code we have same code for the success retrun from the connect and
also connect retrun *EINPROGRESS i.e. cc *==0, it means that we are not
taking care of the EINPROGRESS.
Regards
Dinesh.
On Wed, Aug 12, 2009 at 5:48 AM, kalpesh varyani kalpesh.l...@gmail.comwrote:
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 cat...@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 k
Recursive Query.
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. Regards Hiro Lalwani ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recursive Query.
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 k...@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 dono...@beth.k12.pa.us mailto:dono...@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recursive Query.
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 cat...@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 k...@chrysler.com mailto:k...@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 dono...@beth.k12.pa.us mailto:dono...@beth.k12.pa.us mailto:dono...@beth.k12.pa.us mailto:dono...@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
