BIND, DHCP, and CVE-2014-0160 (the OpenSSL Heartbleed bug)
Earlier this week, the OpenSSL project (http://openssl.org) announced CVE-2014-0160, disclosing a very serious security flaw in the OpenSSL library, affecting versions 1.0.1 and 1.0.2-beta (including OpenSSL 1.0.1f and 1.0.2-beta1) In many stories, this vulnerability is being referred to as the Heartbleed bug. Because ISC products can be built to link against OpenSSL libraries, users of BIND 9 and ISC DHCP have asked us to clarify whether or not their systems are at risk due to CVE-2014-0160. Rather than answer questions individually, we hope that this will clarify the matter for our users and reassure them that their services are safe from this security vulnerability. 1) Is BIND vulnerable? After consulting with our developers, we are pleased to report that BIND 9 does not make use of the vulnerable parts of the OpenSSL libraries, so BIND services are NOT at risk from CVE-2014-0160. 2) Is ISC DHCP vulnerable? ISC DHCP does not use the affected parts of the OpenSSL library, either. ISC DHCP services are not at risk from CVE-2014-0160. 3) What about Windows binary packages? For the benefit of Windows users, ISC provides installable binary distributions of BIND 9 for those who wish to run it on Windows servers. At the time of this message, the most recent Windows binary distributions include vulnerable versions of the OpenSSL shared libraries. These shared library files are safe for use with BIND 9 because BIND does not use the flawed parts of the library, but operators should not use the provided libraries with other applications. Future versions of the Windows binary distributions will include updated OpenSSL libraries with the security issues fixed, but we have no current plans to release emergency security releases for Windows because the libraries provided are safe for BIND 9. 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
Windows dig resolv.conf
Apologies if this has been discussed; I searched the archives and didn't find anything. I'd like to know why the search and domain settings in the Windows %systemroot%\system32\drivers\etc\resolv.conf don't seem to make a difference. Anyone know? Thanks. Fred Woodbridge ___ 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: Windows dig resolv.conf
On Apr 11 2014, Frederic Woodbridge wrote: Apologies if this has been discussed; I searched the archives and didn't find anything. I'd like to know why the search and domain settings in the Windows %systemroot%\system32\drivers\etc\resolv.conf don't seem to make a difference. Anyone know? If you are asking why doesn't dig take any notice of these settings, that's not Windows-specific. From the dig man page: +[no]search Use [do not use] the search list defined by the searchlist or domain directive in resolv.conf (if any). The search list is not used by default. -- Chris Thompson Email: c...@cam.ac.uk ___ 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
Inline signing and views.
Hello -
Is it possible to enable inline signing of a zone in 2 different views with 2
different keys?
I have the following config:
view external {
match-clients {
1.1.1.1;
};
zone test.com. {
type master;
file external.test.com.;
allow-update {
localhost;
};
key-directory /config/external.keys;
auto-dnssec maintain;
inline-signing yes;
};
};
view internal {
match-clients {
any;
};
zone test.com. {
type master;
file internal.test.com.;
allow-update {
localhost;
};
key-directory /config/internal.keys;
auto-dnssec maintain;
inline-signing yes;
};
};
When I run bind I get these errors:
11-Apr-2014 10:35:30.414 dns_dnssec_findzonekeys2: error reading private key
file test.com/RSASHA1/49440: file not found
11-Apr-2014 10:35:30.415 dns_dnssec_findzonekeys2: error reading private key
file test.com/RSASHA1/6124: file not found
11-Apr-2014 10:35:30.435 zone test.com/IN/external (signed): reconfiguring zone
keys
11-Apr-2014 10:35:30.436 zone test.com/IN/internal (signed): reconfiguring zone
keys
11-Apr-2014 10:35:30.436 dns_dnssec_keylistfromrdataset: error reading private
key file test.com/RSASHA1/49440: file not found
11-Apr-2014 10:35:30.437 dns_dnssec_keylistfromrdataset: error reading private
key file test.com/RSASHA1/6124: file not found
Is what I am trying to do not possible, or do I have a config error?
I created the key files using
dnssec-keygen test.com
dnssec-keygen -fk test.com
In the 2 different directorys.
All permissions and file owner ship is correct.
It works properly if I only have one (either of them) of these zones configured
for auto signing,
so I believe the key files are ok.
The man page and tutorials that I have found do not address multiple views.
Thank you
___
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: Clients Matching Multiple Views
On Apr 9, 2014, at 4:14 AM, Steven Carr wrote: However, assuming you are using views on the same IP address and not splitting it across internal/external servers as that would screw up NS records), you can reuse the same zone file so those zones that appear in both internal and external views refer back to the same zone file, then when you update that zone file both views are updated. My understanding has been that two views that are masters for a zone can safely share a zone file if the zone isn't dynamic (e.g. dnsupdate, dnssec auto signing, etc), but that two views of a slave zone shouldn't do that: you could have two different views independently rewriting the same file, a bad thing even if the files are known to be identical. Furthermore, allowing that could conceivably show no problems very much of the time, masking the actual risk. If I'm wrong, that would be a good thing to know. John Wobus Cornell U ___ 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: Clients Matching Multiple Views
On 11 Apr 2014, at 18:59, John Wobus jw...@cornell.edu wrote: On Apr 9, 2014, at 4:14 AM, Steven Carr wrote: However, assuming you are using views on the same IP address and not splitting it across internal/external servers as that would screw up NS records), you can reuse the same zone file so those zones that appear in both internal and external views refer back to the same zone file, then when you update that zone file both views are updated. My understanding has been that two views that are masters for a zone can safely share a zone file if the zone isn't dynamic (e.g. dnsupdate, dnssec auto signing, etc), but that two views of a slave zone shouldn't do that: you could have two different views independently rewriting the same file, a bad thing even if the files are known to be identical. Furthermore, allowing that could conceivably show no problems very much of the time, masking the actual risk. If I'm wrong, that would be a good thing to know. John Wobus Cornell U If you were to use a DLZ for the dynamic zone rather than a file, then the multiple writer integrity can be handled by the DLZ code (i.e. palming it off to a RDBMS to deal with). Just a thought - but generally I agree that multiple writers to a file is just asking for trouble… - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Clients Matching Multiple Views
On 04/11/2014 10:59 AM, John Wobus wrote: My understanding has been that two views that are masters for a zone can safely share a zone file if the zone isn't dynamic (e.g. dnsupdate, dnssec auto signing, etc), but that two views of a slave zone shouldn't do that: you could have two different views independently rewriting the same file, a bad thing even if the files are known to be identical. Furthermore, allowing that could conceivably show no problems very much of the time, masking the actual risk. You are correct. Include statements that reference the common data between the zones on the master has been the canonical way to handle this situation since day 1. Doug ___ 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
