Re: DNS Blackholing
On 12/04/2012 02:44 AM, John Hascall wrote: We have found that RPZ works quite well for us. We have 366825 names in our RPZ zone at present and scaling thus far has been a non-issue.ot ( Likewise. We have 675k entries in an RPZ zone, and performance is fine. It's genuinely surprising how many hits we get on the Badness host (we rewrite the RPZ result to a CNAME aimed at an internal host) even from machines which are clean, with sensible users at the keyboard. There's a lot of slime on the internet that you can step in and track into the house... It also amazes me how many people will install spyware in exchange for a web browser search toolbar. Sigh... ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
R: OT - Dns test Q/A - [[]] - ok it's an OT, but no help?
-Messaggio originale- Da: bind-users-bounces+stefano.chiesa=wki...@lists.isc.org [mailto:bind-users-bounces+stefano.chiesa=wki...@lists.isc.org] Per conto di Chiesa Stefano Inviato: giovedì 29 novembre 2012 11.44 A: bind-users@lists.isc.org Oggetto: OT - Dns test Q/A - [[]] Hello all. I created an application to delegate zone management to collegues that are used to ask changes to that zones. I would set up a small zone administration test to verify a minimal dns knowledge (right use of main RR such A-CNAME-MX.) Can you suggest me a document from which I can extract few questions? Sorry for the OT and thanks in advance. Stefano Chiesa. Stefano Chiesa Wolters Kluwer Italia Network Specialist Strada 1, Palazzo F6 20090 Milanofiori Assago (Mi) - Italia Phone +39 0282476279 (20279 Voip) Fax +39 0282476815 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Update view without using 2 ip for each DNS Server
Hi all and thanks for existing!!! I have two DNS server 1 Master and 1 Slave both of them with 2 view: - 1 external view, used for resolve existing domain; - 1 internal view with recursion enabled. When there is an update Master-Slave, the process to update 2 view is the follow: - The First IP of the Master is connect with the corrispondig first IP of Slave; - The Second IP of the Master is connect with the corrispondig second IP of Slave; But in this way unfortunately I use 2 IP for each DNS server. I ask you this: Is it possible to update the second view when the firstl view is updated without having to assign 2 IPs like now ? Thanks in advance to anyone will help me. Best Regards. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Update view without using 2 ip for each DNS Server
On 4 Dec 2012, at 11:23, manman wrote: Is it possible to update the second view when the firstl view is updated without having to assign 2 IPs like now ? You could use a pair of TSIG secrets instead of a pair of IP addresses. There has been discussion about this on the list before, which you can find in the archives. The following links may help. https://lists.isc.org/pipermail/bind-users/2009-August/077479.html https://lists.isc.org/pipermail/bind-users/2012-June/087872.html https://lists.isc.org/pipermail/bind-users/2012-June/087933.html The example in the last one is extracted from a live configuration which I'm responsible for. Best regards, Niall O'Reilly University College Dublin IT Services ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Update view without using 2 ip for each DNS Server
On Tue, Dec 4, 2012 at 4:09 AM, Niall O'Reilly niall.orei...@ucd.ie wrote: On 4 Dec 2012, at 11:23, manman wrote: Is it possible to update the second view when the firstl view is updated without having to assign 2 IPs like now ? You could use a pair of TSIG secrets instead of a pair of IP addresses. There has been discussion about this on the list before, which you can find in the archives. The following links may help. https://lists.isc.org/pipermail/bind-users/2009-August/077479.html https://lists.isc.org/pipermail/bind-users/2012-June/087872.html https://lists.isc.org/pipermail/bind-users/2012-June/087933.html The example in the last one is extracted from a live configuration which I'm responsible for. If the ONLY reason for having two views is to allow recursion for local system, I think it would be much simpler and more easily maintained to use an ACL with the 'allow-recursion' option. Views provide a lot of benefits for more complex cases, but to just control recursion strikes my as over-kill. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Blackholing
On 12/4/2012 6:00 AM, John Hascall j...@iastate.edu wrote: We have found that RPZ works quite well for us. We have 366825 names in our RPZ zone at present and scaling thus far has been a non-issue. A question from the OP that has not yet been answered - Make the zones masters on all servers. What I did was to have a file in common storage accessible to each DNS server, and every 10 minutes a cron job would run to see if the file in common storage had been updated. If so, then the file was copied to the local disk, and an rndc reconfig command was issued to re-read the config file. Note that the 10-minute cron ran at a different minute on each server to insure that only one server was reloading at any given time. --Barry Finkel ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ISC Security Advisory: BIND 9 servers using DNS64 can be crashed by a crafted query
A specific query can cause BIND nameservers using DNS64 to exit with a REQUIRE assertion failure. CVE: CVE-2012-5688 Document Version:2.0 Posting date:04 Dec 2012 Program Impacted:BIND Versions affected: 9.8.0-9.8.4, 9.9.0-9.9.2 Severity:Critical Exploitable: Remotely Description: BIND 9 nameservers using the DNS64 IPv6 transition mechanism are vulnerable to a software defect that allows a crafted query to crash the server with a REQUIRE assertion failure. Remote exploitation of this defect can be achieved without extensive effort, resulting in a denial-of-service (DoS) vector against affected servers. Please Note: Support for DNS64 was added to BIND 9 in version 9.8.0. Therefore BIND 9 versions prior to 9.8.0 cannot be affected by this bug. Also, nameservers running versions 9.8.0 and greater can only be affected if DNS64 is turned on using the dns64 configuration statement. If you are not using DNS64 you are not at risk. For current information on which versions are actively supported, please see http://www.isc.org/software/bind/versions. Impact: Any BIND 9 nameserver configured to use DNS64 is vulnerable to this defect and can be crashed by any client machine from which it accepts queries. CVSS Score: 7.8 CVSS Equation: (AV:N/AC:L/Au:N/C:N/I:N/A:C) For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculatoradvversion=2vector=(AV:N/AC:L/Au:N/C:N/I:N/A:C) Workarounds: Only BIND 9 servers which are configured to use DNS64 are vulnerable. For those servers, disallowing queries from untrusted clients (a recommended practice in any case) will slightly mitigate a server's exposure, but no workarounds are available which will completely protect an affected server against exploitation of this bug. If you are using DNS64 either disable it or upgrade to a fixed version. Active exploits: No known active exploits. Solution: Upgrade to the patched release most closely related to your current version of BIND. These can all be downloaded from http://www.isc.org/downloads/all. BIND 9 version 9.8.4-P1 BIND 9 version 9.9.2-P1 Acknowledgements: ISC would like to thank BlueCat Networks for bringing this defect to our attention. Document Revision History: 1.0 - 27 November 2012 Advance Notification to Phase One. 1.1 - 03 December 2012 Notification to Phase Two and Phase Three 2.0 - 04 December 2012 Notification to Phase Four (Public) Related Documents: Japanese Translation: https://kb.isc.org/article/AA-00832 Spanish Translation: https://kb.isc.org/article/AA-00834 German Translation: https://kb.isc.org/article/AA-00833 See our BIND Security Matrix for a complete listing of Security Vulnerabilities and versions affected. http://www.isc.org/software/bind/security/matrix If you'd like more information on our Forum or product support please visit www.isc.org/software/guild or www.isc.org/support. Do you still have questions? Questions regarding this advisory should go to security-offi...@isc.org ISC Security Vulnerability Disclosure Policy: Details of our current security advisory policy and practice can be found here: https://www.isc.org/security-vulnerability-disclosure-policy This Knowledge Base article https://kb.isc.org/article/AA-00828 is the complete and official security advisory document. There is also a summary article located on our website and linking to here: https://www.isc.org/software/bind/advisories/cve-2012-5688 Legal Disclaimer: Internet Systems Consortium (ISC) is providing this notice on an AS IS basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors. (c) 2001-2012 Internet Systems Consortium ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.9.2-P1 is now available
Introduction BIND 9.9.2-P1 is a security-fix release, superceding BIND 9.9.2 as the latest production release of BIND 9.9. This document summarizes changes from BIND 9.9.1 to BIND 9.9.2-P1. Please see the CHANGES file in the source code release for a complete list of all changes. Download The latest versions of BIND 9 software can always be found on our web site at http://www.isc.org/downloads/all. There you will find additional information about each release, source code, and pre-compiled versions for Microsoft Windows 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. Security Fixes Prevents named from aborting with a require assertion failure on servers with DNS64 enabled. These crashes might occur as a result of specific queries that are received. (Note that this fix is a subset of a series of updates that will be included in full in BIND 9.8.5 and 9.9.3 as change #3388, RT #30996). [CVE-2012-5688] [RT #30792] A deliberately constructed combination of records could cause named to hang while populating the additional section of a response. [CVE-2012-5166] [RT #31090] Prevents a named assert (crash) when queried for a record whose RDATA exceeds 65535 bytes. [CVE-2012-4244] [RT #30416] Prevents a named assert (crash) when validating caused by using Bad cache data before it has been initialized. [CVE-2012-3817] [RT #30025] A condition has been corrected where improper handling of zero-length RDATA could cause undesirable behavior, including termination of the named process. [CVE-2012-1667] [RT #29644] ISC_QUEUE handling for recursive clients was updated to address a race condition that could cause a memory leak. This rarely occurred with UDP clients, but could be a significant problem for a server handling a steady rate of TCP queries. [CVE-2012-3868] [RT #29539 #30233] New Features Elliptic Curve Digital Signature Algorithm keys and signatures in DNSSEC are now supported per RFC 6605. [RT #21918] Introduces a new tool dnssec-checkds command that checks a zone to determine which DS records should be published in the parent zone, or which DLV records should be published in a DLV zone, and queries the DNS to ensure that it exists. (Note: This tool depends on python; it will not be built or installed on systems that do not have a python interpreter.) [RT #28099] Introduces a new tool dnssec-verify that validates a signed zone, checking for the correctness of signatures and NSEC/NSEC3 chains. [RT #23673] Adds configuration option max-rsa-exponent-size value; that can be used to specify the maximum rsa exponent size that will be accepted when validating [RT #29228] Feature Changes Improves OpenSSL error logging [RT #29932] nslookup now returns a nonzero exit code when it is unable to get an answer. [RT #29492] Bug Fixes Uses binary mode to open raw files on Windows. [RT #30944] When using DNSSEC inline signing with rndc signing -nsec3param, a salt value of - can now be used to indicate 'no salt'. [RT #30099] Prevents race conditions (address use after free) that could be encountered when named is shutting down and releasing structures used to manage recursive clients. [RT #30241] Static-stub zones now accept forward and fowarders options (often needed for subdomains of the zone referenced to override global forwarding options). These options are already available with traditional stub zones and their omission from zones of type static-stub was an inadvertent oversight. [RT #30482] Limits the TTL of signed RRsets in cache when their RRSIGs are approaching expiry. This prevents the persistence in cache of invalid RRSIGs in order to assist recovery from a situation where zone re-signing doesn't occur in a timely manner. With this change, named will attempt to obtain new RRSIGs from the authoritative server once the original ones have expired, and even if the TTL of the old records would in other circumstances cause them to be kept in cache for longer. [RT #26429] Corrects the syntax of isc_atomic_xadd() and isc_atomic_cmpxchg() which are employed on Itanium systems to speed up lock management by making use of atomic operations. Without the syntax correction it is possible that concurrent access to the same structures could accidentally occur with unpredictable results. [RT #25181] Improves OpenSSL error logging [RT #29932] The configure script now supports and detects libxml2-2.8.x correctly [RT #30440] The host command should no longer assert on some architectures and builds
BIND 9.8.4-P1 is now available
Introduction BIND 9.8.4-P1 is a security-fix release, superceding BIND 9.8.4 as the latest production release of BIND 9.8. This document summarizes changes from BIND 9.8.3 to BIND 9.8.4-P1. Please see the CHANGES file in the source code release for a complete list of all changes. Download The latest versions of BIND 9 software can always be found on our web site at http://www.isc.org/downloads/all. There you will find additional information about each release, source code, and pre-compiled versions for Microsoft Windows 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. Security Fixes Prevents named from aborting with a require assertion failure on servers with DNS64 enabled. These crashes might occur as a result of specific queries that are received. (Note that this fix is a subset of a series of updates that will be included in full in BIND 9.8.5 and 9.9.3 as change #3388, RT #30996). [CVE-2012-5688] [RT #30792] A deliberately constructed combination of records could cause named to hang while populating the additional section of a response. [CVE-2012-5166] [RT #31090] Prevents a named assert (crash) when queried for a record whose RDATA exceeds 65535 bytes [CVE-2012-4244] [RT #30416] Prevents a named assert (crash) when validating caused by using Bad cache data before it has been initialized. [CVE-2012-3817] [RT #30025] A condition has been corrected where improper handling of zero-length RDATA could cause undesirable behavior, including termination of the named process. [CVE-2012-1667] [RT #29644] New Features Elliptic Curve Digital Signature Algorithm keys and signatures in DNSSEC are now supported per RFC 6605. [RT #21918] Feature Changes Improves OpenSSL error logging [RT #29932] nslookup now returns a nonzero exit code when it is unable to get an answer. [RT #29492] Bug Fixes Uses binary mode to open raw files on Windows. [RT #30944] Static-stub zones now accept forward and fowarders options (often needed for subdomains of the zone referenced to override global forwarding options). These options are already available with traditional stub zones and their omission from zones of type static-stub was an inadvertent oversight. [RT #30482] Limits the TTL of signed RRsets in cache when their RRSIGs are approaching expiry. This prevents the persistence in cache of invalid RRSIGs in order to assist recovery from a situation where zone re-signing doesn't occur in a timely manner. With this change, named will attempt to obtain new RRSIGs from the authoritative server once the original ones have expired, and even if the TTL of the old records would in other circumstances cause them to be kept in cache for longer. [RT #26429] Corrects the syntax of isc_atomic_xadd() and isc_atomic_cmpxchg() which are employed on Itanium systems to speed up lock management by making use of atomic operations. Without the syntax correction it is possible that concurrent access to the same structures could accidentally occur with unpredictable results. [RT #25181] The configure script now supports and detects libxml2-2.8.x correctly [RT #30440] The host command should no longer assert on some architectures and builds while handling the time values used with the -w (wait forever) option. [RT #18723] Invalid zero settings for max-retry-time, min-retry-time, max-refresh-time, min-refresh-time will now be detected during parsing of named.conf and an error emitted instead of triggering an assertion failure on startup. [RT #27730] Removes spurious newlines from log messages in zone.c [RT #30675] When built with readline support (i.e. on a system with readline installed) nsupdate no longer terminates unexpectedly in interactive mode. [RT #29550] All named tasks that perform task-exclusive operations now share the same single task. Prior to this change, there was the possibility of a race condition between rndc operations and other functions such as re-sizing the adb hash table. If the race condition was encountered, named would in most cases terminate unexpectedly with an assert. [RT #29872] Ensures that servers are expired from the ADB cache when the timeout limit is reached so that their learned attributes can be refreshed. Prior to this change, servers that were frequently queried might never have their entries removed and reinitialized. This is of particular importance to DNSSEC-validating recursive servers that might erroneously set no-edns for an authoritative server following a period of intermittent
Re: Upstart job for BIND9
On 29/11/2012 11:25, Alexander Gurvitz wrote: Hi Alexander, I'm trying to run a bind9 from an upstart job instead of an init.d script. I'm a bit confused if I should expect fork or expect daemon. It seems to work with expect fork, though somehow I don't feel convinced. Actually, you don't need either. If you start BIND with the -f option, it remains in the foreground, and this is the best way to run daemons under upstart (and also OSX's launchd). See below. (Upstart must know how the daemon forks - if it forks once, expect fork should be specified, and if a daemon forks twice, it should be expect daemon. Then upstart will wait for that forkings and will monitor the final PID). Thanks in advance, Alexander Gurvitz, net-me.net P.S My /etc/init/bind.conf: start on runlevel [2345] stop on runlevel [!2345] pre-start script # dirs under /var/run can go away on reboots. mkdir -p /var/run/named chmod 775 /var/run/named chown root:bind /var/run/named /dev/null 21 || true end script exec /usr/sbin/named -u bind Replace this with exec /usr/sbin/named -f -u bind pre-stop exec rndc stop -p post-stop exec logger -p user.warning -t upstart-bind bind stopped expect fork Remove this expect fork. respawn respawn limit 3 10 kill timeout 30 console none Regards, Anand Buddhdev RIPE NCC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Blackholing
On Tue, Dec 04, 2012 at 09:45:07AM +, Phil Mayers wrote: On 12/04/2012 02:44 AM, John Hascall wrote: We have found that RPZ works quite well for us. We have 366825 names in our RPZ zone at present and scaling thus far has been a non-issue.ot ( Likewise. We have 675k entries in an RPZ zone, and performance is fine. It's genuinely surprising how many hits we get on the Badness host (we rewrite the RPZ result to a CNAME aimed at an internal host) even from machines which are clean, with sensible users at the keyboard. There's a lot of slime on the internet that you can step in and track into the house... It also amazes me how many people will install spyware in exchange for a web browser search toolbar. Sigh... Thanks, all. Sounds like RPZ is the way to go. Ray ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RHEL, Centos, Fedora rpm 9.9.2-p1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.five-ten-sg.com/util/bind-9.9.2-0.2.P1.fc18.src.rpm EL4: rpmbuild --rebuild --define 'dist .el4' \ bind-9.9.2-0.2.P1.fc18.src.rpm EL5: rpmbuild --rebuild --define 'dist .el5' \ bind-9.9.2-0.2.P1.fc18.src.rpm EL6: rpmbuild --rebuild --define 'dist .el6' \ bind-9.9.2-0.2.P1.fc18.src.rpm -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlC+0XMACgkQL6j7milTFsF2LwCfbx6RMeFmuPY9a+np//IpqcQ6 UmkAn1j7KTGRqvxVOpN7hSDXapQYxh8w =TeSE -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Blackholing
Hi All, Is there a way for RPZ zone file to act on domain AND subdomains without using two separate entries? At present I can only get them to match on one or the other unless I do example.comblah *.example.com blah I'm sure I've missed the obvious, but thought I'd ask ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
