Building bind with visual c++ express
I am trying to build Bind with Visual C++ Express 2005, but get 151 errors and 47 warnings.I already have OpenSSL built and prior to opening the DSW inside win32utils in Visual C++ Express 2005 I ran buildsetup.bat without problems I have the FrameworkSDK v6.0 installed and added the bin to the path and set the lib and include directories to refer to then ones located in the FrameworkSDK directory. Can Bind be built with Visual C++ Express 2005 and what will is required. Thanks in advance. Regards, Serge Fonville ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: dnsperf and BIND memory consumption
Hi all, I know this is a an old thread, but I wish to resurrect this in hopes to find answers.. 9.5 + threads on FreeBSD 7 is better performance wise, but there is this problem. 9.4 + threads on FreeBSD 7 is almost 50% of the performance, but there is no issues like this. 9.5 without threads doesnt have this issue but same in performance. more data below... its basically the same as Vinny's but im stressing out that 9.5 with threads has a good performance. hoping there's some shed of light as to where to get a patch for this issue. Thanks! - Ivan system: FreeBSD 7.0 RELEASE AMD64 Server is a Dell SC1435 with 4 CPU's, no Hyperthreading, 2GB of RAM and a 150GB RAID1 Dnsperf run from a different server on the same network segment over Gig-E 1. FreeBSD 7-RELEASE+BIND 9.4.2-P2 = 34,000 QPS, 94MB mem 2. FreeBSD 7-RELEASE+BIND 9.5.0-P2 threaded = 82,000 QPS, 1.5GIG mem! (and it wont stop until the test script ends, and does not go back to its original state) 3. FreeBSD 7-RELEASE+BIND 9.5.0-P2 non-threaded = 34,000 QPS, 95MB mem FIRST TEST # pkg_info | grep bind bind94-base-9.4.2.2 The BIND DNS suite with updated DNSSEC and threads # named -v BIND 9.4.2-P2 # ldd /usr/sbin/named /usr/sbin/named: libcrypto.so.5 => /lib/libcrypto.so.5 (0x8007a9000) libthr.so.3 => /lib/libthr.so.3 (0x800a3b000) libc.so.7 => /lib/libc.so.7 (0x800b51000) PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 13677 bind7 1000 93704K 77912K select 1 6:13 194.43% named Notes: 1. regardless how many times the script was used, memory consumption remained the same.. 2. a few seconds after the script was terminated... the CPU normalize.. PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 13677 bind7 980 93704K 77912K select 3 7:57 0.00% named SECOND TEST # pkg_info | grep bind bind95-base-9.5.0.2 The BIND DNS suite with updated DNSSEC and threads # named -v BIND 9.5.0-P2 # ldd /usr/sbin/named /usr/sbin/named: libcrypto.so.5 => /lib/libcrypto.so.5 (0x8007bf000) libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x800a51000) libz.so.4 => /lib/libz.so.4 (0x800c95000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x800da9000) libm.so.5 => /lib/libm.so.5 (0x800fa2000) libthr.so.3 => /lib/libthr.so.3 (0x8010bc000) libc.so.7 => /lib/libc.so.7 (0x8011d2000) PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 67304 bind7 990 1524M 1509M select 1 2:10 200.54% named Notes: 1. memory consumption of 1.5G after only running the script 26 times. thats 1.3 million authoritative queries. 2. the script was terminated and the memory consumption was still the same. 3RD TEST (very similar to 1st test) Hardware Details CPU: Quad-Core AMD Opteron(tm) Processor 2350 (1995.01-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! usable memory = 2133491712 (2034 MB) avail memory = 2058821632 (1963 MB) # uname -a FreeBSD jaljeb.infoweapons.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC FreeBSD 7.0 RELEASE AMD64 Server is a Dell SC1435 with 4 CPU's, Hyperthreading disabled, 2GB of RAM and a 150GB RAID1 Dnsperf run from a different server on the same network segment over Gig-E --- On Fri, 8/8/08, Vinny Abello <[EMAIL PROTECTED]> wrote: > From: Vinny Abello <[EMAIL PROTECTED]> > Subject: RE: dnsperf and BIND memory consumption > To: "JINMEI Tatuya / 神明達哉" <[EMAIL PROTECTED]> > Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Date: Friday, August 8, 2008, 2:33 AM > > -Original Message- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > > Behalf Of JINMEI Tatuya / > > Sent: Thursday, August 07, 2008 3:56 AM > > To: Vinny Abello > > Cc: [EMAIL PROTECTED] > > Subject: Re: dnsperf and BIND memory consumption > > > > At Thu, 7 Aug 2008 00:58:23 -0400, > > Vinny Abello <[EMAIL PROTECTED]> wrote: > > > > > OK. I've recompiled BIND 9.5.0-P2 (from > ports) without threads > > > enabled. I no longer see the memory leak at all. > I'm running dnsperf > > > and I see a constant of 18MB which is much more > reasonable for what > > > I am doing. For me it's easy to reproduce. > Some more information > > > that may help reproduce it: > > > > > FreeBSD 7.0 STABLE AMD64 (cvsup'ed within the > past week) > > > BIND 9.5.0-P2 installed via ports with threads > enabled > > > Server is a Dell PowerEdge 2850 with 2 CPU's, > Hyperthreading > > disabled, 4GB of RAM and a 36GB RAID1 array on a Perc4 > controller (LSI > > MegaRAID chipset) > > > Dnsperf run from a different server on the same > network segment over > > Gig-E > > > > This looks quite similar to the one we heard before. > I suspect this > > is due to some bad interac
Re: rfc1918 ns records coming from internet are queried?
>> I'm looking for a way to set a policy that named wont
>> query
>> rfc1918 nameserver addresses returned from a non-rfc1918 query.
>> Would this be
>> a bad policy?
>
> You could use netmasks with your server statements, like this:
>
> server 10.0.0.0/8 {
> bogus yes;
> };
>
> server 172.16.0.0/12 {
> bogus yes;
> };
>
> server 192.168.0.0/16 {
> bogus yes;
> };
>
> You could even then override this for specific servers in those
> ranges, by using statements without netmasks (or more specific
> netmasks).
Thanks, that is a workaround that solves most of the problem, but
unfortunately it is not usable. It requires that a list of the local
organizations dns servers are maintained which is unfeasible (large, global,
disparate organization). Also, IP collision between local dns servers and
rogue rfc1918 responses will still send queries to the local dns servers.
A good border router will do a few things for network hygiene. It will filter
incoming packets that have a source address from the internal network, and it
will filter outgoing packets that don't have a source IP in the internal
network.
A DNS server should do a similar thing: it will not send rfc1918 queries to
the internet, and it will discard rfc1918 responses from the internet.
It appears Bind can't do this and I'm fine with that. This email is simply to
clear up any confusion about what the issue is.
ds
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
The queries from the resolver to internal name servers caused by
incorrect referrals for outside domains *should* cause no harm.
However, if you're concerned, it's pretty easy to set up a more secure
infrastructure. Put a resolver (resolving name server) at the edge of
your network (in a DMZ, presumably) that knows nothing of internal
domains (nor IP address space). It refuses to send queries to private
addresses, but will answer queries coming from them. Then set up an
internal resolver that knows about your private namespace; for any
outside domains, it forwards to the server on the edge of your
network. Have client machines send queries to the internal resolver,
not to the edge resolver.
This way, there is complete separation between inside and outside
resolution. A referral from an outside domain with a glue record
pointing inside is ignored.
Chris Buxton
Professional Services
Men & Mice
On Nov 26, 2008, at 10:43 AM, David Sparks wrote:
I'm looking for a way to set a policy that named wont
query
rfc1918 nameserver addresses returned from a non-rfc1918 query.
Would this be
a bad policy?
You could use netmasks with your server statements, like this:
server 10.0.0.0/8 {
bogus yes;
};
server 172.16.0.0/12 {
bogus yes;
};
server 192.168.0.0/16 {
bogus yes;
};
You could even then override this for specific servers in those
ranges, by using statements without netmasks (or more specific
netmasks).
Thanks, that is a workaround that solves most of the problem, but
unfortunately it is not usable. It requires that a list of the local
organizations dns servers are maintained which is unfeasible (large,
global,
disparate organization). Also, IP collision between local dns
servers and
rogue rfc1918 responses will still send queries to the local dns
servers.
A good border router will do a few things for network hygiene. It
will filter
incoming packets that have a source address from the internal
network, and it
will filter outgoing packets that don't have a source IP in the
internal network.
A DNS server should do a similar thing: it will not send rfc1918
queries to
the internet, and it will discard rfc1918 responses from the internet.
It appears Bind can't do this and I'm fine with that. This email is
simply to
clear up any confusion about what the issue is.
ds
___
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: rfc1918 ns records coming from internet are queried?
> A good border router will do a few things for network hygiene. It will filter > incoming packets that have a source address from the internal network, and it > will filter outgoing packets that don't have a source IP in the internal > network. > > A DNS server should do a similar thing: it will not send rfc1918 queries to > the internet, and it will discard rfc1918 responses from the internet. A border router knows what is "inside" and "outside" your network, while a DNS server does not. Important difference. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
--- On Thu, 11/27/08, David Sparks <[EMAIL PROTECTED]> wrote:
> From: David Sparks <[EMAIL PROTECTED]>
> Subject: Re: rfc1918 ns records coming from internet are queried?
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Date: Thursday, November 27, 2008, 7:43 AM
> >> I'm looking for a way to set a policy that
> named wont
> >> query
> >> rfc1918 nameserver addresses returned from a
> non-rfc1918 query.
> >> Would this be
> >> a bad policy?
> >
> > You could use netmasks with your server statements,
> like this:
> >
> > server 10.0.0.0/8 {
> > bogus yes;
> > };
> >
> > server 172.16.0.0/12 {
> > bogus yes;
> > };
> >
> > server 192.168.0.0/16 {
> > bogus yes;
> > };
> >
> > You could even then override this for specific servers
> in those
> > ranges, by using statements without netmasks (or more
> specific
> > netmasks).
>
> Thanks, that is a workaround that solves most of the
> problem, but
> unfortunately it is not usable. It requires that a list of
> the local
> organizations dns servers are maintained which is
> unfeasible (large, global,
> disparate organization). Also, IP collision between local
> dns servers and
> rogue rfc1918 responses will still send queries to the
> local dns servers.
>
>
> A good border router will do a few things for network
> hygiene. It will filter
> incoming packets that have a source address from the
> internal network, and it
> will filter outgoing packets that don't have a source
> IP in the internal network.
>
> A DNS server should do a similar thing: it will not send
> rfc1918 queries to
> the internet, and it will discard rfc1918 responses from
> the internet.
>
> It appears Bind can't do this and I'm fine with
> that. This email is simply to
> clear up any confusion about what the issue is.
This is an operational issue. The owner of 'ad.rice.edu' be responsible not to
publish RRs pointing to RFC 1918 addresses, especially the glue.
split DNS or split views should have been done from their end.
>
> ds
> ___
> 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: rfc1918 ns records coming from internet are queried?
[EMAIL PROTECTED] wrote: >> A good border router will do a few things for network hygiene. It will >> filter >> incoming packets that have a source address from the internal network, and it >> will filter outgoing packets that don't have a source IP in the internal >> network. >> >> A DNS server should do a similar thing: it will not send rfc1918 queries to >> the internet, and it will discard rfc1918 responses from the internet. > > A border router knows what is "inside" and "outside" your network, while > a DNS server does not. Important difference. You're missing the point. This is not about inside and outside networks, it is about rfc1918 responses from internet queries. ds ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
> However, if you're concerned, it's pretty easy to set up a more secure
> infrastructure. Put a resolver (resolving name server) at the edge of
> your network (in a DMZ, presumably) that knows nothing of internal
> domains (nor IP address space). It refuses to send queries to private
> addresses, but will answer queries coming from them. Then set up an
> internal resolver that knows about your private namespace; for any
> outside domains, it forwards to the server on the edge of your
> network. Have client machines send queries to the internal resolver,
> not to the edge resolver.
That will work but I was hoping for something like:
view "internet" {
filter-rfc1918-responses yes;
...
However I'm not concerned. :)
ds
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
On Nov 26, 2008, at 11:49 AM, David Sparks wrote:
However, if you're concerned, it's pretty easy to set up a more
secure
infrastructure. Put a resolver (resolving name server) at the edge of
your network (in a DMZ, presumably) that knows nothing of internal
domains (nor IP address space). It refuses to send queries to private
addresses, but will answer queries coming from them. Then set up an
internal resolver that knows about your private namespace; for any
outside domains, it forwards to the server on the edge of your
network. Have client machines send queries to the internal resolver,
not to the edge resolver.
That will work but I was hoping for something like:
view "internet" {
filter-rfc1918-responses yes;
...
However I'm not concerned. :)
You can in fact set up the environment I described using views. Just
have the private view forward to the internet view. The following
resolving name server will ignore referrals to private name servers
for outside names; note that it's missing the masters list definition
named "private-auth-servers", plus the options statement, but is
otherwise complete.
acl "private" {
10/8;
172.16/12;
192.168/16;
# does not include 127/8
};
view "private" {
match-clients { private; };
# forward unknown names to the internet view:
forward only;
forwarders { 127.0.0.1; };
# stub, slave, or forward zones for the private namespace:
zone "private.zone" {
type stub;
masters { private-auth-servers; };
file "stub.private.zone";
forwarders { }; # disable forwarding for stub zones
};
};
view "internet" {
server 10/8 { bogus yes; };
server 172.16/12 { bogus yes; };
server 192.168/16 { bogus yes; };
allow-query { 127.0.0.1; };
};
Chris Buxton
Professional Services
Men & Mice
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
> > A border router knows what is "inside" and "outside" your network, while > > a DNS server does not. Important difference. > > You're missing the point. This is not about inside and outside networks, it > is about rfc1918 responses from internet queries. I'm afraid I have seen too many organizations using a mix of public and RFC1918 IP addresses on the "inside". Thus I don't believe that you can differentiate based on RFC1918 addresses or not on a general basis. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
[EMAIL PROTECTED] wrote: >>> A border router knows what is "inside" and "outside" your network, while >>> a DNS server does not. Important difference. >> You're missing the point. This is not about inside and outside networks, it >> is about rfc1918 responses from internet queries. > > I'm afraid I have seen too many organizations using a mix of public and > RFC1918 IP addresses on the "inside". Thus I don't believe that you can > differentiate based on RFC1918 addresses or not on a general basis. This is incorrect, you can always differentiate based on rfc1918 addresses. When a 3rd party gives you a rfc1918 address it is invalid. ds ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsperf and BIND memory consumption
At Wed, 26 Nov 2008 10:34:59 -0800 (PST), ivan jr sy <[EMAIL PROTECTED]> wrote: > I know this is a an old thread, but I wish to resurrect this in > hopes to find answers.. > > 9.5 + threads on FreeBSD 7 is better performance wise, but there is > this problem. > > 9.4 + threads on FreeBSD 7 is almost 50% of the performance, but > there is no issues like this. 9.5 without threads doesnt have this > issue but same in performance. > more data below... its basically the same as Vinny's but im > stressing out that 9.5 with threads has a good performance. > > hoping there's some shed of light as to where to get a patch for this issue. Unfortunately, I've never succeeded in reproducing this problem. If possible, can I see your test configuration (including named.conf and query data)? Also, just out of curiosity (I actually don't think this matters), do you see the same problem if you build named by hand, not from FreeBSD ports? --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ISC BIND
Hi, why I have BIND from 4 and 8 releases and from born of 9 release I lifted up till 9.5.1b3 that is working fine. I tried to compile and run ISC BIND 9.6.0b1 with some configure switches and /etc/rc.d/init.d/rc-script statements. Why I get back no errors inside ISC BIND files but in the end ISC BIND 9.6.0b1 does not remain as daemon serving user requests?!. --- Alberto Colosi IBM Global Business Services Sistemi Informativi S.P.A. IT NetWork & Security Department *-* *-* *-* SECURITY IS EVERYONE'S BUSINESS Member of IBM Information Security WW CoP ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND
Look at your log files, commonly in /var/log/ Did you define other logfiles in your named.conf that you had working with 9.51b3? -david Alberto Colosi/SI/RM/GSI/it wrote: > > Hi, why I have BIND from 4 and 8 releases and from born of 9 release I > lifted up till 9.5.1b3 that is working fine. > > I tried to compile and run ISC BIND 9.6.0b1 with some configure > switches and /etc/rc.d/init.d/rc-script statements. > > Why I get back no errors inside ISC BIND files but in the end ISC BIND > 9.6.0b1 does not remain as daemon serving user requests?!. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND
For sure as IBM or Microsoft or an org so big could have!.
My named.conf is really full of ACL and confs.
my logging channels are: (but I should find something inside one of
them or /var/log/messages ;) mainly from 9.0 till 9.5.1b3
is working! what is different inside 9.6
logging{
channel sec{
file "/var/named/log/sec.log" versions 2 size 2m;
print-time yes;
print-category yes;
print-severity yes;
};
channel in_out{
file "/var/named/log/xfer.log" versions 2 size 2m;
print-time yes;
print-category yes;
print-severity yes;
};
channel named_log{
file "/var/named/log/general.log" versions 2 size 2m;
print-time yes;
print-category yes;
print-severity yes;
};
channel upd_log{
file "/var/named/log/update.log" versions 2 size 2m;
print-time yes;
print-category yes;
print-severity yes;
};
channel log_lame{
file "/var/named/log/lame.log" versions 2 size 2m;
print-time yes;
print-category yes;
print-severity yes;
};
channel dnssec_log {
file "/var/named/log/dnssec.log" versions 2 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity debug 3;
};
channel edns {
file "/var/named/log/edns.log" versions 2 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity debug 3;
};
channel "querylog" {
file "/var/named/log/queries.log" versions 2 size 2m;
print-time yes;
print-category yes;
print-severity yes;
};
---
Alberto Colosi
IBM Global Business Services
Sistemi Informativi S.P.A.
IT NetWork & Security Department
*-* *-* *-*
SECURITY IS EVERYONE'S BUSINESS
Member of
IBM Information Security WW CoP
David Ford <[EMAIL PROTECTED]>
27/11/2008 00.31
To
Alberto Colosi/SI/RM/GSI/it <[EMAIL PROTECTED]>
cc
bind-users@lists.isc.org
Subject
Re: ISC BIND
Look at your log files, commonly in /var/log/
Did you define other logfiles in your named.conf that you had working
with 9.51b3?
-david
Alberto Colosi/SI/RM/GSI/it wrote:
>
> Hi, why I have BIND from 4 and 8 releases and from born of 9 release I
> lifted up till 9.5.1b3 that is working fine.
>
> I tried to compile and run ISC BIND 9.6.0b1 with some configure
> switches and /etc/rc.d/init.d/rc-script statements.
>
> Why I get back no errors inside ISC BIND files but in the end ISC BIND
> 9.6.0b1 does not remain as daemon serving user requests?!.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
In message <[EMAIL PROTECTED]>, David Sparks writes: > [EMAIL PROTECTED] wrote: > >>> A border router knows what is "inside" and "outside" your network, while > >>> a DNS server does not. Important difference. > >> You're missing the point. This is not about inside and outside networks, > it > >> is about rfc1918 responses from internet queries. > > > > I'm afraid I have seen too many organizations using a mix of public and > > RFC1918 IP addresses on the "inside". Thus I don't believe that you can > > differentiate based on RFC1918 addresses or not on a general basis. > > This is incorrect, you can always differentiate based on rfc1918 addresses. > When a 3rd party gives you a rfc1918 address it is invalid. Except it may not be. Networks are way too complicated to make such general assumptions. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND
Is there any indication about why named shuts down immediately in those logfiles? -david Alberto Colosi/SI/RM/GSI/it wrote: > > For sure as IBM or Microsoft or an org so big could have!. > My named.conf is really full of ACL and confs. > > my logging channels are: (but I should find something inside one > of them or /var/log/messages ;) mainly from 9.0 till > 9.5.1b3 is working! what is different inside 9.6 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND
no, if not I was not writing here. I compile and run bing from version 4 and I have compiled and runned each bind version one by one... till today I can't count how many ;) --- Alberto Colosi IBM Global Business Services Sistemi Informativi S.P.A. IT NetWork & Security Department *-* *-* *-* SECURITY IS EVERYONE'S BUSINESS Member of IBM Information Security WW CoP David Ford <[EMAIL PROTECTED]> 27/11/2008 00.52 To Alberto Colosi/SI/RM/GSI/it <[EMAIL PROTECTED]> cc bind-users@lists.isc.org Subject Re: ISC BIND Is there any indication about why named shuts down immediately in those logfiles? -david Alberto Colosi/SI/RM/GSI/it wrote: > > For sure as IBM or Microsoft or an org so big could have!. > My named.conf is really full of ACL and confs. > > my logging channels are: (but I should find something inside one > of them or /var/log/messages ;) mainly from 9.0 till > 9.5.1b3 is working! what is different inside 9.6 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND
In message <[EMAIL PROTECTED]>, David Ford writes: > Is there any indication about why named shuts down immediately in those > logfiles? > > -david One can always start named using "named -g " which will send the log messages to the screen and stop named becoming a daemon. If named is stopping immediately this is often the quickest way to see what is going wrong. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
