Re: Threaded bind on CentOS
On Mon, Feb 28, 2011 at 09:30:10PM +, Jack Tavares wrote: Recap: running named with -n 1 will spin up one worker thread and approx 4 other threads. Hello, Is there an official discussion or explanation of what these other threads do? official explanation can be found in BIND source code. $ grep -r isc_thread_create bind-9.8.0rc1/ shows me this (stripped): 1. lib/isc/unix/socket.c - this thread handles dispatching of all incomming queries. The thread reads DNS packet from socket and send it to pool of worker threads which process it (DNSSEC validation, authoritative/recursive response etc.) 2. lib/isc/timer.c - this is the timer thread. It handles all timer events, i.e. asynchronously put specified actions to pool of worker threads 3. the main named process is the third thread other threads, called worker threads are created in lib/isc/task.c. So number of threads (as shown via `ps -eLf |grep named`) is always number of worker threads + 3. Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ISC BIND 9.8.0 is now available
__ Introduction BIND 9.8.0 is the first production release of BIND 9.8. This document summarizes changes from BIND 9.7 to BIND 9.8. Please see the CHANGES file in the source code release for a complete list of all changes. Download The latest development versions of BIND 9 software can always be found on our web site at http://www.isc.org/downloads/development. There you will find additional information about each release, source code, and some pre-compiled versions for certain operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. New Features 9.8.0 * The ADB hash table stores informations about which authoritative servers to query about particular domains. Previous versions of BIND had the hash table size as a fixed value. On a busy recursive server, this could lead to hash table collisions in the ADB cache, resulting in degraded response time to queries. Bind 9.8 now has a dynamically scalable ADB hash table, which helps a busy server to avoid hash table collisions and maintain a consistent query response time. [RT #21186] * BIND now supports a new zone type, static-stub. This allows the administrator of a recursive nameserver to force queries for a particular zone to go to IP addresses of the administrator's choosing, on a per zone basis, both globally or per view. I.e. if the administrator wishes to have their recursive server query 192.0.2.1 and 192.0.2.2 for zone example.com rather than the servers listed by the .com gTLDs, they would configure example.com as a static-stub zone in their recursive server. [RT #21474] * BIND now supports Response Policy Zones, a way of expressing reputation in real time via specially constructed DNS zones. See the draft specification here: http://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt [RT #21726] * BIND 9.8.0 now has DNS64 support. named synthesizes records from specified A records if no record exists. IP6.ARPA CNAME records will be synthesized from corresponding IN-ADDR.ARPA. [RT #21991/22769] * Dynamically Loadable Zones (DLZ) now support dynamic updates. Contributed by Andrew Tridgell of the Samba Project. [RT #22629] * Added a dlopen DLZ driver, allowing the creation of external DLZ drivers that can be loaded as shared objects at runtime rather than having to be linked with named at compile time. Currently this is switched on via a compile-time option, configure --with-dlz-dlopen. Note: the syntax for configuring DLZ zones is likely to be refined in future releases. Contributed by Andrew Tridgell of the Samba Project. [RT #22629] * named now retains GSS-TSIG keys across restarts. This is for compatibility with Microsoft DHCP servers doing dynamic DNS updates for clients, which don't know to renegotiate the GSS-TSIG session key when named restarts. [RT #22639] * There is a new update-policy match type external. This allows named to decide whether to allow a dynamic update by checking with an external daemon. Contributed by Andrew Tridgell of the Samba Project. [RT #22758] * There have been a number of bug fixes and ease of use enhancements for configuring BIND to support GSS-TSIG [RT #22629/22795]. These include: + Added a tkey-gssapi-keytab option. If set, dynamic updates will be allowed for any key matching a Kerberos principal in the specified keytab file. tkey-gssapi-credential is no longer required and is expected to be deprecated. Contributed by Andrew Tridgell of the Samba Project. [RT #22629] + It is no longer necessary to have a valid /etc/krb5.conf file. Using the syntax DNS/hostname@REALM in nsupdate is sufficient for to correctly set the default realm. [RT #22795] + Documentation updated new gssapi configuration options (new option tkey-gssapi-keytab and changes in tkey-gssapi-credential and tkey-domain behavior). [RT 22795] + DLZ correctly deals with NULL zone in a query. [RT 22795] + TSIG correctly deals with a NULL tkey-creator. [RT 22795] * A new test has been added to check the apex NSEC3 records after DNSKEY records have been added via dynamic update. [RT #23229] * RTT banding (randomized server selection on queries) was introduced in BIND releases in 2008, due to the Kaminsky cache poisoning bug. Instead of always picking the
Re: inconsistency dnssec debuguers response and writing conseil for new areas zone
Le mardi 01 mars 2011 à 09:34 +0100, Laurent Bauer a écrit : On 28/02/2011 23:35, fakessh @ wrote: 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 You will have to ask your registrar to submit the DS to the parent zone, just as you have to ask your registrar my registrar OVH not implement dnssec for yet when you want to change the NS for your zone. i use other dns secondary that does not come from ovh use isc dlv If they are already implementing DNSSEC, ask them what you are supposed to provide (the KSK or the DS only) ; for the submission in isc dlv we have their key to submit and we get a new text record it is easy to initiate I guess there must be a FAQ not FAQ to explicite for implement a DS record somewhere on the control panel. is the repeat isc dlv seems to accept the flag DS in my case i have to a file dsset-fakessh.eu but the file contains two keys DS and i don't know which to use Eurid is already ready for DS submission, so you will be able to complete the whole chain of trust for your .eu domain, if your registrar is DNSSEC ready. 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
Re: inconsistency dnssec debuguers response and writing conseil for new areas zone
On 03/01/11 20:17, fakessh @ wrote: is the repeat isc dlv seems to accept the flag DS in my case i have to a file dsset-fakessh.eu but the file contains two keys DS and i don't know which to use The DS you have are both for the same key, only one is SHA1 and other SHA256. You could try any of them, but see below. ISC DLV accepts keys, you have to create an account, add your zone and keys for it. I remember having some trouble trying to add DS records, but DNSKEY worked fine. Of course the zone has to be signed using that key, and ISC asks you to add a TXT record at dlv.your.zone (or something similar) to prove your ability to modify the zone. The procedure is simple and well defined. And about OVH - I don't know if it's related, but I've asked Polish OVH how about providing DNSSEC, as .pl is planned to be signed mid-year, and they've answered me they will probably be ready. This might, or might not be related to providing DNSSEC by other OVH branches and for other registries. Torinthiel ___ 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
as I now know what key DS uses. I logged into my account and I moved isc dlv record SHA1 DS, and I thought to receive a new record or something like that. well no reply from the ISC is : A corresponding DNSKEY already exists for this record. All comments are welcome to help me find a solution nb : I publish on my blog a little article on dnssec http://fakessh.eu/2011/02/16/faire-marcher-dnssec-sur-son-serveur/ Le mardi 01 mars 2011 à 21:00 +0100, Torinthiel a écrit : On 03/01/11 20:17, fakessh @ wrote: is the repeat isc dlv seems to accept the flag DS in my case i have to a file dsset-fakessh.eu but the file contains two keys DS and i don't know which to use The DS you have are both for the same key, only one is SHA1 and other SHA256. You could try any of them, but see below. ISC DLV accepts keys, you have to create an account, add your zone and keys for it. I remember having some trouble trying to add DS records, but DNSKEY worked fine. Of course the zone has to be signed using that key, and ISC asks you to add a TXT record at dlv.your.zone (or something similar) to prove your ability to modify the zone. The procedure is simple and well defined. And about OVH - I don't know if it's related, but I've asked Polish OVH how about providing DNSSEC, as .pl is planned to be signed mid-year, and they've answered me they will probably be ready. This might, or might not be related to providing DNSSEC by other OVH branches and for other registries. Torinthiel ___ 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
Please join us for our BIND 9.8 Feature Webinar and Roadmap (Tomorrow)
Hi Team, ISC will be conducting two BIND 9.8 Feature Webinars on March 2nd at 8:00 am PST and 4:00 pm PST. Please up using this URL: http://www.isc.org/webinars This is a new feature ISC, where we are educating our constituents as each new BIND feature is released. Stay tuned for BIND 9.9, 9.10, etc :-) Thanks, Barry -- Barry Raveendran Greene President CEO Internet Systems Consortium (ISC) Phone: +1 650 423 1311 Mobile: +1 408 218 4669 E-mail: bgre...@isc.org ___ 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
In message 1299012754.7.430.camel@localhost.localdomain, fakessh @ writ es: as I now know what key DS uses. I logged into my account and I moved isc dlv record SHA1 DS, and I thought to receive a new record or something like that. well no reply from the ISC is : A corresponding DNSKEY already exists for this record. Because there are already DLV records for the key in the DLV. ;; ANSWER SECTION: fakessh.eu.dlv.isc.org. 3529IN DLV 47103 3 2 68096942650C1DD89D5BE43A9EEA05BA9C20F09EDC55309F4F1CD348 4D8ED07B fakessh.eu.dlv.isc.org. 3529IN DLV 47103 3 1 CFEA04C5B918359273D6BAC07AE7F2DF5225E357 And the zone itself validates (ad=1). ; DiG 9.6.0-APPLE-P2 fakessh.eu soa +adflag ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4080 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;fakessh.eu.IN SOA ;; ANSWER SECTION: fakessh.eu. 38400 IN SOA r13151.ovh.net. postmaster.fakessh.eu. 2011022802 10800 3600 604800 38400 ;; Query time: 2521 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Mar 2 08:45:13 2011 ;; MSG SIZE rcvd: 89 All comments are welcome to help me find a solution nb : I publish on my blog a little article on dnssec http://fakessh.eu/2011/02/16/faire-marcher-dnssec-sur-son-serveur/ Le mardi 01 mars 2011 =C3=A0 21:00 +0100, Torinthiel a =C3=A9crit : On 03/01/11 20:17, fakessh @ wrote: is the repeat isc dlv seems to accept the flag DS in my case i have to a file dsset-fakessh.eu but the file contains two keys DS and i don't know which to use The DS you have are both for the same key, only one is SHA1 and other SHA256. You could try any of them, but see below. ISC DLV accepts keys, you have to create an account, add your zone and keys for it. I remember having some trouble trying to add DS records, but DNSKEY worked fine. Of course the zone has to be signed using that key, and ISC asks you to add a TXT record at dlv.your.zone (or something similar) to prove your ability to modify the zone. The procedure is simple and well defined. And about OVH - I don't know if it's related, but I've asked Polish OVH how about providing DNSSEC, as .pl is planned to be signed mid-year, and they've answered me they will probably be ready. This might, or might not be related to providing DNSSEC by other OVH branches and for other registries. Torinthiel ___ 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=3Dgetsearch=3D0x092164A7 --=-hAV62QMSnDEL5t7IF2op Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBNbVyStXI/OwkhZKcRApHLAJ9mpVDpLbdoXNJE2HWrZtEMP5nkOQCfQHxF OWD+2cnsCQvmY1sJsLmpZoA= =3tB9 -END PGP SIGNATURE- --=-hAV62QMSnDEL5t7IF2op-- --===8423262514623441036== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --===8423262514623441036==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
I got a trouble ticket on this too. From the looks of things, Cisco is using GSSes to load-balance this site. GSSes return SERVFAIL if all of the resources behind the load-balancer are down (which it determines via a heartbeat mechanism). So I think this is a simple case of a website (or cluster) going down. It was down earlier today, then up again, as of this writing, it is down again. DNS doesn't really have a response code of requested resource not available, so SERVFAIL is Cisco's closest approximation. It has the drawback, however, of often making other sorts of problems appear to be DNS problems. That's just a cross that we DNS admins have to bear... - Kevin On 3/1/2011 4:08 PM, Mike Bernhardt wrote: I should add that tools.cisco.com was resolvable at one time, so either Cisco's behavior has changed, or our firewall's behavior has changed. We obviously haven't upgraded our BIND version in a while (9.4.3P3), so I don't think the problem is BIND. -Original Message- From: Mike Bernhardt [mailto:bernha...@bart.gov] Sent: Tuesday, March 01, 2011 12:40 PM To: bind-users@lists.isc.org Subject: Help with unresolvable domain (subdomain, actually) For some reason, we can no longer resolve tools.cisco.com. there are several clues to the problem but I can't put them together. Here is some dig output. I know that the time stamps don't all match up below, but the results are typical: [root@ns1 ~]# dig +trace -b 148.165.3.10 tools.cisco.com ; DiG 9.4.3-P3 +trace -b 148.165.3.10 tools.cisco.com ;; global options: printcmd . 90550 IN NS i.root-servers.net. . 90550 IN NS h.root-servers.net. . 90550 IN NS e.root-servers.net. . 90550 IN NS d.root-servers.net. . 90550 IN NS j.root-servers.net. . 90550 IN NS k.root-servers.net. . 90550 IN NS l.root-servers.net. . 90550 IN NS g.root-servers.net. . 90550 IN NS f.root-servers.net. . 90550 IN NS a.root-servers.net. . 90550 IN NS m.root-servers.net. . 90550 IN NS c.root-servers.net. . 90550 IN NS b.root-servers.net. ;; Received 512 bytes from 148.165.3.10#53(148.165.3.10) in 0 ms com.172800 IN NS l.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. ;; Received 505 bytes from 198.41.0.4#53(a.root-servers.net) in 13 ms cisco.com. 172800 IN NS ns1.cisco.com. cisco.com. 172800 IN NS ns2.cisco.com. ;; Received 101 bytes from 192.54.112.30#53(h.gtld-servers.net) in 154 ms tools.cisco.com.86400 IN NS rcdn9-14p-dcz05n-gss1.cisco.com. tools.cisco.com.86400 IN NS rtp5-dmz-gss1.cisco.com. tools.cisco.com.86400 IN NS sjck-dmz-gss1.cisco.com. tools.cisco.com.86400 IN NS cax01-bb14-dcz01n-gss1.cisco.com. ;; Received 226 bytes from 64.102.255.44#53(ns2.cisco.com) in 75 ms ;; Received 33 bytes from 72.163.4.28#53(rcdn9-14p-dcz05n-gss1.cisco.com) in 47 ms Now, focusing in on rtp5-dmz-gss1.cisco.com for further analysis (just picked it out of the group): [root@ns1 ~]# dig -b 148.165.3.10 @rtp5-dmz-gss1.cisco.com tools.cisco.com ; DiG 9.4.3-P3 -b 148.165.3.10 @rtp5-dmz-gss1.cisco.com tools.cisco.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 5165 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;tools.cisco.com. IN A ;; Query time: 75 msec ;; SERVER: 64.102.246.5#53(64.102.246.5) ;; WHEN: Tue Mar 1 12:22:57 2011 ;; MSG SIZE rcvd: 33 Here is
Re: Help with unresolvable domain (subdomain, actually)
See my other post. This is designed-in behavior for Cisco GSSes, since there is no service unavailable, try again later RCODE. - Kevin On 3/1/2011 4:25 PM, Mark Andrews wrote: Ring Cisco and complain that their nameservers are broken for the zone. ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 13389 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;tools.cisco.com. IN A ;; Query time: 204 msec ;; SERVER: 72.163.4.28#53(rcdn9-14p-dcz05n-gss1.cisco.com) ;; WHEN: Wed Mar 2 08:23:59 2011 ;; MSG SIZE rcvd: 33 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
In message 4d6d7268.1080...@chrysler.com, Kevin Darcy writes: I got a trouble ticket on this too. From the looks of things, Cisco is using GSSes to load-balance this site. GSSes return SERVFAIL if all of the resources behind the load-balancer are down (which it determines via a heartbeat mechanism). So I think this is a simple case of a website (or cluster) going down. It was down earlier today, then up again, as of this writing, it is down again. DNS doesn't really have a response code of requested resource not available, so SERVFAIL is Cisco's closest approximation. It has the drawback, however, of often making other sorts of problems appear to be DNS problems. That's just a cross that we DNS admins have to bear... - Kevin Then the load balancer should return default records or 0.0.0.0/:: to indicate the name is good but doesn't currently have a address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
