RE: BIND 9.6.2rc1 make test question
Hi Stace, Sorry, I didn't think this was necessarily a Solaris problem. I'm running this on Solaris 10 (SPARC 64bit), built with Sun Studio 12.1. Why did it occur on OpenSolaris? Thanks. -John From: stacey.marsh...@sun.com [stacey.marsh...@sun.com] Sent: Wednesday, February 24, 2010 9:01 AM To: John Center Cc: bind-users@lists.isc.org Subject: Re: BIND 9.6.2rc1 make test question On 02/15/10 20:25, John Center wrote: Hi, I just built BIND 9.6.2rc1 make test passes except for the following: A:the dst module provides the capability to verify data signed with the RSA and DSA algorithms I:testing t2_data_1, t2_dsasig, test., 23616, DST_ALG_DSA, ISC_R_SUCCESS I:testing t2_data_1, t2_rsasig, test., 54622, DST_ALG_RSAMD5, ISC_R_SUCCESS I:testing t2_data_1, t2_dsasig, test., 54622, DST_ALG_RSAMD5, !ISC_R_SUCCESS I:testing t2_data_2, t2_dsasig, test., 23616, DST_ALG_DSA, !ISC_R_SUCCESS mem.c:322: INSIST(dl != 0L) failed. I:the test case caused exception 6 R:UNRESOLVED What does this mean where do I look to resolve this issue? Thanks. -John John, You don't state what your building on? I too have come across the same error on OpenSolaris circa snv_117. Stace ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.6.2rc1 make test question
Hi, I just built BIND 9.6.2rc1 make test passes except for the following: A:the dst module provides the capability to verify data signed with the RSA and DSA algorithms I:testing t2_data_1, t2_dsasig, test., 23616, DST_ALG_DSA, ISC_R_SUCCESS I:testing t2_data_1, t2_rsasig, test., 54622, DST_ALG_RSAMD5, ISC_R_SUCCESS I:testing t2_data_1, t2_dsasig, test., 54622, DST_ALG_RSAMD5, !ISC_R_SUCCESS I:testing t2_data_2, t2_dsasig, test., 23616, DST_ALG_DSA, !ISC_R_SUCCESS mem.c:322: INSIST(dl != 0L) failed. I:the test case caused exception 6 R:UNRESOLVED What does this mean where do I look to resolve this issue? Thanks. -John -- John Center Villanova University ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind 9.6.1-P1 ignoring listen-on directive
Hi,
I'm testing Bind 9.6.1-P1 on Solaris 10 SPARC (64bit/Sun Studio 12.1)
I noticed this in the logs:
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface lo0, 127.0.0.1#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge0, 153.104.92.2#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge0:1, 153.104.92.4#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge1, 10.104.36.20#53
I only wanted named to listen on one interface + the loopback, so I
added a listen-on statement in named.conf:
acl testnets { 153.104.244.0/24; 153.104.248.0/24; };
options {
directory /opt/isc/bind/var/db;
allow-query { testnets; };
listen-on { localhost; 153.104.92.2; };
listen-on-v6 { none; };
};
zone 0.0.127.in-addr.arpa in {
type master;
file db.127.0.0;
notify no;
};
But, I still have the same log entries when I start named. I then
modified named.conf to specifically exclude the other interfaces:
listen-on { localhost; 153.104.92.2; !153.104.92.4; !10.104.36.20; };
But, again, I'm still seeing it state that it is listening on the
excluded interfaces. I tried increasing the debug level, but I didn't
see any additional info pertaining to this. I know that it is listening
on the excluded interfaces because I see a queries on the 10.104.36.20
interface:
Sep 9 13:09:16 ns3a/ns3a named[22867]: [ID 873579 daemon.info] client
10.104.109.0#1041: query (cache) 'ATF/A/IN' denied
Sep 9 13:09:16 ns3a/ns3a named[22867]: [ID 873579 daemon.info] client
10.104.109.0#1046: query (cache) 'ATP.villanova.edu/A/IN' denied
Is this a known problem? It's an issue for us because we restrict DNS
queries to particular interfaces. If it isn't a known bug, I'd be glad
to help troubleshoot this problem.
Thanks.
-John
--
John Center
Villanova University
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.6.1-P1 ignoring listen-on directive
Of course, right after hitting enter on this message, I came across a
message from last year about localhost mapping to all interfaces, not
just 127.0.0.1. I created a loopback acl used it instead that
worked. Sorry for the noise.
-John
On 09/09/2009 03:04 PM, John Center wrote:
Hi,
I'm testing Bind 9.6.1-P1 on Solaris 10 SPARC (64bit/Sun Studio 12.1)
I noticed this in the logs:
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface lo0, 127.0.0.1#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge0, 153.104.92.2#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge0:1, 153.104.92.4#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge1, 10.104.36.20#53
I only wanted named to listen on one interface + the loopback, so I
added a listen-on statement in named.conf:
acl testnets { 153.104.244.0/24; 153.104.248.0/24; };
options {
directory /opt/isc/bind/var/db;
allow-query { testnets; };
listen-on { localhost; 153.104.92.2; };
listen-on-v6 { none; };
};
zone 0.0.127.in-addr.arpa in {
type master;
file db.127.0.0;
notify no;
};
But, I still have the same log entries when I start named. I then
modified named.conf to specifically exclude the other interfaces:
listen-on { localhost; 153.104.92.2; !153.104.92.4; !10.104.36.20; };
But, again, I'm still seeing it state that it is listening on the
excluded interfaces. I tried increasing the debug level, but I didn't
see any additional info pertaining to this. I know that it is listening
on the excluded interfaces because I see a queries on the 10.104.36.20
interface:
Sep 9 13:09:16 ns3a/ns3a named[22867]: [ID 873579 daemon.info] client
10.104.109.0#1041: query (cache) 'ATF/A/IN' denied
Sep 9 13:09:16 ns3a/ns3a named[22867]: [ID 873579 daemon.info] client
10.104.109.0#1046: query (cache) 'ATP.villanova.edu/A/IN' denied
Is this a known problem? It's an issue for us because we restrict DNS
queries to particular interfaces. If it isn't a known bug, I'd be glad
to help troubleshoot this problem.
Thanks.
-John
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
