Error Building 9.7.1-P2 on Sparc/Solaris 8
Hello; I am trying to build 9.7.1-P2 on Solaris Sparc in the same way I've done so countless other ways in the past, but now getting the following error: [...] making all in /tmp/bind-9.7.1-P2/bin/named/unix gcc -I/tmp/bind-9.7.1-P2 -I./include -I./unix/include -I. -I/tmp/bind-9.7.1-P2/lib/lwres/include -I../../lib/lwres/unix/include -I../../lib/lwres/include -I/tmp/bind-9.7.1-P2/lib/dns/include -I../../lib/dns/include -I/tmp/bind-9.7.1-P2/lib/bind9/include -I../../lib/bind9/include -I/tmp/bind-9.7.1-P2/lib/isccfg/include -I../../lib/isccfg/include -I/tmp/bind-9.7.1-P2/lib/isccc/include -I../../lib/isccc/include -I/tmp/bind-9.7.1-P2/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include -D_REENTRANT -D_XPG4_2 -D__EXTENSIONS__ -g -O2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing \ -DVERSION=\"9.7.1-P2\" \ -DNS_LOCALSTATEDIR=\"/opt/bind/var\" \ -DNS_SYSCONFDIR=\"/opt/bind/etc\" \ -c ./config.c ./config.c:249: error: expected ',' or ';' before 'MANAGED_KEYS' *** Error code 1 make: Fatal error: Command failed for target `config.o' Current working directory /tmp/bind-9.7.1-P2/bin/named *** Error code 1 make: Fatal error: Command failed for target `subdirs' Current working directory /tmp/bind-9.7.1-P2/bin *** Error code 1 make: Fatal error: Command failed for target `subdirs' Am I missing a system setting or variable set somewhere? Any help would be greatly appreciated. .vp ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices For Coexisting
Thanks for the reply. My DMZ, or external lookups, are all performed via one of six BIND-9 servers. The product that we use is based on BIND-8, though they've recently come out with a BIND-9 version. If I "split" my lookups and have internal lookups pointed at the MS DNS servers, and non-authoritative lookups to my external servers (running BIND-9), then shouldn't this address the issues you spoke of? How are you able to allow for the windoze boxes to automatically add entries? In other words, a strong case they made is that they must presently maintain two databases, AD *and* DNS. With MS DNS, they say, this is not the case whereby when you add an entry or join a host, that entry is automatically added in DNS. In there a way to do this in BIND? Thanks again, .vp > Subject: RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices For > Coexisting > Date: Fri, 6 Feb 2009 09:49:42 -0500 > From: jlight...@water.com > To: wiskbr...@hotmail.com; bind-users@lists.isc.org > > I don't see why it is either/or. > > Here we have Windoze DNS servers for internal lookups and Linux/BIND 9 > DNS servers for external lookups. The internal servers refer all > queries they aren't authoritative for to the external ones which in turn > refer all queries for domains we don't own to the root servers. > > The only "gotcha" is that we have some domains that we want to present > different IPs for internally (10.x.x.x) or externally (12.x.x.x). On > the Windoze DNS servers they have our primary domain with those internal > addresses and on the BIND DNS servers we have those external addresses. > > > Of course you could do it all with just BIND servers running views but > this is the way I inherited the BIND servers here. > > We don't seem to have the headaches your Windoze team is moaning about. > Hopefully you are running redundant (master/slave) BIND servers? > > Also I'd suggest upgrading to BIND 9 once you've got all the rest of > this quieted down. > > -Original Message- > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of > wiskbr...@hotmail.com > Sent: Friday, February 06, 2009 9:25 AM > To: bind-users@lists.isc.org > Subject: Case For Microsoft DNS v. BIND 9 - Or Best Practices For > Coexisting > > > > Hello; > > My site is presently using a product derived from BIND-8 for internal > DNS only. > > For years our Windows team has been arguing that they want to be > non-dependent on the non-MS DNS servers; which they say causes them much > grief on firmwide shutdown/bootups. > > Well, their concerns have fallen on ears of those who can make that > decision and it now appears as though we must either come up with good > reasons why we should retain BIND, or a BIND derived product, or simply > a plan to allow MSDNS and BIND to coexist at all. > > Can anyone provide me, or point me at, any good docs on this subject, I > am certain that their a tons of stuff out there, I need simple, to the > point type of stuff. > > Also, can anyone think of any good reason why our internal, non-public > accessible network, should not just be allowed to run either a mixed > BIND/MS-DNs setup? The slave/cache/whatever-but not master, would have > to be BIND. > > > The case the windows team made was ease of adding entries, you simply > add into the MMC, or even easier, when you join a host into a domain, it > adds itself. > > Thanks all, > > .vp > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > > Please consider our environment before printing this e-mail or attachments. > -- > CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential > information and is for the sole use of the intended recipient(s). If you are > not the intended recipient, any disclosure, copying, distribution, or use of > the contents of this information is prohibited and may be unlawful. If you > have received this electronic transmission in error, please reply immediately > to the sender that you have received the message in error, and delete it. > Thank you. > -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Case For Microsoft DNS v. BIND 9 - Or Best Practices For Coexisting
Hello; My site is presently using a product derived from BIND-8 for internal DNS only. For years our Windows team has been arguing that they want to be non-dependent on the non-MS DNS servers; which they say causes them much grief on firmwide shutdown/bootups. Well, their concerns have fallen on ears of those who can make that decision and it now appears as though we must either come up with good reasons why we should retain BIND, or a BIND derived product, or simply a plan to allow MSDNS and BIND to coexist at all. Can anyone provide me, or point me at, any good docs on this subject, I am certain that their a tons of stuff out there, I need simple, to the point type of stuff. Also, can anyone think of any good reason why our internal, non-public accessible network, should not just be allowed to run either a mixed BIND/MS-DNs setup? The slave/cache/whatever-but not master, would have to be BIND. The case the windows team made was ease of adding entries, you simply add into the MMC, or even easier, when you join a host into a domain, it adds itself. Thanks all, .vp ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: IPv6 Lookups on BIND 9.5.1-P1 and .GOV Addresses
> From: do...@dougbarton.us
>
> wiskbr...@hotmail.com wrote:
>> Hello;
>>
>> I have two "DMZ" BIND/DNS servers running whose purpose is to allow
>> lookups via them from my otherwise incapable internal network.
>>
>> I've recently upgraded only one of them from BIND 9.5.0-P2 to BIND
>> 9.5.1-P1. Both servers are running Sparc/Solaris 9.
>>
>> Upon upgrading one to BIND 9.5.0-P2, which was in an effort to
>> resolve failed lookups for .gov sites, I found that the server was
>> now attempting to resolve using IPv6 style addresses. I am not
>> able to find any such attempts in the past at all from either
>> server (See messages from BIND 9.5.1-P1 server below).
>>
>> I've installed a newer db.root file by running dig then saving the
>> output to db.root. The newer file contained IPv6 style entries,
>> which I've manually removed (about the same time attempts ceased)
>
> This isn't going to make a difference. Even if the root server
> addresses were not already in the named binary, the first thing a
> resolving name server does when it starts up is to get an updated copy
> of the information from the root servers themselves.
How and where does this happen?
>> I've also tried to force any attempts at using IPv6 and what appear
>> to be issues resolving .gov domains in my named.conf like this:
>>
>> options { edns-udp-size 512; max-udp-size 512;
>
> Those two options are not good. EDNS exists for a reason.
Delete them?
>> listen-on-v6 {
>> none; }; };
>
> That's not going to do what you want. You want to start named with the
> -4 option. (Although a better option would be to get working IPv6.) :)
I will try using the -4 option, yeah getting IPv6 would be "cool" though not
warranted right now.
>> logging { category lame-servers {null;}; category edns-disabled
>> {null;}; };
>>
>>
>> The issues that I was seeing with .gov sites resulted in this type
>> of error in my logfile:
>>
>> Jan 22 11:24:56 NS1 named[7678]: [ID 873579 daemon.info] too many
>> timeouts resolving 'www.fdic.gov/A' (in 'www.fdic.gov'?): disabling
>> EDNS
>
> This problem isn't caused by IPv6, fdic.gov has no name servers with
> IPv6 addresses. This looks more like a firewall problem on your end.
Is there a way to test to see if it is my firewalls? I recall reading that
using dig you can test your firewall rulesets to determine if it is properly
configured for NAT and to allow outbound IP fragmenting and out-of-order
fragmentation.
By the way, what would cause a DNS server to fragment packets or send out of
order? Aren't the packets typically small enough to fit within the typical 1500
imposed size?
>> Jan 22 16:05:08 NS1 named[7678]: [ID 873579 daemon.info] network
>> unreachable resolving
>> 'ADNS1.BERKELEY.EDU//IN':2001:500:2f::f#53
>
> This is odd. The IP address listed is for f-root. That adns1 name
> server does have an IPv6 address, but for some reason that address is
> not listed in the root zone file (currently).
>
>> Jan 22 16:05:08 NS1 named[7678]: [ID 873579 daemon.info] network
>> unreachable resolving 'ADNS2.BERKELEY.EDU/A/IN': 2001:500:2f::f#53
>
> Same here.
>
> Doug
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
IPv6 Lookups on BIND 9.5.1-P1 and .GOV Addresses
Hello;
I have two "DMZ" BIND/DNS servers running whose purpose is to allow lookups via
them from my otherwise incapable internal network.
I've recently upgraded only one of them from BIND 9.5.0-P2 to BIND 9.5.1-P1.
Both servers are running Sparc/Solaris 9.
Upon upgrading one to BIND 9.5.0-P2, which was in an effort to resolve failed
lookups for .gov sites, I found that the server was now attempting to resolve
using IPv6 style addresses. I am not able to find any such attempts in the
past at all from either server (See messages from BIND 9.5.1-P1 server below).
I've installed a newer db.root file by running dig then saving the output to
db.root. The newer file contained IPv6 style entries, which I've manually
removed (about the same time attempts ceased)
I've also tried to force any attempts at using IPv6 and what appear to be
issues resolving .gov domains in my named.conf like this:
options {
edns-udp-size 512;
max-udp-size 512;
listen-on-v6 { none; };
};
logging {
category lame-servers {null;};
category edns-disabled {null;};
};
The issues that I was seeing with .gov sites resulted in this type of error in
my logfile:
Jan 22 11:24:56 NS1 named[7678]: [ID 873579 daemon.info] too many timeouts
resolving 'www.fdic.gov/A' (in 'www.fdic.gov'?): disabling EDNS
Any help would be greatly appreciated, am I missing something obvious, or
perhaps I need to add something else into my configs?
Thank you,
.vp
Jan 22 16:05:08 NS1 named[7678]: [ID 873579 daemon.info] network unreachable
resolving 'ADNS1.BERKELEY.EDU//IN':2001:500:2f::f#53
Jan 22 16:05:08 NS1 named[7678]: [ID 873579 daemon.info] network unreachable
resolving 'ADNS2.BERKELEY.EDU/A/IN': 2001:500:2f::f#53
Jan 22 16:05:08 NS1 named[7678]: [ID 873579 daemon.info] network unreachable
resolving 'indom80.indomco.hk/A/IN': 2001:dc0:1:0:4777::140#53
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
