Re: Optimising rndc reload times on a slave server with 50,000 zones
5 files in a single directory will make difficult for any filesystem. I would recommend breaking that out into groups of less than 1 per directory. For better performance, separate them onto directories that are on different spindles; the parallelization of seek (and with thousands of small files that can each be read in one or two reads, your disks will spend a lot of this time seeking) should show noticeable performance improvement. Do only some of the zones update at any given 15 minute cycle? If so, you may show an even bigger improvement by only reloading those that will have changed. On Sat, Feb 26, 2011 at 8:56 PM, Dennis Perisa dennis.per...@gmail.com wrote: Hi folks, I'm looking for suggestions to substantially improve reload times on a slave that is serving 50,000 zones (mostly customer zones). 'rndc reload' is being executed on the slave every 15 minutes. Due to the large number of zones to trawl through, the reload process is causing intermittent outages and/or significant delays to zone transfers. Here are some ideas I have: - use rndc reconfig instead - separate zone files into separate dirs to improve O/S performance (currently, all zone files are in a single dir) Are these viable options? Any other thoughts/suggestions? This is expected to be a short-term fix while we consider brute force approach of throwing more cpu/mem/IO at this. DP ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Optimising rndc reload times on a slave server with 50,000 zones
On 2/27/2011 1:15 AM, Dennis Perisa wrote: Thanks Doug. Yes, helps a lot. And yes, this is to handle adding new zones. Look into BIND 9.7.2 or newer and the rndc addzone capabilities. Solves the problem without needing to reload/restart/reconifg at all. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: inconsistency dnssec debuguers response and writing conseil for new areas zone
Den 28. feb. 2011 kl. 17.46 skrev fakessh @: for example the test shows me some time http://dnssec-debugger.verisignlabs.com/nicolaspichot.fr the results are not consistent with my expectations Well, I see a few different errors for that domain: I don't see any DS records for your domain when I query the fr. nameservers. I don't know how it's handled in that TLD but I guess you somehow need to tell your registrar about your KSK, so they can put in the correct DS record. The delegation of your domain looks a bit odd, the fr. nameservers claims you have: - ns0.xname.org - ns1.xname.org - ns1.novacrea.fr - r13151.ovh.net ...but if I query any of these, I'm told there's also ns2.xname.org At the moment, ns1.xname.org gives an older version of the zone, with a serial number 2011021401 Check the list of errors on http://dnsviz.net/d/nicolaspichot.fr/dnssec/ especially about missing key 12961. -- Regards Eivind Olsen eiv...@aminor.no ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tools for searching/removing stale keys
On Thu, 24 Feb 2011, Antonio Querubin wrote: Has anyone come up with scripts/tools for removing stale zone-signing keys but leaving key-signing keys which are in the same directory alone? Take a look at http://seatpost.its.uiowa.edu/bind_stuff/ It's a collection of scripts for dealing with routine DNS tasks related to multiple views DNSSEC. The check-keys script might be close to what you're after. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec validation, managed keys, and chaos view
On 2011.02.28 00.20, Evan Hunt wrote:
if i comment out dnssec-lookaside, or the chaos view, things seem to work
ok. i'm wondering what i can do to further diagnose what is happening.
below is my configuration, with the (presumably) uninteresting bits
removed. i'm using 9.7.1, courtesy of ubuntu 10.10.
Try putting dnssec-lookaside auto; into all the non-chaos view
stanzas separately, and leaving it out of the chaos one.
even with dnssec-lookaside auto; only in the non-chaos view stanzas, it
seems to still want to do something relating to the chaos view:
28-Feb-2011 14:12:44.702 general: info: managed-keys-zone ./IN/internal:
loaded serial 2
28-Feb-2011 14:12:44.703 general: info: zone
5.0.1.0.1.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN/external: loaded serial
2010061300
28-Feb-2011 14:12:44.703 general: info: zone
1.4.2.c.0.7.4.0.1.0.0.2.ip6.arpa/IN/external: loaded serial 2010061300
28-Feb-2011 14:12:44.705 general: info: zone bitrate.net/IN/external:
loaded serial 2010061300
28-Feb-2011 14:12:44.706 general: info: zone dipswitch.net/IN/external:
loaded serial 2010121001
28-Feb-2011 14:12:44.706 general: info: zone
groundnoise.net/IN/external: loaded serial 2010061301
28-Feb-2011 14:12:44.706 general: info: zone sjva1991.org/IN/external:
loaded serial 2010061300
28-Feb-2011 14:12:44.707 general: info: zone thielsen.org/IN/external:
loaded serial 2010061300
28-Feb-2011 14:12:44.784 general: info: managed-keys-zone ./IN/external:
loaded serial 8
28-Feb-2011 14:12:44.784 general: info: zone bind/CH/chaos: loaded
serial 2009113000
28-Feb-2011 14:12:44.784 general: error: managed-keys-zone ./CH/chaos:
loading from master file
/etc/bind/keys/managed/5d5bddb577102d0a960bcf6fea9050c10fe5e9feddcb5c2170ccab872db9ee87.mkeys
failed: file not found
28-Feb-2011 14:12:44.785 general: critical:
rdata/generic/keydata_65533.c:222: REQUIRE(keydata-common.rdclass ==
rdclass) failed, back trace
28-Feb-2011 14:12:44.785 general: critical: #0 0x424290 in ??
28-Feb-2011 14:12:44.785 general: critical: #1 0x119773 in ??
28-Feb-2011 14:12:44.785 general: critical: #2 0xee4276 in ??
28-Feb-2011 14:12:44.785 general: critical: #3 0xee55b9 in ??
28-Feb-2011 14:12:44.785 general: critical: #4 0xf691d8 in ??
28-Feb-2011 14:12:44.785 general: critical: #5 0xf69d39 in ??
28-Feb-2011 14:12:44.785 general: critical: #6 0xf6ba24 in ??
28-Feb-2011 14:12:44.785 general: critical: #7 0x44219a in ??
28-Feb-2011 14:12:44.785 general: critical: #8 0x442400 in ??
28-Feb-2011 14:12:44.785 general: critical: #9 0x13c2cb in ??
28-Feb-2011 14:12:44.785 general: critical: #10 0xdb6cc9 in ??
28-Feb-2011 14:12:44.785 general: critical: #11 0x7d869e in ??
28-Feb-2011 14:12:44.785 general: critical: exiting (due to assertion
failure)
modified config:
/etc/bind named-checkconf -p
options {
bindkeys-file /etc/bind/keys/dnssec/bind.keys;
blackhole {
bogon;
};
directory /var/cache/bind;
dump-file /var/log/named/named.dump;
interface-interval 0;
listen-on-v6 {
::1/128;
};
managed-keys-directory /etc/bind/keys/managed;
memstatistics-file /var/log/named/named.memstats;
recursing-file /var/log/named/namedrecursing;
statistics-file /var/log/named/named.stats;
allow-query-cache-on {
localhost;
private_lan;
};
allow-recursion {
localhost;
private_lan;
};
allow-recursion-on {
localhost;
private_lan;
};
minimal-responses yes;
allow-transfer {
localhost;
slaves;
};
zone-statistics yes;
};
view internal in {
match-clients {
localhost;
private_lan;
};
zone example.com {
type master;
file /var/lib/bind/internal/example.com;
allow-update {
key ddns-key-1;
};
};
dnssec-lookaside auto ;
};
view external in {
match-clients {
any;
};
zone example.com {
type master;
file /etc/bind/zones/external/example.com;
};
dnssec-lookaside auto ;
};
view chaos chaos {
match-clients {
any;
};
zone . {
type hint;
file /dev/null;
};
zone bind {
type master;
file /etc/bind/zones/system/db.bind;
};
allow-query {
localhost;
};
allow-transfer {
none;
};
};
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec validation, managed keys, and chaos view
even with dnssec-lookaside auto; only in the non-chaos view stanzas, it seems to still want to do something relating to the chaos view: Ah well, thanks for checking. Turns out managed keys cross-link between the views incorrectly. There's a fix in review, I'll send you a patch later today. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Threaded bind on CentOS
Recap: running named with -n 1 will spin up one worker thread and approx 4 other threads. Is there an official discussion or explanation of what these other threads do? -- Thanks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: inconsistency dnssec debuguers response and writing conseil for new areas zone
Le lundi 28 février 2011 à 20:14 +0100, Laurent Bauer a écrit : Eivind Olsen wrote: Well, I see a few different errors for that domain: I don't see any DS records for your domain when I query the fr. nameservers. I don't know how it's handled in that TLD but I guess you somehow need to tell your registrar about your KSK, so they can put in the correct DS record. This is not handled yet. The .FR zone has been signed since september 2010, but submitting DS for child zones will be supported later this year. See http://operations.afnic.fr for more information. thank you for taking the trouble to answer me. I therefore rest with my chain of security provided by isc dlv and wait for the DS flag a chance to insert later. but I wonder one thing I'm not a registar I am a passionate individual, how I'm going to do later for the flag for my DS .eu domain and .fr? I do not know and still do not understand how Laurent ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 signature.asc Description: Ceci est une partie de message numériquement signée ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
why dig +short for NS doesn't get the result
server1:/var/cache/bind# dig ox.test.nsbeta.info ns @localhost +short # got nothing here server1:/var/cache/bind# dig ox.test.nsbeta.info ns @localhost ; DiG 9.6-ESV-R3 ox.test.nsbeta.info ns @localhost ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53460 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ox.test.nsbeta.info. IN NS ;; AUTHORITY SECTION: ox.test.nsbeta.info.20222 IN NS dwdns1.nsbeta.info. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Mar 1 11:51:21 2011 ;; MSG SIZE rcvd: 58 I have setup the NS for ox.test.nsbeta.info zone, why dig +short gets nothing but dig does get the result? Thanks. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: why dig +short for NS doesn't get the result
On 03/01/11 04:55, terry wrote: server1:/var/cache/bind# dig ox.test.nsbeta.info ns @localhost +short # got nothing here server1:/var/cache/bind# dig ox.test.nsbeta.info ns @localhost ; DiG 9.6-ESV-R3 ox.test.nsbeta.info ns @localhost ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53460 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ox.test.nsbeta.info. IN NS ;; AUTHORITY SECTION: ox.test.nsbeta.info.20222 IN NS dwdns1.nsbeta.info. Look where the answer is ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Mar 1 11:51:21 2011 ;; MSG SIZE rcvd: 58 I have setup the NS for ox.test.nsbeta.info zone, why dig +short gets nothing but dig does get the result? +short instructs dig to only write extract of ANSWER section. your reply is in authorative section. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
