Re: dnsperf and BIND memory consumption

2008-12-18 Thread Dmitry Rybin
JINMEI Tatuya / 神明達哉 wrote:
> At Mon, 15 Dec 2008 09:53:23 +0300,
> Dmitry Rybin  wrote:
> 
>> Thank's to JINMEI Tatuya for support.
>> I have over 40 views, defined in named.conf, max-memory for cache -
>> 32Mb. Named daemon allocate over 2 Gb per 24 hours of work.
> 
> Each view has a separate cache DB.  So if each of these 40 views
> really needs to cache a certain amount of data, a footprint of 2GB is
> not a surprising situation, even with a 32MB of max-cache-size for
> each view.


OK. I Just limit max-cache-size 16MB.
16MB * 50 views = over 800 MB of memory.

How much total memory bind can accrue?


--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Testing my configuration

2008-12-18 Thread Stephane Bortzmeyer
On Wed, Dec 17, 2008 at 12:36:44PM +0100,
 Holger Honert  wrote 
 a message of 113 lines which said:

> check out dig eith the zone-transfer option (man dig):

He asked for information about a DOMAIN NAME, which may or may not be
also a ZONE. If it is not a zone, zone transfer wont' work.

Using:

dig @your.name.server ANY dom.ain.name.example

would be more sensible.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: dnsperf and BIND memory consumption

2008-12-18 Thread Dmitry Rybin
JINMEI Tatuya / 神明達哉 wrote:
>>
>>> Have you any ideas how to limit memory usage?
>> Unfortunately not, unless you can consolidate the caching views to a
>> small number of views.
> 
> If you can allow the multiple views to share a single cache, one
> possibility is to create a separate "localhost" view as the single
> caching view and forward all recursive queries to that view:
> 

I add this lines in named.conf
clients IP in this view can't resolve recursive queries.

view "localhost" {
match-clients { ::1; };
};

view "view7" {

max-cache-ttl 0;
zone "." {
type forward;
forwarders { ::1; };
forward only;
};
};


Trying to use
view "localhost" {
match-clients { ::1; };
  zone "." {
  type hint;
  file "named.root";
  };
};

has the same result.

> view "localhost" {
>   match-clients { ::1; };
> };
> 
> view "view1" {
>   match-clients { view1-clients; };
> 
>   max-cache-ttl 0;  //disable caching to save memory
>   zone "." {
>   type forward;
>   forwarders { ::1; };
>   forward only;
>   };
>   // add other authoritative zones if necessary
> };
> 
> view "view2" {
>   match-clients { view2-clients; };
>   max-cache-ttl 0;
>   zone "." {
>   type forward;
>   forwarders { ::1; };
>   forward only;
>   };
>   // add other authoritative zones if necessary
> };
> 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: 50 million records under one domain using Bind

2008-12-18 Thread Vinay Y S
>> I believe he is talking on one server not spread out over several
>> servers. I think he is trying to see the limit on one server as to how
>> many records it could serve reliably.

Can the records of a single domain be spread across multiple machines
(sharding?) using bind?

> I believe that the limiting factor is not going to be the size of the
> database, but how fast the machine can process network requests.  Ie,
> how many queries per second;  If the machine can only handle 10k
> queries per second, then the MOST it will see is 10k qps even if 11k
> qps are coming in.

Is there any good tool to benchmark this metric? Upon searching on
Internet, I've found queryperf so far which I'll try.

-- 
Vinay Y S
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: 50 million records under one domain using Bind

2008-12-18 Thread Vinay Y S
> If you plan to use a plain zone file for the 50 million records,
> rather than using a separate backend database, you may want to

What are the backend database options available? Is bind-sdb active
developed and is it production ready?

> precompile your zone file by named-compilezone.  It will make load
> time twice as short as it is with the plain text format.

Thanks for the tip. I'll give it a shot. Currently text file with 50
million records is taking 10 minutes to load on a machine with 16GB
RAM and dual quad-core processors.

-- 
Vinay Y S
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Bind 9.5 configuration doubt

2008-12-18 Thread Barry Margolin
In article ,
 Stacey Jonathan Marshall  wrote:

> Reinaldo Matukuma wrote:
> > Hello.
> >> I'm in doubt about defining a SOA record to a zone.
> >> Is this correct and valid?
> >>
> >> $TTL86400
> >> $ORIGIN teste.com.
> >> @   1D IN SOA   @ root (
> >>42  ; serial (d.
> >> adams)
> >>3H  ; refresh
> >>15M ; retry
> >>1W  ; expiry
> >>1D ); minimum
> >>
> >>1D IN NS@
> >>1D IN A 192.168.1.3
> >> www IN A192.168.1.2
> >>
> >>
> >> This is just a example. In fact, my zone will be a public zone with 
> >> valid
> >> ip addresses.
> >>
> >> My doubt is if it's correct specify the "owner" and "source-dname" with
> >> "@", once "@" denotes the current origin. If I used $ORIGIN like in 
> >> example
> >> then I suppose that "@" will define just "teste.com" too.
> >>
> >> But I make this test into a interna DNS server and look as a valid
> >> configuration.
> >>
> >
> I've seen a number of configurations where the $ORIGIN is set and then 
> the '@' sign is used as the first position in the SOA.
> But I've never understood that as I thought that the idea of the @ was 
> to use the ORIGIN as defined in the 'zone' statement.  Either way the 
> ISC training suggested that the @ not be used in practice as its often 
> looked-over and inappropriately copied to other files.  Therefore I 
> would suggest that placing the '@' character in other locations really 
> isn't a good idea.  think about the inverse address, the above isn't 
> going to work there.

"@" represents whatever the current origin is.  If you have no $ORIGIN 
directives then this defaults to the one in the "zone" statement in the 
named.conf.  If you do have $ORIGIN, @ will be replaced with the most 
recent origin specified that way.

The benefit of "@" is not having to retype the zone name throughout the 
file.  For subdomains you achieve this by entering relative names (with 
no trailing "."), but if you want to use the zone name (or origin) 
itself you need to use "@" to achieve this.

There's nothing wrong with using it on the RHS, although this is 
relatively uncommon because it's unusual to point anything to the zone 
itself except maybe as a synonym for www..  The above example uses 
the zone name as the nameserver, which is quite unusual I think.

While copying records like this may sometimes be inappropriate, it also 
can make things easier.  It's not uncommon to have lots of domains that 
are all identical, and you can do this by using the same file for all of 
them.  This works as long as the zone file only uses relative names.

-- 
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: bind memory usage

2008-12-18 Thread JINMEI Tatuya / 神明達哉
At Wed, 17 Dec 2008 23:36:31 -0200,
Leonardo Rodrigues Magalhães  wrote:

> > I can confirm bind 9.4 does run on an (IBM, not Intel) 486-SCL/2 with 16 MB.
> > That cpu can address no more than 16 MB.

> i have tried running 9.4.3 instead of 9.5.0-P2  and got odd results.

I suspect you should compare 9.4.3 with 9.5.1 (currently rc).  There
are many differences between pre-and-post P1/P2 versions.  So you may
be comparing an apple with an orange (even though you may already be
comparing different fruits by comparing 9.4 with 9.5, though).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: dnsperf and BIND memory consumption

2008-12-18 Thread JINMEI Tatuya / 神明達哉
At Thu, 18 Dec 2008 17:14:06 +0300,
Dmitry Rybin  wrote:

> > If you can allow the multiple views to share a single cache, one
> > possibility is to create a separate "localhost" view as the single
> > caching view and forward all recursive queries to that view:
> 
> I add this lines in named.conf
> clients IP in this view can't resolve recursive queries.

It's hard to help with this too simplified problem description...

Note that my previous config example is just a conceptual one.  You
should probably adjust it for your own environment.

> view "localhost" {
> match-clients { ::1; };
> };

One obvious point in this example is that named has to listen on ::1,
which is not the case for the default configuration.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: 50 million records under one domain using Bind

2008-12-18 Thread JINMEI Tatuya / 神明達哉
At Thu, 18 Dec 2008 22:01:37 +0530,
"Vinay Y S"  wrote:

> > If you plan to use a plain zone file for the 50 million records,
> > rather than using a separate backend database, you may want to
> 
> What are the backend database options available? Is bind-sdb active
> developed and is it production ready?

Check DLZ.  I don't know much about it, and can't provide specific
answers.  I'm sure some others in this list can.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


BIND 9.5.1rc2 is now available.

2008-12-18 Thread Mark Andrews

BIND 9.5.1rc2 is now available.

BIND 9.5.1rc2 is a maintenance release candidate for BIND 9.5.

BIND 9.5.1rc2 can be downloaded from

ftp://ftp.isc.org/isc/bind9/9.5.1rc2/bind-9.5.1rc2.tar.gz

The PGP signature of the distribution is at

ftp://ftp.isc.org/isc/bind9/9.5.1rc2/bind-9.5.1rc2.tar.gz.asc
ftp://ftp.isc.org/isc/bind9/9.5.1rc2/bind-9.5.1rc2.tar.gz.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.5.1rc2/bind-9.5.1rc2.tar.gz.sha512.asc

The signature was generated with the ISC public key, which is
available at 

A binary kit for Windows XP and Window 2003 is at

ftp://ftp.isc.org/isc/bind9/9.5.1rc2/BIND9.5.1rc2.zip
ftp://ftp.isc.org/isc/bind9/9.5.1rc2/BIND9.5.1rc2.debug.zip

The PGP signature of the binary kit for Windows XP and Window 2003 is at

ftp://ftp.isc.org/isc/bind9/9.5.1rc2/BIND9.5.1rc2.zip.asc
ftp://ftp.isc.org/isc/bind9/9.5.1rc2/BIND9.5.1rc2.zip.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.5.1rc2/BIND9.5.1rc2.zip.sha512.asc
ftp://ftp.isc.org/isc/bind9/9.5.1rc2/BIND9.5.1rc2.debug.zip.asc
ftp://ftp.isc.org/isc/bind9/9.5.1rc2/BIND9.5.1rc2.debug.zip.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.5.1rc2/BIND9.5.1rc2.debug.zip.sha512.asc

Changes since 9.5.0.

--- 9.5.1rc2 released ---

2513[bug]   Fix windows cli build. [RT #19062]

2510.   [bug]   "dig +sigchase" could trigger REQUIRE failures.
[RT #19033]

2509.   [bug]   Specifying a fixed query source port was broken.
[RT #19051]

2504.   [bug]   Address race condition in the socket code. [RT #18899]

--- 9.5.1rc1 released ---

2498.   [bug]   Removed a bogus function argument used with
ISC_SOCKET_USE_POLLWATCH: it could cause compiler
warning or crash named with the debug 1 level
of logging. [RT #18917]

2496.   [bug]   Add sanity length checks to NSID option. [RT #18813]

2495.   [bug]   Tighten RRSIG checks. [RT #18795]

2494.   [bug]   isc/radix.h, dns/sdlz.h and dns/dlz.h were not being
installed. [RT #18826]

2493.   [bug]   The linux capabilites code was not correctly cleaning
up after itself. [RT #18767]

2490.   [port]  aix: work around a kernel bug where IPV6_RECVPKTINFO
is cleared when IPV6_V6ONLY is set. [RT #18785]

2489.   [port]  solaris: Workaround Solaris's kernel bug about
/dev/poll:
http://bugs.opensolaris.org/view_bug.do?bug_id=6724237
Define ISC_SOCKET_USE_POLLWATCH at build time to enable
this workaround. [RT #18870]

2487.   [bug]   Give TCP connections longer to complete. [RT #18675]

2485.   [bug]   Change update's the handling of obscured RRSIG
records.  Not all orphand DS records were being
removed. [RT #18828]

2482.   [port]  libxml2: support versions 2.7.* in addition
to 2.6.*. [RT #18806]

2479.   [bug]   xfrout:covers was not properly initalized. [RT #18801]

2478.   [bug]   'addresses' could be used uninitalized in
configure_forward(). [RT #18800]

2476.   [doc]   ARM: improve documentation for max-journal-size and
ixfr-from-differences. [RT #15909] [RT #18541]

--- 9.5.1b3 released ---

2475.   [bug]   LRU cache cleanup under overmem condition could purge
particular entries more aggressively. [RT #17628]

2474.   [bug]   ACL structures could be allocated with insufficient
space, causing an array overrun. [RT #18765]

2473.   [port]  linux: raise the limit on open files to the possible
maximum value before spawning threads; 'files'
specified in named.conf doesn't seem to work with
threads as expected. [RT #18784]

2472.   [port]  linux: check the number of available cpu's before
calling chroot as it depends on "/proc". [RT #16923]

2471.   [bug]   named-checkzone was not reporting missing mandatory
glue when sibling checks were disabled. [RT #18768]

2470.   [bug]   Elements of the isc_radix_node_t could be incorrectly
overwritten.  [RT# 18719]

2469.   [port]  solaris: Work around Solaris's select() limitations.
[RT #18769]

2468.   [bug]   Resolver could try unreachable servers multiple times.
[RT #18739]

2467.   [bug]   Failure of fcntl(F_DUPFD) wasn't logged. [RT #18740]

2466.   [do

Re: Stats collection script for BIND 9.5 (and greater?)

2008-12-18 Thread JINMEI Tatuya / 神明達哉
At Tue, 16 Dec 2008 10:38:49 +0100,
Alexander Gall  wrote:

> Yes, if that assumption is correct, I don't see a big problem sticking
> to version 1.0 for the new format in 9.6.0 and 9.5.1.  Still, if you
> do manage to get this particular change in (I guess it would be
> extremely localized and probably doesn't require any actual code
> change at all) that would be preferrable, IMHO.

After an internal discussion, we've decided to bump the version number
to 2.0.  It's not included in 9.6.0rc2, but we don't plan to issue
another RC for 9.6.0 just for this.  The same change will appear in
9.5.1 (not included in 9.5.1rc2).  Hopefully this won't happen a
different type of compatibility issues.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users