Re: Fwd: Re: Fwd: Re: Difference between netstat & rndc status
On 05/07/11 06:25, Bind wrote: > -Original Message- > From: "Bind" > To: "Mark Andrews" > Date: Tue, 05 Jul 2011 09:55:03 +0430 > Subject: Re: Fwd: Re: Difference between netstat & rndc status > > > Thanks for your best support and answers all the time. > Could u explain more about this list. how it built and when it refreshed? > Regards > When a client makes a query of a recursive server, sometimes the answer can be given immediately from cache (or from authoritative data if the server is both authoritative and recursive). However, if the server needs to perform iterative resolution of the query on behalf of the client by sending it's own queries to authoritative servers elsewhere,then it has to keep a record of the original client query while this is happening so that it can respond when the answer is available. If the same client makes multiple queries for different names, then these are all recorded separately since each is due its own answer. When the server responds to the client, then the entry is removed from the list. If a client doesn't see the server response, it doesn't mean that the entry isn't removed from the list, it means that the server responded after the client timed out (this sometimes happens if there are problems resolving the query). Duplicate client queries are identified (for example if the client retries) and stored as a single 'recursive client'. If the list reaches the 'soft' limit (this is the number in the middle) then named starts timing out (SERVFAIL) the longest waiting client queries earlier than it would normally in order to make room for new queries. If the list reaches the 'hard' limit, then there is nowhere to put new queries and named will not be able to process them. ___ 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: whether to return RRSIG RRs
Cathy Zhang wrote: > # Check direct query for RRSIG: If it's not cached with other records, > # it should result in an empty response. > > Why shouldn't recursive server return RRSIG RRs to the client? An RRSIG is part of the RRset that it signs, and the whole thing must travel together as a unit. If you fetch the signature and the signed records separately, you are likely to encounter a spurious mismatch when the authoritative data changes. Tony. -- f.anthony.n.finchhttp://dotat.at/ Portland, Plymouth, Northwest Biscay: Southerly or southwesterly 4 or 5, increasing 5 to 7 later. Slight or moderate. Rain or showers. Moderate or good, occasionally poor. ___ 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.8.0-P4
Introduction BIND 9.8.0-P4 is security patch for BIND 9.8.0. 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 some pre-compiled versions for certain operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. Security Fixes 9.8.0-P4 * Using Response Policy Zone (RPZ) with DNAME records and querying the subdomain of that label can cause named to crash. Now logs that DNAME is not supported. [RT #24766] * If named is configured to be both authoritative and resursive and receives a recursive query for a CNAME in a zone that it is authoritative for, if that CNAME also points to a zone the server is authoritative for, the recursive part of name will not follow the CNAME change and the response will not be a complete CNAME chain. [RT #24455] * Using Response Policy Zone (RPZ) to query a wildcard CNAME label with QUERY type SIG/RRSIG, it can cause named to crash. Fix is query type independant. [RT #24715] [CVE-2011-1907] * Change #2912 (see CHANGES) exposed a latent bug in the DNS message processing code that could allow certain UPDATE requests to crash named. This was fixed by disambiguating internal database representation vs DNS wire format data. [RT #24777] [CVE-2011-2464] Thank You Thank you to everyone who assisted us in making this release possible. If you would like to contribute to ISC to assist us in continuing to make quality open source software, please visit our donations page at http://www.isc.org/supportisc. -- 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
BIND 9.6-ESV-R4-P3
Introduction BIND 9.6-ESV-R4-P3 is security patch for BIND 9.6-ESV-R4. 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 some pre-compiled versions for certain operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. Security Fixes 9.6-ESV-R4-P3 * Change #2912 (see CHANGES) exposed a latent bug in the DNS message processing code that could allow certain UPDATE requests to crash named. This was fixed by disambiguating internal database representation vs DNS wire format data. [RT #24777] [CVE-2011-2464] Thank You Thank you to everyone who assisted us in making this release possible. If you would like to contribute to ISC to assist us in continuing to make quality open source software, please visit our donations page at http://www.isc.org/supportisc. -- 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
Security Advisory: CVE-2011-2465 ISC BIND 9 Remote Crash with Certain RPZ Configurations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 ISC BIND 9 Remote Crash with Certain RPZ Configurations Two defects were discovered in ISC's BIND 9 code. These defects only affect BIND 9 servers which have recursion enabled and which use a specific feature of the software known as Response Policy Zones (RPZ) and where the RPZ zone contains a specific rule/action pattern. CVE: CVE-2011-2465 Document Version: 2.0 Posting date: 05 Jul 2011 Program Impacted: BIND Versions affected: 9.8.0, 9.8.0-P1, 9.8.0-P2 and 9.8.1b1 Other versions of BIND 9 not listed here are not vulnerable to this problem. Severity: High Exploitable: Remotely Description: A defect in the affected versions of BIND could cause the "named" process to exit when queried, if the server has recursion enabled and was configured with an RPZ zone containing certain types of records. Specifically, these are any DNAME record and certain kinds of CNAME records. The patch release of BIND 9.8.0-P4 alters the behavior of RPZ zones by ignoring any DNAME records in an RPZ zone, and correctly returning CNAME records from RPZ zones. Note that DNAME has no defined effect on the RPZ engine and its presence in an RPZ zone is ignored. The definitive list of meaningful patterns in an RPZ zone is given in the BIND 9 Administrative Reference Manual and also in ISC Technical Note 2010-1. 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?calculator&adv&version=2 Workarounds: Do not put certain CNAME or any DNAME records into an RPZ zone file until your software can be patched. If you subscribe to a service which supplies your RPZ zone data, ensure that it does not contain any DNAME or certain CNAME records. The CNAME records which must not be used are those which signal the RPZ engine to rewrite query names. CNAME records which signal the RPZ engine to forge an NXDOMAIN response are not affected by this defect. An example of an RPZ rule which causes a query name to be rewritten is: *.malicious-domain.com CNAME walled-garden.isp.net An example of an RPZ rule which causes an NXDOMAIN response to be returned is: *.malicious-domain.com CNAME . Please refer to the BIND 9 Administrative Reference Manual or to ISC Technical Note 2010-1 for more information about the Response Policy Zone (RPZ) feature which was added to BIND 9 in Version 9.8.0. Active exploits: ISC received reports of this software flaw and verified the report's accuracy. Solution: Upgrade to: 9.8.0-P4. (Note that 9.8.0-P3 is not affected but has been replaced by 9.8.0-P4 due to CVE-2011-2464) Download this version from the following location: ISC releases of BIND 9 software may be downloaded from http://www.isc.org/software/bind If you do not obtain your BIND software directly from ISC, contact your operating system or software vendor for an update. If you are participating in ISC's Beta or release candidate (RC) program, please upgrade. ISC Beta/RC testers are expected to remove vulnerable versions and upgrade. No security advisories are issued for beta / release candidates once the corresponding final release is made. Acknowledgement: ISC thanks Bryce Moore from TELUS Security Labs for finding and reporting this issue. Document Revision History Version 1.0 - 14 June 2011: Phase One Disclosure Date Version 1.1 - 20 June 2011: Phase Two Disclosure Date with updates. Version 1.2 - 21 June 2011: Updates on beta, RC, and clarity editing Version 1.3 - 24 June 2011: Added document URL Version 1.4 - 28 June 2011: Updated Solution and description (revised to recommend 9.8.0-P4 per CVE-2011-2464) Version 1.5 - 4 July 2011: Phase Three and Four Disclosure Date Version 2.0 - 5 July 2011: Public Disclosure References: Do you have Questions? Questions regarding this advisory should go to security-offi...@isc.org. Do you need Software Support? Questions on ISC's Support services or other offerings should be sent to sa...@isc.org. More information on ISC's support and other offerings are available at: http://www.isc.org/community/blog/201102/BIND-support 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 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 thi
Security Advisory: CVE-2011-2464 - ISC BIND 9 Remote packet Denial of Service against Authoritative and Recursive Servers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
ISC BIND 9 Remote packet Denial of Service against Authoritative and
Recursive Servers
A specially constructed packet will cause BIND 9 ("named") to exit,
affecting DNS service.
CVE: CVE-2011-2464
Document Version: 2.0
Posting date: 05 Jul 2011
Program Impacted: BIND
Versions affected: 9.6.3, 9.6-ESV-R4, 9.6-ESV-R4-P1, 9.6-ESV-R5b1 9.7.0,
9.7.0-P1, 9.7.0-P2, 9.7.1, 9.7.1-P1, 9.7.1-P2, 9.7.2, 9.7.2-P1, 9.7.2-P2,
9.7.2-P3, 9.7.3, 9.7.3-P1, 9.7.3-P2, 9.7.4b1 9.8.0, 9.8.0-P1, 9.8.0-P2,
9.8.0-P3, 9.8.1b1
Severity: High
Exploitable: Remotely
Description:
A defect in the affected BIND 9 versions allows an attacker to remotely
cause the "named" process to exit using a specially crafted packet. This
defect affects both recursive and authoritative servers. The code location
of the defect makes it impossible to protect BIND using ACLs configured
within named.conf or by disabling any features at compile-time or run-time.
A remote attacker would need to be able to send a specially crafted packet
directly to a server running a vulnerable version of BIND. There is also
the potential for an indirect attack via malware that is inadvertently
installed and run, where infected machines have direct access to an
organization's nameservers.
CVSS Score: 7.8
(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?calculator&adv&version=2
Workarounds:
There are no known workarounds for publicly available servers.
Administrators of servers that are not publicly available may be able to
limit exposure via firewalls and packet filters.
Active exploits:
ISC knows of no public tools to exploit this defect at the time of this
advisory.
Solution:
Upgrade to: 9.6-ESV-R4-P3, 9.7.3-P3 or 9.8.0-P4.
Download these versions from the following locations:
ISC releases of BIND 9 software may be downloaded from
http://www.isc.org/software/bind
If you do not obtain your BIND software directly from ISC, contact your
operating system or software vendor for an update.
If you are participating in ISC's beta or release candidate (RC) programs,
please upgrade. ISC Beta/RC testers are expected to remove vulnerable
versions and upgrade. No security advisories are issued for beta / release
candidates once the corresponding final release is made.
In addition, 9.5.3b1 and 9.5.3rc1 are affected although ISC has not
released a final production version of 9.5.3. Note that BIND 9.5 is
End-of-Life, therefore if you are running a pre-release version of 9.5.3 we
recommend upgrading to a supported production version of BIND.
9.6-ESV-R4-P2 is not affected by any known attack vectors, but has been
replaced by 9.6-ESV-R4-P3 which carries a more complete fix
Other versions of BIND 9 not listed in this advisory are not vulnerable to
this problem.
Acknowledgements:
ISC thanks Roy Arends from Nominet for pin-pointing the exact nature of the
vulnerability. We also thank Ramesh Damodaran of Infoblox for finding a
variation of the attack vector and Mats Dufberg of TeliaSonera Sweden for
confirming additional variants.
Document Revision History:
Version 1.0 - 14 June 2011: Phase One Disclosure Date
Version 1.1 - 20 June 2011: Phase Two Disclosure Date with updates.
Version 1.2 - 21 June 2011: Updates on beta, RC, and clarity editing
Verison 1.3 - 21 June 2011: Sent Hold Notices to Phase I constituents,
extended Acknowledgments
Version 1.4 - 23 June 2011: Updated -P versions to include Advanced
Security Patches release to Phase I, and "Upgrade to:" versions
Version 1.5 - 24 June 2011: Added document URL, sent schedule update to
Phase I constituents.
Version 1.6 - 28 June 2011: Updated Versions Affected, extended
Acknowledgments, sent Phase I updates
Version 1.7 - 30 June 2011: Updated attribution text.
Version 1.8 - 4 July 2011: Phase Three and Four Disclosure Date
version 2.0 - 5 July 2011: Public Disclosure
Do you have Questions? Questions regarding this advisory should go to
security-offi...@isc.org.
Do you need Software Support? Questions on ISC's Support services or other
offerings should be sent to sa...@isc.org. More information on ISC's
support and other offerings are available at:
http://www.isc.org/community/blog/201102/BIND-support
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
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 d
BIND 9.7.3-P3
Introduction BIND 9.7.3-P3 is security patch for BIND 9.7.3. 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 some pre-compiled versions for certain operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. Security Fixes 9.7.3-P3 * Change #2912 (see CHANGES) exposed a latent bug in the DNS message processing code that could allow certain UPDATE requests to crash named. This was fixed by disambiguating internal database representation vs DNS wire format data. [RT #24777] [CVE-2011-2464] Thank You Thank you to everyone who assisted us in making this release possible. If you would like to contribute to ISC to assist us in continuing to make quality open source software, please visit our donations page at http://www.isc.org/supportisc. -- 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
cve-2011-2464 affected the 9.4-ESV-R4-P1?
Hi all, on the ISC website i don't see that the 9.4-ESV-R4-P1 is affected by the CVE-2011-2464 is it because it's not really affected? or it's affected but i don't see it on "versions affected" because the 9.4-ESV-R4-P1 has it's EOL date to jun2011. Thanks. Issam HARRATHI. IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ___ 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: Slow list
On Jun 1 2011, Alan Clegg wrote: On 6/1/2011 7:16 AM, /dev/rob0 wrote: On Wed, Jun 01, 2011 at 09:54:04AM +0200, Jan-Piet Mens wrote: Does anyone else find the bind-users list to be very slow? [...] I'll have operations take a look into what is causing the delay (it doesn't happen on all mail to the list...) Delays were very noticeable today for the bind-announce messages copied to bind-users. From the Received headers, the delay seems to happen between webster.isc.org and the next host: either mx.ams1.isc.org or mx.pao1.isc.org for different messages. In the worst case, there was delay of over 3 hours between webster receiving the message and passing it on. -- 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
Re: cve-2011-2464 affected the 9.4-ESV-R4-P1?
> on the ISC website i don't see that the 9.4-ESV-R4-P1 is affected by the > CVE-2011-2464 is it because it's not really affected? or it's affected > but i don't see it on "versions affected" because the 9.4-ESV-R4-P1 has > it's EOL date to jun2011. To be very precise with my language: It is not *exposed*. The issue has two layers. First, there's an underlying bug that's been dormant in our code for a very long time, but there was no way to trigger it... and, second, there's the trigger. Actually, there are two separate triggers: one was introduced in 9.6 and another in 9.7. Neither of them is in any version of 9.4. So, we *will* be releasing 9.4-ESV-R5 soon, and it contains a fix for the underlying bug. But we didn't release a patch today because there's no trigger. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Client cannot resolve communities.intel.com
On 7/5/2011 12:28 AM, Fajar A. Nugraha wrote: On Tue, Jul 5, 2011 at 10:29 AM, vr wrote: Hello, I am trying to visit "http://communities.intel.com"; using Iceweasel on a Debian desktop PC. No proxies. My clients etc/resolv.conf point to my own Debian BIND 9.7.3 installed on a separate server and installed from distribution packages (bind9 1:9.7.3.dfsg-1~squeeze2). From myDesktop, NSLOOKUP fails but DIG shows a CNAME record. I see the same results from the BIND server so I've included just the output from myDesktop below. Also included below is my named.conf. Do I have something obvious in BIND screwed up? Quite possibly so. And you use dig incorrectly too. me@myDesktop:~$ dig communities.intel.com ns.iotk.net this should be $ dig communities.intel.com @ns.iotk.net ;; ANSWER SECTION: communities.intel.com. 207 IN CNAME intel-2.hs.llnwd.net. so it finds the cname ... ;; AUTHORITY SECTION: llnwd.net. 604800 IN SOA localhost. root.localhost. 2008071301 604800 86400 2419200 604800 ... but your DNS has a broken record for llnwd.net. It should be ;; ANSWER SECTION: llnwd.net. 3600IN SOA dns11.llnwd.net. hostmaster.llnwd.net. 210 900 300 604800 300 Yeah, there's some nasty stuff in that nameserver's version of the llnwd.net zone: % dig llnwd.net ns +norec @99.30.25.1 ; <<>> DiG 9.4.3-P3 <<>> llnwd.net ns +norec @99.30.25.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1589 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;llnwd.net. IN NS ;; ANSWER SECTION: llnwd.net. 604800 IN NS localhost. ;; ADDITIONAL SECTION: localhost. 604800 IN A 127.0.0.1 localhost. 604800 IN ::1 ;; Query time: 36 msec ;; SERVER: 99.30.25.1#53(99.30.25.1) ;; WHEN: Tue Jul 5 16:02:45 2011 ;; MSG SIZE rcvd: 94 Since the nameserver is responding authoritatively, the llnwd.net zone would appear to be defined as "type master" or "type slave", despite the fact that it was missing from the named.conf posted earlier. - Kevin ___ 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: Slow list
On Tue, 5 Jul 2011, Chris Thompson wrote: > On Jun 1 2011, Alan Clegg wrote: > > > On 6/1/2011 7:16 AM, /dev/rob0 wrote: > > > On Wed, Jun 01, 2011 at 09:54:04AM +0200, Jan-Piet Mens wrote: > > > > > Does anyone else find the bind-users list to be very slow? > [...] > > I'll have operations take a look into what is causing the delay (it > > doesn't happen on all mail to the list...) > > Delays were very noticeable today for the bind-announce messages copied > to bind-users. From the Received headers, the delay seems to happen > between webster.isc.org and the next host: either mx.ams1.isc.org or > mx.pao1.isc.org for different messages. In the worst case, there was > delay of over 3 hours between webster receiving the message and passing > it on. We are working on this -- I believe we've discovered the problem internally, it seems to be a bad link between the handoff from mailman to postfix on a large list, exacerbated by several users whose domains return a SRVFAIL response. (The irony here of course is that those users need the help the list could offer the most). This seems to be because mailman asks postfix to do a "verify" (but not an SMTP VRFY) of the addresses as part of the VERP that it does. One annoying thing that I should note is that removing those problem users and flushing the queues does NOT help. -Dan ___ 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
"Key : Delaying activation to match the DNSKEY TTL."
I saw this message from dnssec-signzone around the time a previously published key was due to be activated, and I'm not quite sure what it means. Google is uncharacteristically silent about it ;). If someone could offer an explanation of why the activation was delayed and whether I should care it would be much appreciated, thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 ___ 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: cve-2011-2464 affected the 9.4-ESV-R4-P1?
In message <20110705200619.gb99...@isc.org>, Evan Hunt writes: > > on the ISC website i don't see that the 9.4-ESV-R4-P1 is affected by the > > CVE-2011-2464 is it because it's not really affected? or it's affected > > but i don't see it on "versions affected" because the 9.4-ESV-R4-P1 has > > it's EOL date to jun2011. > > To be very precise with my language: It is not *exposed*. > > The issue has two layers. First, there's an underlying bug that's been > dormant in our code for a very long time, but there was no way to trigger > it... and, second, there's the trigger. Actually, there are two separate > triggers: one was introduced in 9.6 and another in 9.7. Neither of > them is in any version of 9.4. > > So, we *will* be releasing 9.4-ESV-R5 soon, and it contains a fix for the > underlying bug. But we didn't release a patch today because there's no > trigger. Additionally we report if EoL code contains a security vulnerability even if the only fix is to upgrade to a more recent version. It is not in ISC's, nor the public's interest, to leave vulnerable code out there running. Mark -- 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: "Key : Delaying activation to match the DNSKEY TTL."
On Tue, Jul 05, 2011 at 02:28:13PM -0700, Paul B. Henson wrote: > I saw this message from dnssec-signzone around the time a previously > published key was due to be activated, and I'm not quite sure what it > means. Google is uncharacteristically silent about it ;). > > If someone could offer an explanation of why the activation was delayed > and whether I should care it would be much appreciated, thanks... The key is being published now, and its activation date (i.e., when it will start to be used to sign records) is in the near future: less than the TTL of the DNSKEY record from now. When the key starts signing, then someone could get an RRSIG generated by that key... but, if that same someone had a cached copy of the DNSKEY record from *before* the key was published, then validation could fail. So, what it's telling you is that named won't start signing records with this key until after the old DNSKEY record is guaranteed to have expired out of all the resolver caches. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
