Looking for a pointer on getting reverse mapping with DDNS to work with DHCPD Named.
Problem.
===
I'm working on getting a DHCP / Bind / DDNS server set up. When a client
receives
an IP address lease, I want the forward / reverese zones files updated
so
name lookups behave appropriately / as expected.
After a couple of days of fiddling with this (and lots of Google / ISC
searches), I'm
still unable to get the IP address lease for a workstation to be
auto-entered into
my reverse db.dhcp.coloradostudios.com zones file.
I'm getting either of the following errors:
dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. to
proccilapxp.dhcp.coloradostudios.com: bad DNS key
dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. to
proccilapxp.dhcp.coloradostudios.com: timed out
It apparently has something to do with how I'm using the keys to tell /
let dhcpd
update the DNS zones file, but I'll be 'derned if I can figure out what's
breaking.
Any pointers on what to look for in order to get this working would be
appreciated.
Thanks,
Jim
I've attached the current configs in the hopes this is merely a simple
syntactical error on my part.
--
Jim Bucks - IT Director
Colorado Studios http://www.coloradostudios.com, Mobile TV
Grouphttp://www.mobiletvgroup.com,
HDNet http://www.hd.net, AXS.tv http://www.axs.tv/
8269 E. 23rd Ave. Denver, CO 80238 Main 303-388-8500
jbu...@coloradostudios.comDirect 303-542-5520
Centos 64 bit ver 6.4
dhcpd ver 4.1.1-P1
bind var BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6.3
All the above are on one server.
Problem.
===
I'm working on getting a DHCP / Bind / DDNS server set up. When a client
receives
an IP address lease, I want the forward / reverese zones files updated so
name lookups behave appropriately / as expected.
After a couple of days of fiddling with this (and lots of Google / ISC
searches), I'm
still unable to get the IP address lease for a workstation to be auto-entered
into
my reverse db.dhcp.coloradostudios.com zones file.
I'm getting either of the following errors:
dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. to
proccilapxp.dhcp.coloradostudios.com: bad DNS key
dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. to
proccilapxp.dhcp.coloradostudios.com: timed out
It apparently has something to do with how I'm using the keys to tell / let
dhcpd
update the DNS zones file, but I'll be 'derned if I can figure out what's
breaking.
Any pointers on what to look for in order to get this working would be
appreciated.
Thanks,
Jim
Here are all my configuration logfiles. They are 99% the same as my real
files.
The only change was to replace the secret string. Syntactically, there are
no changes.
cat /etc/dhcp/dhcpd.conf
==
#
# DHCP Server Configuration file.
# see /usr/share/doc/dhcp*/dhcpd.conf.sample
# see 'man 5 dhcpd.conf'
#
# Sept 19, 2012 jbucks
# /etc/dhcp/dhcdp.conf file - prepping for dhcp rollout
#
#
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# # Separate multiple interfaces with spaces, e.g. eth0 eth1.
INTERFACES=eth1;
# Use this to send dhcp log messages to a different log file (you also
# # have to hack syslog.conf to complete the redirection).
log-facility local6;
authoritative;# Sets the server authoritative for my network
ddns-update-style interim;# Activates Dynamic DNS
update-static-leases-on; # Ensures static leases get entered
#ignore client-updates;
# Use this command line to generate the key. Only need the key string inside
these files.
# dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER
#
# It is very important to use the exact same keystring and name on both
dhcpd.conf and named.conf for this to work.
key DHCP_UPDATER { # This line specifies the key name
#algorithm HMAC-MD5.SIG-ALG.REG.INT; # This line specifies the encryption
algorithm best to stick with HMAC-MD5
algorithm HMAC-MD5; # This line specifies the encryption
algorithm best to stick with HMAC-MD5
secret x99yzTXeOPQLKsd==; # Finally the key statement itself
};
subnet 172.10.0.0 netmask 255.255.0.0 {
# --- default gateway
option routers 172.10.5.1;
option subnet-mask 255.255.0.0;
option nis-domain coloradostudios.com;
option domain-name coloradostudios.com;
option domain-name-servers 172.10.5.5;
option time-offset -25200; # Mountain Standard Time
# option time-offset -18000; # Eastern Standard Time
# option ntp-servers 192.168.1.1;
# option netbios-name-servers 192.168.1.1;
# --- Selects point-to-point node (default is hybrid). Don't change this unless
# -- you understand Netbios very well
# option
Re: Looking for a pointer on getting reverse mapping with DDNS to work with DHCPD Named.
Hi Jim,
I'm getting either of the following errors:
dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. to
proccilapxp.dhcp.coloradostudios.com
http://proccilapxp.dhcp.coloradostudios.com: bad DNS key
dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. to
proccilapxp.dhcp.coloradostudios.com
http://proccilapxp.dhcp.coloradostudios.com: timed out
it's actually the line above those :)
Mar 26 07:56:59 dns04 dhcpd: db.172.10.20.: host unknown.
which is caused by the zone statements in dhcpd.conf:
zone 20.10.172.in-addr.arpa. {
primary db.172.10.20.;
key DHCP_UPDATER;
#file internal/db.172.10.20;
}
'primary' should be the address of the DNS server to send the update
message to (not the filename of the zone - dhcpd asks the nameserver to
make the updates on its behalf, it doesn't alter the zone file itself).
so you probably want:
zone 20.10.172.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
#file internal/db.172.10.20;
}
(and similar a change for the forward zone).
Graham
--
Graham Clinch
Systems Programmer,
Information Systems Services,
Lancaster University
signature.asc
Description: OpenPGP digital 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
ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named
Note: This email advisory is provided for your information. The most up to date advisory information will always be at: https://kb.isc.org/article/AA-00871 please use this URL for the most up to date advisory information. --- A critical defect in BIND 9 allows an attacker to cause excessive memory consumption in named or other programs linked to libdns. CVE: CVE-2013-2266 Document Version: 2.0 Posting date: 26 March 2013 Program Impacted: BIND Versions affected:Unix versions of BIND 9.7.x, 9.8.0 - 9.8.5b1, 9.9.0 - 9.9.3b1. (Windows versions are not affected. Versions of BIND 9 prior to BIND 9.7.0 (including BIND 9.6-ESV) are not affected. BIND 10 is not affected.) Severity: Critical Exploitable: Remotely Description: A flaw in a library used by BIND 9.7, 9.8, and 9.9, when compiled on Unix and related operating systems, allows an attacker to deliberately cause excessive memory consumption by the named process, potentially resulting in exhaustion of memory resources on the affected server. This condition can crash BIND 9 and will likely severely affect operation of other programs running on the same machine. Please Note: Versions of BIND 9.7 are beyond their end of life (EOL) and no longer receive testing or security fixes from ISC. However, the re-compilation method described in the Workarounds section of this document will prevent exploitation in BIND 9.7 as well as in currently supported versions. For current information on which versions are actively supported, please seehttp://www.isc.org/software/bind/versions. Additional information is available in the CVE-2013-2266 FAQ and Supplemental Information article in the ISC Knowledge base, https://kb.isc.org/article/AA-00879. Impact: Intentional exploitation of this condition can cause denial of service in all authoritative and recursive nameservers running affected versions of BIND 9 [all versions of BIND 9.7, BIND 9.8.0 through 9.8.5b1 (inclusive) and BIND 9.9.0 through BIND 9.9.3b1 (inclusive)]. Additionally, other services which run on the same physical machine as an affected BIND server could be compromised as well through exhaustion of system memory. Programs using the libdns library from affected versions of BIND are also potentially vulnerable to exploitation of this bug if they can be forced to accept input which triggers the condition. Tools which are linked against libdns (e.g. dig) should also be rebuilt or upgraded, even if named is not being used. 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: Patched versions are available (see the Solutions: section below) or operators can prevent exploitation of this bug in any affected version of BIND 9 by compiling without regular expression support. Compilation without regular expression support: BIND 9.7 (all versions), BIND 9.8 (9.8.0 through 9.8.5b1), and BIND 9.9 (9.9.0 through 9.9.3b1) can be rendered completely safe from this bug by re-compiling the source with regular expression support disabled. In order to disable inclusion of regular expression support: - After configuring BIND features as desired using the configure script in the top level source directory, manually edit the config.h header file that was produced by the configure script. - Locate the line that reads #define HAVE_REGEX_H 1 and replace the contents of that line with #undef HAVE_REGEX_H. - Run make clean to remove any previously compiled object files from the BIND 9 source directory, then proceed to make and install BIND normally. Active exploits: No known active exploits. Solution: Compile BIND 9 without regular expression support as described in the Workarounds section of this advisory or upgrade to the patched release most closely related to your current version of BIND. These can be downloaded fromhttp://www.isc.org/downloads/all. BIND 9 version 9.8.4-P2 BIND 9 version 9.9.2-P2 Acknowledgements: ISC would like to thank Matthew Horsfall of Dyn, Inc. for discovering this bug and bringing it to our attention. Document Revision History: 1.0 Phase One - Advance Notification, 11 March 2013 1.1 Phase Two Three, 25 March 2013 2.0 Notification to Public (Phase Four), 26 March 2013 Related Documents: Japanese
Re: querying TLD nameservers - limitations
On Sun, Mar 24, 2013 at 04:55:13PM -0700, blrmaani blrma...@gmail.com wrote a message of 17 lines which said: I am developing a monitoring script for internal use and this requires extensive querying of TLD nameservers (a .. m).tld servers. [TLD operator hat on.] Hard to ansdwer without more details. Really, I do not see why a monitoring script for internal use could require a lot of requests to TLD name servers. ___ 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: ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named
Hello, if I understand correctly, this isn't issue in BIND itself but it is some memory leak in underlying regexp library (glibc in Linux case). Can you please clarify which exact flaw in glibc (or other regex implementation) makes BIND vulnerable to remote DoS? Is it already reported to regex library developers? Was it already fixed (and how)? I'm asking because from distribution point of view it's better to address this flaw directly in regex implementation which will automatically make BIND invulnerable. Thank you in advance for response. Regards, Adam On Tue, Mar 26, 2013 at 12:01:50PM -0400, ISC Support Staff wrote: A critical defect in BIND 9 allows an attacker to cause excessive memory consumption in named or other programs linked to libdns. CVE: CVE-2013-2266 Document Version: 2.0 Posting date: 26 March 2013 Program Impacted: BIND Versions affected:Unix versions of BIND 9.7.x, 9.8.0 - 9.8.5b1, 9.9.0 - 9.9.3b1. (Windows versions are not affected. Versions of BIND 9 prior to BIND 9.7.0 (including BIND 9.6-ESV) are not affected. BIND 10 is not affected.) Severity: Critical Exploitable: Remotely Description: A flaw in a library used by BIND 9.7, 9.8, and 9.9, when compiled on Unix and related operating systems, allows an attacker to deliberately cause excessive memory consumption by the named process, potentially resulting in exhaustion of memory resources on the affected server. This condition can crash BIND 9 and will likely severely affect operation of other programs running on the same machine. Please Note: Versions of BIND 9.7 are beyond their end of life (EOL) and no longer receive testing or security fixes from ISC. However, the re-compilation method described in the Workarounds section of this document will prevent exploitation in BIND 9.7 as well as in currently supported versions. For current information on which versions are actively supported, please seehttp://www.isc.org/software/bind/versions. Additional information is available in the CVE-2013-2266 FAQ and Supplemental Information article in the ISC Knowledge base, https://kb.isc.org/article/AA-00879. Impact: Intentional exploitation of this condition can cause denial of service in all authoritative and recursive nameservers running affected versions of BIND 9 [all versions of BIND 9.7, BIND 9.8.0 through 9.8.5b1 (inclusive) and BIND 9.9.0 through BIND 9.9.3b1 (inclusive)]. Additionally, other services which run on the same physical machine as an affected BIND server could be compromised as well through exhaustion of system memory. Programs using the libdns library from affected versions of BIND are also potentially vulnerable to exploitation of this bug if they can be forced to accept input which triggers the condition. Tools which are linked against libdns (e.g. dig) should also be rebuilt or upgraded, even if named is not being used. 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: Patched versions are available (see the Solutions: section below) or operators can prevent exploitation of this bug in any affected version of BIND 9 by compiling without regular expression support. Compilation without regular expression support: BIND 9.7 (all versions), BIND 9.8 (9.8.0 through 9.8.5b1), and BIND 9.9 (9.9.0 through 9.9.3b1) can be rendered completely safe from this bug by re-compiling the source with regular expression support disabled. In order to disable inclusion of regular expression support: - After configuring BIND features as desired using the configure script in the top level source directory, manually edit the config.h header file that was produced by the configure script. - Locate the line that reads #define HAVE_REGEX_H 1 and replace the contents of that line with #undef HAVE_REGEX_H. - Run make clean to remove any previously compiled object files from the BIND 9 source directory, then proceed to make and install BIND normally. Active exploits: No known active exploits. Solution: Compile BIND 9 without regular expression support as described in the Workarounds section of this advisory or upgrade to the
BIND 9.8.4-P2 is now available
Introduction BIND 9.8.4-P2 is a security-fix release, superceding BIND 9.8.4-P1 as the latest production release of BIND 9.8. This document summarizes changes from BIND 9.8.3 to BIND 9.8.4-P2. 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 Removed the check for regex.h in configure in order to disable regex syntax checking, as it exposes BIND to a critical flaw in libregex on some platforms. [RT #32688] 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.
BIND 9.9.2-P2 is now available
Introduction BIND 9.9.2-P2 is a security-fix release, superceding BIND 9.9.2-P1 as the latest production release of BIND 9.9. This document summarizes changes from BIND 9.9.1 to BIND 9.9.2-P2. 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 Removed the check for regex.h in configure in order to disable regex syntax checking, as it exposes BIND to a critical flaw in libregex on some platforms. [RT #32688] 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
Re: ISC Security Advisory: CVE-2013-2266 (Adam Tkac)
Dear Adam, In order to minimize exploitation, we are trying to not spell out the specific nature of the flaw publicly. I will respond to you directly with a more detailed explanation. Regards, Jeff Wright ___ 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: ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named
I have a request for clarification: The workaround states to rebuild BIND with regexp support disabled. And I see new versions of BIND have been released. Are those versions just a rebuild with regexp support disabled? Or are they a more comprehensive fix? thanks. -- Jack Tavares From: bind-announce-bounces+j.tavares=f5@lists.isc.org [bind-announce-bounces+j.tavares=f5@lists.isc.org] on behalf of ISC Support Staff [support-st...@isc.org] Sent: Tuesday, March 26, 2013 09:02 To: bind-annou...@lists.isc.org Subject: ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named Note: This email advisory is provided for your information. The most up to date advisory information will always be at: https://kb.isc.org/article/AA-00871 please use this URL for the most up to date advisory information. --- A critical defect in BIND 9 allows an attacker to cause excessive memory consumption in named or other programs linked to libdns. CVE: CVE-2013-2266 Document Version: 2.0 Posting date: 26 March 2013 Program Impacted: BIND Versions affected:Unix versions of BIND 9.7.x, 9.8.0 - 9.8.5b1, 9.9.0 - 9.9.3b1. (Windows versions are not affected. Versions of BIND 9 prior to BIND 9.7.0 (including BIND 9.6-ESV) are not affected. BIND 10 is not affected.) Severity: Critical Exploitable: Remotely Description: A flaw in a library used by BIND 9.7, 9.8, and 9.9, when compiled on Unix and related operating systems, allows an attacker to deliberately cause excessive memory consumption by the named process, potentially resulting in exhaustion of memory resources on the affected server. This condition can crash BIND 9 and will likely severely affect operation of other programs running on the same machine. Please Note: Versions of BIND 9.7 are beyond their end of life (EOL) and no longer receive testing or security fixes from ISC. However, the re-compilation method described in the Workarounds section of this document will prevent exploitation in BIND 9.7 as well as in currently supported versions. For current information on which versions are actively supported, please seehttp://www.isc.org/software/bind/versions. Additional information is available in the CVE-2013-2266 FAQ and Supplemental Information article in the ISC Knowledge base, https://kb.isc.org/article/AA-00879. Impact: Intentional exploitation of this condition can cause denial of service in all authoritative and recursive nameservers running affected versions of BIND 9 [all versions of BIND 9.7, BIND 9.8.0 through 9.8.5b1 (inclusive) and BIND 9.9.0 through BIND 9.9.3b1 (inclusive)]. Additionally, other services which run on the same physical machine as an affected BIND server could be compromised as well through exhaustion of system memory. Programs using the libdns library from affected versions of BIND are also potentially vulnerable to exploitation of this bug if they can be forced to accept input which triggers the condition. Tools which are linked against libdns (e.g. dig) should also be rebuilt or upgraded, even if named is not being used. 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: Patched versions are available (see the Solutions: section below) or operators can prevent exploitation of this bug in any affected version of BIND 9 by compiling without regular expression support. Compilation without regular expression support: BIND 9.7 (all versions), BIND 9.8 (9.8.0 through 9.8.5b1), and BIND 9.9 (9.9.0 through 9.9.3b1) can be rendered completely safe from this bug by re-compiling the source with regular expression support disabled. In order to disable inclusion of regular expression support: - After configuring BIND features as desired using the configure script in the top level source directory, manually edit the config.h header file that was produced by the configure script. - Locate the line that reads #define HAVE_REGEX_H 1 and replace the contents of that line with #undef HAVE_REGEX_H. - Run make clean to remove any previously compiled object files from the BIND 9 source directory, then proceed to make and install BIND normally. Active exploits: No known active
Re: ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named
On 3/26/13 10:05 AM, Jack Tavares wrote: I have a request for clarification: The workaround states to rebuild BIND with regexp support disabled. And I see new versions of BIND have been released. Are those versions just a rebuild with regexp support disabled? Or are they a more comprehensive fix? This question is addressed in the CVE-2013-2266: FAQ and Supplemental Information Knowledge Base article, which I encourage everyone to read. https://kb.isc.org/article/AA-00879 Please see specifically the section which begins: What is the difference between deploying the patched versions of BIND versus implementing the documented workaround? Thanks, Michael McNally ISC Support ___ 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: ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named
Thank you. -- Jack Tavares From: ISC Support Staff [support-st...@isc.org] Sent: Tuesday, March 26, 2013 11:08 To: Jack Tavares Cc: bind-us...@isc.org Subject: Re: ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named On 3/26/13 10:05 AM, Jack Tavares wrote: I have a request for clarification: The workaround states to rebuild BIND with regexp support disabled. And I see new versions of BIND have been released. Are those versions just a rebuild with regexp support disabled? Or are they a more comprehensive fix? This question is addressed in the CVE-2013-2266: FAQ and Supplemental Information Knowledge Base article, which I encourage everyone to read. https://kb.isc.org/article/AA-00879 Please see specifically the section which begins: What is the difference between deploying the patched versions of BIND versus implementing the documented workaround? Thanks, Michael McNally ISC Support ___ 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: Suspecious DNS traffic
Dear Matus, I think you got my point. Yes. I am using Stateful Firewall and not sure my DNS server connecting to remote DNS on non standard port? So where i need to now look? Regards Papdheen M From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, 25 March 2013 7:46 PM Subject: Re: Suspecious DNS traffic On 26.03.13 00:21, babu dheen wrote: Hi Matus, please, skip personal replies. this is mailing listand issued should be discussed here. Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? If you have statefull firewall, you simply need to allow open connections (statefull firewalls can track outgoing UDP packets and match the replies). If not, you have to allow all traffic from port 53 on remote DNS servers to your DNS server. Since you can't know all DNS servers, you have to allow all incoming traffic to your DNS server where source port is 53. all the security is useless if blocks your service. Luckily, most of firewalls can track the connection state. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. ___ 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
Re: Suspecious DNS traffic
Dear Brown, I am using Stateful firewall from leading vendor company. So let me know why still my server initiate connection to remote DNS server on non standard destination port? Regards Babu From: wbr...@e1b.org wbr...@e1b.org To: babu dheen babudh...@yahoo.co.in Cc: bind-users@lists.isc.org bind-users@lists.isc.org Sent: Monday, 25 March 2013 7:48 PM Subject: Re: Suspecious DNS traffic babu dheen wrote on 03/25/2013 12:21:30 PM: Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? Total security requires total isolation. It is a matter of accepting some risks to perform the needed task. I beleive we just need to allow TCP and UDP 53 from our DNS server to internet(any) which is already done. Not sure why we have to open non standard port from our DNS server to internet? Kindly provide some details. You send request via UDP from random high port to an authoritative server. Answer is too large to fit in UDP packet, so it responds via TCP to the source port of the request (random high port from above). If you block that TCP connection, you cannot receive answer to your query. Another reason for TCP replies is DNS Response Rate Limiting (RRL). Some modern stateful firewalls understand DNS and if there is a UDP packet sent to port 53, it will accept TCP connections back from the destination address on port 53 to the source address/port. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system.___ 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: Suspecious DNS traffic
Dear Vernon, Thanks for your wonderful and detailed reply. I read the update given by you as below. Many stateful firewalls can also record the source and destination IP addresses and port numbers of outgoing UDP packets and allow subsequent incoming UDP packets with source and destination reversed. This has nothing to do with TCP. I am using stateful firewall and still why my BIND DNS server connection iniated using source port 53 to remote DNS server on non standard destination port is getting blocked? Not sure why my DNS server is initiating the connection to remote DNS server on non standard destination Port? Regards Babu From: Vernon Schryver v...@rhyolite.com To: bind-users@lists.isc.org Sent: Monday, 25 March 2013 8:40 PM Subject: Re: Suspecious DNS traffic Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? Every UDP and TCP packet has two port numbers, the source port and the destination port. When a resolver sends a request to a distant DNS authority, it sends to destination port 53 with a random local source port number. When the distant resolver responds, it will send a UDP packet with source port 53 and with destination port equal to the source port number in the request. If you block all packets from port 53 to local ports other than 53, then you will block all response to your resolver's requests. Some DNS resolver software in ancient days sent requests to distant authorities with source port 53, so that both the source and destination port numbers in DNS/UDP packets were 53. There are many reasons why that was a bad idea. For one modern reason, see https://www.google.com/search?q=cache+poisoning+attack and https://www.google.com/search?q=dns+source+port+randomization Contrary to claims in this thread, that source port need not be greater than 1024 except on some operating systems. The notion of privileged ports smaller than 1024 is an ancient BSDism that many consider a mistake. However, the source ports in DNS/UDP requests (as well as DNS/TCP) are likely to be restricted to parts of the complete [1,65535] range of port nubmers, but those partial ranges depend on the operating system, operating system configuration, DNS resolver software, and the resolvers configuration. For TCP and stub DNS resolvers, see https://www.google.com/search?q=ephemeral+port For DNS/UDP and BIND as a resolver, see the BIND Administrators Reference Manual (ARM) including the query-source,use-v4-udp-ports, use-v6-udp-ports, avoid-v4-udp-ports, and avoid-v6-udp-ports options. You send request via UDP from random high port to an authoritative server. Answer is too large to fit in UDP packet, so it responds via TCP to the source port of the request (random high port from above). If you block that TCP connection, you cannot receive answer to your query. No, a distant DNS authority certainly does not respond via TCP after a UDP response fails to fit in a DNS/UDP packet. Instead, the distant authority responds with a DNS/UDP packet with the TC or truncated error bit. A resolver will react to TC bits or truncation errors by making the same request with TCP unless it has already received the required data from some other DNS authority. This can happen after the local resolver has tired of waiting for an answer from one authority and sent the request to some other authority. Making a request via TCP consists of sending a TCP segment (or packet) with SYN bit sent to port 53 at the distant authority and with yet another random source port number. The distant authority will respond with a TCP segment with both the SYN and ACK bits set. The local resolver will respond with another TCP segment with both the SYN and ACK bits set. This is the famous 3-way handshake that establishes a TCP connection. Only after the TCP connection is established does the local resolver send the DNS request through the TCP connection. Another reason for TCP replies is DNS Response Rate Limiting (RRL). Not exactly. Some modern stateful firewalls understand DNS and if there is a UDP packet sent to port 53, it will accept TCP connections back from the destination address on port 53 to the source address/port. That is wrong. UDP packets have nothing to do with telling reasonable firewalls to allow TCP. Firewalls for more than 10 years have automatically dealt with TCP in at least two ways. One is to notice and remember (i.e. save state) the initial TCP SYN segment 3-way handshake and allow the later predictaBle TCP segments. Another mechanism is to blindly block incoming TCP segments with SYN but without ACK. The first mechanism requires saving state or memory for every established TCP connection, and so can be vulnerable to some kinds of state exhaustion attacks. The second mechanism prevents outsiders from originating TCP connections, but does not protect against
Re: Suspecious DNS traffic
In message 1364323396.89012.yahoomail...@web190806.mail.sg3.yahoo.com, babu d heen writes: Dear Brown, I am using Stateful firewall from leading vendor company. And you have not configured it correctly. So let me know why still my server initiate connection to remote DNS server on non standard destination port? It doesn't. You send to port 53 from any port. The replies come back from port 53 to any port. A properly configured stateful firewall lets these reply packets in. Your firewall is dropping them. I do mean any port not just those greater 1024. A stateful firewall still needs to be configured to record the state necessary to identify the reply packets. e.g. pass out quick proto udp from any to any keep state keep frag This say to record that we sent a UDP packet from any address and port to any other address and port so that we will accept the reply traffic and also to not block UDP fragments. For UDP that state table entry will exist for a few seconds before it is cleaned up. For TCP the firewall will track the TCP state transitions. Mark Regards Babu From: wbr...@e1b.org wbr...@e1b.org To: babu dheen babudh...@yahoo.co.in Cc: bind-users@lists.isc.org bind-users@lists.isc.org Sent: Monday, 25 March 2013 7:48 PM Subject: Re: Suspecious DNS traffic babu dheen wrote on 03/25/2013 12:21:30 PM: Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? Total security requires total isolation. It is a matter of accepting some risks to perform the needed task. I beleive we just need to allow TCP and UDP 53 from our DNS server to internet(any) which is already done. Not sure why we have to open non standard port from our DNS server to internet? Kindly provide some details. You send request via UDP from random high port to an authoritative server. Answer is too large to fit in UDP packet, so it responds via TCP to the source port of the request (random high port from above). If you block that TCP connection, you cannot receive answer to your query. Another reason for TCP replies is DNS Response Rate Limiting (RRL). Some modern stateful firewalls understand DNS and if there is a UDP packet sent to port 53, it will accept TCP connections back from the destination address on port 53 to the source address/port. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Suspecious DNS traffic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Niall already answered you the other day (brackets mine): The reply to such a query [from your server] originates from port 53 on the remote server, and is destined for the port on your server which was used as the source of the query[, which will be a randomly chosen port above 1024 if you are doing things the way they are usually done]. On 03/26/2013 02:44 PM, babu dheen wrote: Dear Brown, I am using Stateful firewall from leading vendor company. So let me know why still my server initiate connection to remote DNS server on non standard destination port? Regards Babu *From:* wbr...@e1b.org wbr...@e1b.org *To:* babu dheen babudh...@yahoo.co.in *Cc:* bind-users@lists.isc.org bind-users@lists.isc.org *Sent:* Monday, 25 March 2013 7:48 PM *Subject:* Re: Suspecious DNS traffic babu dheen wrote on 03/25/2013 12:21:30 PM: Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? Total security requires total isolation. It is a matter of accepting some risks to perform the needed task. I beleive we just need to allow TCP and UDP 53 from our DNS server to internet(any) which is already done. Not sure why we have to open non standard port from our DNS server to internet? Kindly provide some details. You send request via UDP from random high port to an authoritative server. Answer is too large to fit in UDP packet, so it responds via TCP to the source port of the request (random high port from above). If you block that TCP connection, you cannot receive answer to your query. Another reason for TCP replies is DNS Response Rate Limiting (RRL). Some modern stateful firewalls understand DNS and if there is a UDP packet sent to port 53, it will accept TCP connections back from the destination address on port 53 to the source address/port. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. - -- - _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$| |__| | | |__/ | \| _| |novos...@umdnj.edu - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFR8dcACgkQmb+gadEcsb4r3ACeNPse/dcwDd/rkipAo/mO3iJ0 eScAoKn2IRu+JAnIWdGQEMjUWd6irdnv =WVBw -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: Suspecious DNS traffic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It sounds like exactly the reverse of what Niall described in his other e-mail (brackets mine): The reply to such a query originates from port 53 on the remote server [in this case, your server], and is destined for the port on your server [in this case, the remote server] which was used as the source of the query [which will, again, almost certainly be a random port above 1024, but the same port the request just came in from to your port 53]. Why your firewall is confused about this is anyone's guess. I'd check with them. On 03/26/2013 02:50 PM, babu dheen wrote: Dear Vernon, Thanks for your wonderful and detailed reply. I read the update given by you as below. Many stateful firewalls can also record the source and destination IP addresses and port numbers of outgoing UDP packets and allow subsequent incoming UDP packets with source and destination reversed. This has nothing to do with TCP. I am using stateful firewall and still why my BIND DNS server connection iniated using source port 53 to remote DNS server on non standard destination port is getting blocked? Not sure why my DNS server is initiating the connection to remote DNS server on non standard destination Port? Regards Babu *From:* Vernon Schryver v...@rhyolite.com *To:* bind-users@lists.isc.org *Sent:* Monday, 25 March 2013 8:40 PM *Subject:* Re: Suspecious DNS traffic Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? Every UDP and TCP packet has two port numbers, the source port and the destination port. When a resolver sends a request to a distant DNS authority, it sends to destination port 53 with a random local source port number. When the distant resolver responds, it will send a UDP packet with source port 53 and with destination port equal to the source port number in the request. If you block all packets from port 53 to local ports other than 53, then you will block all response to your resolver's requests. Some DNS resolver software in ancient days sent requests to distant authorities with source port 53, so that both the source and destination port numbers in DNS/UDP packets were 53. There are many reasons why that was a bad idea. For one modern reason, see https://www.google.com/search?q=cache+poisoning+attack and https://www.google.com/search?q=dns+source+port+randomization Contrary to claims in this thread, that source port need not be greater than 1024 except on some operating systems. The notion of privileged ports smaller than 1024 is an ancient BSDism that many consider a mistake. However, the source ports in DNS/UDP requests (as well as DNS/TCP) are likely to be restricted to parts of the complete [1,65535] range of port nubmers, but those partial ranges depend on the operating system, operating system configuration, DNS resolver software, and the resolvers configuration. For TCP and stub DNS resolvers, see https://www.google.com/search?q=ephemeral+port For DNS/UDP and BIND as a resolver, see the BIND Administrators Reference Manual (ARM) including the query-source,use-v4-udp-ports, use-v6-udp-ports, avoid-v4-udp-ports, and avoid-v6-udp-ports options. You send request via UDP from random high port to an authoritative server. Answer is too large to fit in UDP packet, so it responds via TCP to the source port of the request (random high port from above). If you block that TCP connection, you cannot receive answer to your query. No, a distant DNS authority certainly does not respond via TCP after a UDP response fails to fit in a DNS/UDP packet. Instead, the distant authority responds with a DNS/UDP packet with the TC or truncated error bit. A resolver will react to TC bits or truncation errors by making the same request with TCP unless it has already received the required data from some other DNS authority. This can happen after the local resolver has tired of waiting for an answer from one authority and sent the request to some other authority. Making a request via TCP consists of sending a TCP segment (or packet) with SYN bit sent to port 53 at the distant authority and with yet another random source port number. The distant authority will respond with a TCP segment with both the SYN and ACK bits set. The local resolver will respond with another TCP segment with both the SYN and ACK bits set. This is the famous 3-way handshake that establishes a TCP connection. Only after the TCP connection is established does the local resolver send the DNS request through the TCP connection. Another reason for TCP replies is DNS Response Rate Limiting (RRL). Not exactly. Some modern stateful firewalls understand DNS and if there is a UDP packet sent to port 53, it will accept TCP connections back from the destination address on port 53 to the source address/port. That is
Re: Suspecious DNS traffic
On Mar 26, 2013, at 3:09 PM, Novosielski, Ryan novos...@umdnj.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It sounds like exactly the reverse of what Niall described in his other e-mail (brackets mine): The reply to such a query originates from port 53 on the remote server [in this case, your server], and is destined for the port on your server [in this case, the remote server] which was used as the source of the query [which will, again, almost certainly be a random port above 1024, but the same port the request just came in from to your port 53]. Why your firewall is confused about this is anyone's guess. I'd check with them. Another option is to just follow the standard dictum of Don't put your DNS server behind a firewall. It almost always makes debugging much harder and either monkeys with stuff that it shouldn't, or simply provides no benefit, all while adding another thing to fall over under DoS conditions. W On 03/26/2013 02:50 PM, babu dheen wrote: Dear Vernon, Thanks for your wonderful and detailed reply. I read the update given by you as below. Many stateful firewalls can also record the source and destination IP addresses and port numbers of outgoing UDP packets and allow subsequent incoming UDP packets with source and destination reversed. This has nothing to do with TCP. I am using stateful firewall and still why my BIND DNS server connection iniated using source port 53 to remote DNS server on non standard destination port is getting blocked? Not sure why my DNS server is initiating the connection to remote DNS server on non standard destination Port? Regards Babu *From:* Vernon Schryver v...@rhyolite.com *To:* bind-users@lists.isc.org *Sent:* Monday, 25 March 2013 8:40 PM *Subject:* Re: Suspecious DNS traffic Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? Every UDP and TCP packet has two port numbers, the source port and the destination port. When a resolver sends a request to a distant DNS authority, it sends to destination port 53 with a random local source port number. When the distant resolver responds, it will send a UDP packet with source port 53 and with destination port equal to the source port number in the request. If you block all packets from port 53 to local ports other than 53, then you will block all response to your resolver's requests. Some DNS resolver software in ancient days sent requests to distant authorities with source port 53, so that both the source and destination port numbers in DNS/UDP packets were 53. There are many reasons why that was a bad idea. For one modern reason, see https://www.google.com/search?q=cache+poisoning+attack and https://www.google.com/search?q=dns+source+port+randomization Contrary to claims in this thread, that source port need not be greater than 1024 except on some operating systems. The notion of privileged ports smaller than 1024 is an ancient BSDism that many consider a mistake. However, the source ports in DNS/UDP requests (as well as DNS/TCP) are likely to be restricted to parts of the complete [1,65535] range of port nubmers, but those partial ranges depend on the operating system, operating system configuration, DNS resolver software, and the resolvers configuration. For TCP and stub DNS resolvers, see https://www.google.com/search?q=ephemeral+port For DNS/UDP and BIND as a resolver, see the BIND Administrators Reference Manual (ARM) including the query-source,use-v4-udp-ports, use-v6-udp-ports, avoid-v4-udp-ports, and avoid-v6-udp-ports options. You send request via UDP from random high port to an authoritative server. Answer is too large to fit in UDP packet, so it responds via TCP to the source port of the request (random high port from above). If you block that TCP connection, you cannot receive answer to your query. No, a distant DNS authority certainly does not respond via TCP after a UDP response fails to fit in a DNS/UDP packet. Instead, the distant authority responds with a DNS/UDP packet with the TC or truncated error bit. A resolver will react to TC bits or truncation errors by making the same request with TCP unless it has already received the required data from some other DNS authority. This can happen after the local resolver has tired of waiting for an answer from one authority and sent the request to some other authority. Making a request via TCP consists of sending a TCP segment (or packet) with SYN bit sent to port 53 at the distant authority and with yet another random source port number. The distant authority will respond with a TCP segment with both the SYN and ACK bits set. The local resolver will respond with another TCP segment with both the SYN and ACK bits set. This is the famous 3-way handshake that establishes a TCP connection. Only after the TCP
Re: Suspecious DNS traffic
Maybe I can try. In the very old days - when BIND as a recursive resolver was chasing down an answer to a question, it would sent the remote authoritative DNS server the query in a UDP packet which has a query ID which was numbered sequentially. This was bad as bad people could guess your next query ID and send back their own answers. Then BIND randomised this 16 bit query ID which made it more difficult. Tie that in with a reasonable TTL, so answers are cached - and the world was a better place. We asked and received answers all on port 53. Then Dan Kaminsky (actually a good guy) discovers a protocol weakness which somewhat negated the effectiveness of the randomness of the 16 bit query ID. The short term solution for this is to add some more randomness in the query. A resolving name-server will now ask an authoritative server on port 53 but will ask from an almost random port. The Answer has to come back from port 53 but to the same random port and obviously with the same Query ID (or maybe ports are the other way around?) You can by configuration restrict or even remove this extra randomness - but it makes it easier for bad people to pollute your cache with bad answers. The Security Solution is to run DNSSEC - ie Sign all your own zones and to use DNSSEC recursive resolvers. You'll then ignore bad answers. If I start 'named' with the '-g' option - I get: 26-Mar-2013 ... using default UDP/IPv4 port range: [1024, 65535] 26-Mar-2013 ... listening on IPv4 interface lo, 127.0.0.1#53 I believe this is BIND telling me its intending to use from port 1024 to port 65535 as the local source of queries. This is a Good Thing. Your Firewall could be configured to allow BIND to do this. One alternative is to lock BIND and the Firewall to only allow port 53 queries and have them all forwarded to a recursive name-server on the outside of your firewall. If I sell machines - I think this is a great solution (I sell more machines). Don't restrict the Randomness that Queries can use. Even with DNSSEC - the majority of the Internet's DNS is not yet signed. If my explanation is not quite right - I'm pretty sure its at least in the right direction. On Wed, 2013-03-27 at 02:40 +0800, babu dheen wrote: Dear Matus, I think you got my point. Yes. I am using Stateful Firewall and not sure my DNS server connecting to remote DNS on non standard port? So where i need to now look? Regards Papdheen M From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, 25 March 2013 7:46 PM Subject: Re: Suspecious DNS traffic On 26.03.13 00:21, babu dheen wrote: Hi Matus, please, skip personal replies. this is mailing list and issued should be discussed here. Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? If you have statefull firewall, you simply need to allow open connections (statefull firewalls can track outgoing UDP packets and match the replies). If not, you have to allow all traffic from port 53 on remote DNS servers to your DNS server. Since you can't know all DNS servers, you have to allow all incoming traffic to your DNS server where source port is 53. all the security is useless if blocks your service. Luckily, most of firewalls can track the connection state. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ -- . . ___. .__ Posix Systems - (South) Africa /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 smime.p7s Description: S/MIME cryptographic 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: Looking for a pointer on getting reverse mapping with DDNS to work with DHCPD Named.
Thanks Graham,
I appreciate the hints. However, I'm still having problems (after finding
a few more how-to's). Any other pointers / tips on what to look for?
Jim
Mar 26 14:18:24 dns04 dhcpd: DHCPRELEASE of 172.10.20.51 from
00:0b:cd:33:b6:49 (proccilapxp) via eth1 (found)
Mar 26 14:18:31 dns04 dhcpd: DHCPDISCOVER from 00:0b:cd:33:b6:49 via eth1
Mar 26 14:18:32 dns04 dhcpd: DHCPOFFER on 172.10.20.51 to 00:0b:cd:33:b6:49
(proccilapxp) via eth1
Mar 26 14:18:32 dns04 dhcpd: Unable to add forward map from
proccilapxp.dhcp.coloradostudios.com. to 172.10.20.51: not authorized
Mar 26 14:18:32 dns04 dhcpd: DHCPREQUEST for 172.10.20.51 (172.10.5.5) from
00:0b:cd:33:b6:49 (proccilapxp) via eth1
Mar 26 14:18:32 dns04 dhcpd: DHCPACK on 172.10.20.51 to 00:0b:cd:33:b6:49
(proccilapxp) via eth1
On Tue, Mar 26, 2013 at 8:52 AM, Graham Clinch g.cli...@lancaster.ac.ukwrote:
Hi Jim,
I'm getting either of the following errors:
dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. to
proccilapxp.dhcp.coloradostudios.com
http://proccilapxp.dhcp.coloradostudios.com: bad DNS key
dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. to
proccilapxp.dhcp.coloradostudios.com
http://proccilapxp.dhcp.coloradostudios.com: timed out
it's actually the line above those :)
Mar 26 07:56:59 dns04 dhcpd: db.172.10.20.: host unknown.
which is caused by the zone statements in dhcpd.conf:
zone 20.10.172.in-addr.arpa. {
primary db.172.10.20.;
key DHCP_UPDATER;
#file internal/db.172.10.20;
}
'primary' should be the address of the DNS server to send the update
message to (not the filename of the zone - dhcpd asks the nameserver to
make the updates on its behalf, it doesn't alter the zone file itself).
so you probably want:
zone 20.10.172.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
#file internal/db.172.10.20;
}
(and similar a change for the forward zone).
Graham
--
Graham Clinch
Systems Programmer,
Information Systems Services,
Lancaster University
--
Jim Bucks - IT Director
Colorado Studios http://www.coloradostudios.com, Mobile TV
Grouphttp://www.mobiletvgroup.com,
HDNet http://www.hd.net, AXS.tv http://www.axs.tv/
8269 E. 23rd Ave. Denver, CO 80238 Main 303-388-8500
jbu...@coloradostudios.comDirect 303-542-5520
___
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: ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named
In message 20130326163235.ga31...@redhat.com, Adam Tkac writes: Hello, if I understand correctly, this isn't issue in BIND itself but it is some memory leak in underlying regexp library (glibc in Linux case). Can you please clarify which exact flaw in glibc (or other regex implementation) makes BIND vulnerable to remote DoS? Is it already reported to regex library developers? Was it already fixed (and how)? I'm asking because from distribution point of view it's better to address this flaw directly in regex implementation which will automatically make BIND invulnerable. Thank you in advance for response. Regards, Adam While I understand your issues bind-users isn't the forum to answer them. Mark On Tue, Mar 26, 2013 at 12:01:50PM -0400, ISC Support Staff wrote: A critical defect in BIND 9 allows an attacker to cause excessive memory consumption in named or other programs linked to libdns. CVE: CVE-2013-2266 Document Version: 2.0 Posting date: 26 March 2013 Program Impacted: BIND Versions affected:Unix versions of BIND 9.7.x, 9.8.0 - 9.8.5b1, 9.9.0 - 9.9.3b1. (Windows versions are not affected. Versions of BIND 9 prior to BIND 9.7.0 (including BIND 9.6-ESV) are not affected. BIND 10 is not affected.) Severity: Critical Exploitable: Remotely Description: A flaw in a library used by BIND 9.7, 9.8, and 9.9, when compiled on Unix and related operating systems, allows an attacker to deliberately cause excessive memory consumption by the named process, potentially resulting in exhaustion of memory resources on the affected server. This condition can crash BIND 9 and will likely severely affect operation of other programs running on the same machine. Please Note: Versions of BIND 9.7 are beyond their end of life (EOL) and no longer receive testing or security fixes from ISC. However, the re-compilation method described in the Workarounds section of this document will prevent exploitation in BIND 9.7 as well as in currently supported versions. For current information on which versions are actively supported, please seehttp://www.isc.org/software/bind/versions. Additional information is available in the CVE-2013-2266 FAQ and Supplemental Information article in the ISC Knowledge base, https://kb.isc.org/article/AA-00879. Impact: Intentional exploitation of this condition can cause denial of service in all authoritative and recursive nameservers running affected versions of BIND 9 [all versions of BIND 9.7, BIND 9.8.0 through 9.8.5b1 (inclusive) and BIND 9.9.0 through BIND 9.9.3b1 (inclusive)]. Additionally, other services which run on the same physical machine as an affected BIND server could be compromised as well through exhaustion of system memory. Programs using the libdns library from affected versions of BIND are also potentially vulnerable to exploitation of this bug if they can be forced to accept input which triggers the condition. Tools which are linked against libdns (e.g. dig) should also be rebuilt or upgraded, even if named is not being used. 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: Patched versions are available (see the Solutions: section below) or operators can prevent exploitation of this bug in any affected version of BIND 9 by compiling without regular expression support. Compilation without regular expression support: BIND 9.7 (all versions), BIND 9.8 (9.8.0 through 9.8.5b1), and BIND 9.9 (9.9.0 through 9.9.3b1) can be rendered completely safe from this bug by re-compiling the source with regular expression support disabled. In order to disable inclusion of regular expression support: - After configuring BIND features as desired using the configure script in the top level source directory, manually edit the config.h header file that was produced by the configure script. - Locate the line that reads #define HAVE_REGEX_H 1 and replace the contents of that line with #undef HAVE_REGEX_H. - Run make clean to remove any previously compiled
Re: Looking for a pointer on getting reverse mapping with DDNS to work with DHCPD Named.
In message camz8b4edupzje_uqespzqvs-oqwpy6hj2wasz9el397gen0...@mail.gmail.com
, Jim Bucks writes:
Thanks Graham,
I appreciate the hints. However, I'm still having problems (after finding
a few more how-to's). Any other pointers / tips on what to look for?
Jim
Fix the view to accept traffic from 127.0.0.1.
Mar 26 14:18:24 dns04 dhcpd: DHCPRELEASE of 172.10.20.51 from
00:0b:cd:33:b6:49 (proccilapxp) via eth1 (found)
Mar 26 14:18:31 dns04 dhcpd: DHCPDISCOVER from 00:0b:cd:33:b6:49 via eth1
Mar 26 14:18:32 dns04 dhcpd: DHCPOFFER on 172.10.20.51 to 00:0b:cd:33:b6:49
(proccilapxp) via eth1
Mar 26 14:18:32 dns04 dhcpd: Unable to add forward map from
proccilapxp.dhcp.coloradostudios.com. to 172.10.20.51: not authorized
Mar 26 14:18:32 dns04 dhcpd: DHCPREQUEST for 172.10.20.51 (172.10.5.5) from
00:0b:cd:33:b6:49 (proccilapxp) via eth1
Mar 26 14:18:32 dns04 dhcpd: DHCPACK on 172.10.20.51 to 00:0b:cd:33:b6:49
(proccilapxp) via eth1
On Tue, Mar 26, 2013 at 8:52 AM, Graham Clinch g.cli...@lancaster.ac.ukwrot
e:
Hi Jim,
I'm getting either of the following errors:
dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. to
proccilapxp.dhcp.coloradostudios.com
http://proccilapxp.dhcp.coloradostudios.com: bad DNS key
dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. to
proccilapxp.dhcp.coloradostudios.com
http://proccilapxp.dhcp.coloradostudios.com: timed out
it's actually the line above those :)
Mar 26 07:56:59 dns04 dhcpd: db.172.10.20.: host unknown.
which is caused by the zone statements in dhcpd.conf:
zone 20.10.172.in-addr.arpa. {
primary db.172.10.20.;
key DHCP_UPDATER;
#file internal/db.172.10.20;
}
'primary' should be the address of the DNS server to send the update
message to (not the filename of the zone - dhcpd asks the nameserver to
make the updates on its behalf, it doesn't alter the zone file itself).
so you probably want:
zone 20.10.172.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
#file internal/db.172.10.20;
}
(and similar a change for the forward zone).
Graham
--
Graham Clinch
Systems Programmer,
Information Systems Services,
Lancaster University
--
Jim Bucks - IT Director
Colorado Studios http://www.coloradostudios.com, Mobile TV
Grouphttp://www.mobiletvgroup.com,
HDNet http://www.hd.net, AXS.tv http://www.axs.tv/
8269 E. 23rd Ave. Denver, CO 80238 Main 303-388-8500
jbu...@coloradostudios.comDirect 303-542-5520
--089e0160c8204ab3a904d8d9a9c4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Thanks Graham,brbrI appreciate the hints.=A0 However, I#39;m still hav=
ing problems (after finding a few more quot;how-to#39;squot;).=A0 Any ot=
her pointers / tips on what to look for?brbrJimbrbrbrMar 26 14:18=
:24 dns04 dhcpd: DHCPRELEASE of 172.10.20.51 from 00:0b:cd:33:b6:49 (procci=
lapxp) via eth1 (found)br
Mar 26 14:18:31 dns04 dhcpd: DHCPDISCOVER from 00:0b:cd:33:b6:49 via eth1b=
rMar 26 14:18:32 dns04 dhcpd: DHCPOFFER on 172.10.20.51 to 00:0b:cd:33:b6:=
49 (proccilapxp) via eth1brMar 26 14:18:32 dns04 dhcpd: Unable to add for=
ward map from a href=3Dhttp://proccilapxp.dhcp.coloradostudios.com;procc=
ilapxp.dhcp.coloradostudios.com/a. to a href=3Dhttp://172.10.20.51;172=
.10.20.51/a: not authorizedbr
Mar 26 14:18:32 dns04 dhcpd: DHCPREQUEST for 172.10.20.51 (172.10.5.5) from=
00:0b:cd:33:b6:49 (proccilapxp) via eth1brMar 26 14:18:32 dns04 dhcpd: D=
HCPACK on 172.10.20.51 to 00:0b:cd:33:b6:49 (proccilapxp) via eth1brbr
brbrdiv class=3Dgmail_quoteOn Tue, Mar 26, 2013 at 8:52 AM, Graham =
Clinch span dir=3Dltrlt;a href=3Dmailto:g.cli...@lancaster.ac.uk; ta=
rget=3D_blankg.cli...@lancaster.ac.uk/agt;/span wrote:brblockquo=
te class=3Dgmail_quote style=3Dmargin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex
Hi Jim,br
br
gt; I#39;m getting either of the following errors:br
gt; dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. tobr=
gt; a href=3Dhttp://proccilapxp.dhcp.coloradostudios.com; target=3D_bla=
nkproccilapxp.dhcp.coloradostudios.com/abr
gt; lt;a href=3Dhttp://proccilapxp.dhcp.coloradostudios.com; target=3D=
_blankhttp://proccilapxp.dhcp.coloradostudios.com/agt;: bad DNS keybr=
gt; dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. tobr=
gt; a href=3Dhttp://proccilapxp.dhcp.coloradostudios.com; target=3D_bla=
nkproccilapxp.dhcp.coloradostudios.com/abr
gt; lt;a href=3Dhttp://proccilapxp.dhcp.coloradostudios.com; target=3D=
_blankhttp://proccilapxp.dhcp.coloradostudios.com/agt;: timed outbr
br
it#39;s actually the line above those :)br
br
gt; Mar 26 07:56:59 dns04 dhcpd: db.172.10.20.: host unknown.br
br
which is caused by the zone statements in dhcpd.conf:br
br
gt; zone 20.10.172.in-addr.arpa. {br
gt; =A0 =A0primary db.172.10.20.;br
gt; =A0 =A0key
Having trouble setting up BIND 9.9.2-P2 on Win XP PRO SP3, won't start
I installed bind using the default settings in the
installer. I successfully generated a rndc.key file. I
needed to populate the etc folder, so I downloaded the
Ubuntu version of bind and extracted the contents of /etc
and put them in Windows version of etc. I went through
the files one by one and replaced Linux paths with Windows
paths. So bind starts then immediately quits. The error
report is below. I have included my config files. I am
using bind only as a recursive revolver as my ISP DNS
servers are super slow and they do DNS hijacking. I don't
want to use any other DNS server other than the one
running on my machine. I want to run my own DNS server
for fun. So what could be wrong, what did I miss.
Event Type:Error
Event Source:Service Control Manager
Event Category:None
Event ID:7022
Date:3/26/2013
Time:5:30:16 PM
User:N/A
Computer:MOM
Description:
The ISC BIND service hung on starting.
named.conf:
include C:\WINDOWS\system32\dns\etc\named.conf.options;
include C:\WINDOWS\system32\dns\etc\named.conf.local;
include
C:\WINDOWS\system32\dns\etc\named.conf.default-zones;
named.conf.options: Note that I commented out the
/var/cache because I thought we don't need that on Windows
or am I wrong.
// options {
//directory /var/cache/bind;
dnssec-validation auto;
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};
named.conf.default-zones:
// prime the server with knowledge of the root servers
zone . {
type hint;
file C:\WINDOWS\system32\dns\etc\db.root;
};
// be authoritative for the localhost forward and reverse
zones, and for
// broadcast zones as per RFC 1912
zone localhost {
type master;
file C:\WINDOWS\system32\dns\etc\db.local;
};
zone 127.in-addr.arpa {
type master;
file C:\WINDOWS\system32\dns\etc\db.127;
};
zone 0.in-addr.arpa {
type master;
file C:\WINDOWS\system32\dns\etc\db.0;
};
zone 255.in-addr.arpa {
type master;
file C:\WINDOWS\system32\dns\etc\db.255;
};
--
http://namiwalks.nami.org/joannehomier
___
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: Having trouble setting up BIND 9.9.2-P2 on Win XP PRO SP3, won't start
I have no idea how things work on Windows, but I doubt directory is optional.
- Original Message -
From: Joanne Homier [mailto:joanne.hom...@gmail.com]
Sent: Tuesday, March 26, 2013 11:30 PM
To: bind-users@lists.isc.org bind-users@lists.isc.org
Subject: Having trouble setting up BIND 9.9.2-P2 on Win XP PRO SP3, won't start
I installed bind using the default settings in the
installer. I successfully generated a rndc.key file. I
needed to populate the etc folder, so I downloaded the
Ubuntu version of bind and extracted the contents of /etc
and put them in Windows version of etc. I went through
the files one by one and replaced Linux paths with Windows
paths. So bind starts then immediately quits. The error
report is below. I have included my config files. I am
using bind only as a recursive revolver as my ISP DNS
servers are super slow and they do DNS hijacking. I don't
want to use any other DNS server other than the one
running on my machine. I want to run my own DNS server
for fun. So what could be wrong, what did I miss.
Event Type:Error
Event Source:Service Control Manager
Event Category:None
Event ID:7022
Date:3/26/2013
Time:5:30:16 PM
User:N/A
Computer:MOM
Description:
The ISC BIND service hung on starting.
named.conf:
include C:\WINDOWS\system32\dns\etc\named.conf.options;
include C:\WINDOWS\system32\dns\etc\named.conf.local;
include
C:\WINDOWS\system32\dns\etc\named.conf.default-zones;
named.conf.options: Note that I commented out the
/var/cache because I thought we don't need that on Windows
or am I wrong.
// options {
//directory /var/cache/bind;
dnssec-validation auto;
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};
named.conf.default-zones:
// prime the server with knowledge of the root servers
zone . {
type hint;
file C:\WINDOWS\system32\dns\etc\db.root;
};
// be authoritative for the localhost forward and reverse
zones, and for
// broadcast zones as per RFC 1912
zone localhost {
type master;
file C:\WINDOWS\system32\dns\etc\db.local;
};
zone 127.in-addr.arpa {
type master;
file C:\WINDOWS\system32\dns\etc\db.127;
};
zone 0.in-addr.arpa {
type master;
file C:\WINDOWS\system32\dns\etc\db.0;
};
zone 255.in-addr.arpa {
type master;
file C:\WINDOWS\system32\dns\etc\db.255;
};
--
http://namiwalks.nami.org/joannehomier
___
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
