Re: windows 2003 dns and bind9

2013-01-24 Thread Beavis
some points to check

- Any specific errors from the named.log?
- Tried querying win2k3 and the bind box separately? AXFR checks?

that's a good start


On Thu, Jan 24, 2013 at 12:37 AM, newbie newbie@gmail.com wrote:
 morning all...

 i am currently using windows server 2003 dns AD and run domain let say
 example.com, and now i have another domain example.org, i use bind9 as
 master of example.org and transfer to my windows dns and i set example.org
 in my windows dns as secondary but it did not work?? can anybody helpme??

 regards

 note: sorry for my bad english..
 ___
 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



-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Disclaimer:
http://goldmark.org/jeff/stupid-disclaimers/
___
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-2012-5689: BIND 9 with DNS64 enabled can unexpectedly terminate when resolving domains in RPZ

2013-01-24 Thread Michael McNally
ISC has learned of the potential for an error condition in BIND 9
that can cause a nameserver to terminate with an assertion failure
when processing queries if it has been configured to use both DNS64
and Response Policy Zones (RPZ).

CVE:   CVE-2012-5689
Document Version:  2.0
Posting date:  24 January 2013
Program Impacted:  BIND 9
Versions affected: 9.8.0-9.8.4-P1, 9.9.0-9.9.2-P1
Severity:  Low 
Exploitable:   Remotely 

Description:

   An error condition may occur when a nameserver which is configured
   to use DNS64 performs a  lookup for a record with an A record
   rewrite rule in a Response Policy Zone (RPZ.)  If the RPZ is
   unable to provide a  record for the name, but does provide
   a rewritten A record, then the DNS64 processing code will attempt
   to remap that A record into a  record.  Due to a coding
   error, this interaction between the RPZ database and the DNS64
   remapping code can cause the named process to terminate with an
   assertion failure.

   ISC believes the number of deployed systems that are using RPZ
   rewrite rules and also using DNS64 is extremely small; furthermore,
   the problem has an easy workaround (see below).  However, ISC
   policy calls for disclosure of any potential vulnerability in
   BIND 9, regardless of how rarely the conditions for such a
   vulnerability may occur in production environments. Thus, despite
   the CVSS score, we assess the severity as Low, and will integrate
   the bug fix into the next beta release of the affected versions.
   No security patch release versions are planned, as the workaround
   is simple and affords complete protection.

   To prevent accidental exposure of those using these features in
   combination, future versions of BIND 9 will include code to
   prevent any exploitation of this bug, beginning with beta versions
   scheduled to be released on January 24, 2013.  However, the
   suggested workaround is a complete remedy for those who are using
   DNS64 in conjunction with RPZ, and is recommended in preference
   to running beta code in a production environment.

Impact:

   Only nameservers that are configured to use both DNS64 and
   Response Policy Zones, and which are maintaining A rewrite rules
   but not  rewrite rules, will be affected by this problem -
   in other words, only systems that are using RPZ to rewrite DNS
   records into A records, then attempting to remap those same A
   records into  via DNS64.  Systems that only use RPZ to
   generate NXDOMAIN or CNAME or NOERROR/NODATA responses, or to
   rewrite other resource record types besides A, will not trigger
   the bug.

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)

Workaround:

   If using DNS64 and Response Policy Zones together, make sure the
   RPZ contains a  rewrite rule for every A rewrite rule. If
   the RPZ provides a  answer without the assistance of DNS64,
   the bug is not triggered.

Active exploits: 

   None

Solution: 

   If you are currently running one of the affected versions, you
   have the following options:

   1.  Employ the workaround (see above).
   2.  Wait for BIND releases that include a fix preventing
   possible exploitation of the bug.

Acknowledgements:

   ISC would like to thank Pories Ediansyah of Institut Teknologi
   Bandung for bringing this defect to our attention.

Document Revision History:

   1.0 - 17 January 2013 Advance Notification to Phase One.
   1.1 - 23 January 2013 Notification to Phase Two and Phase Three
   2.0 - 24 January 2013 Notification to Phase Four (Public)

Related Documents:

   See our BIND Security Matrix for a complete listing of Security
   Vulnerabilities and versions affected.
   https://www.isc.org/software/bind/security/matrix

   If you'd like more information on our Forum or product support
   please visit www.isc.org/software/guild or www.isc.org/support.

   Do you still have questions?  Questions regarding this advisory
   should go to security-offi...@isc.org

   Note: ISC patches only currently supported versions:
   http://www.isc.org/software/bind/versions.  When possible we
   indicate EOL versions affected.

ISC Security Vulnerability Disclosure Policy: 

   Details of our current security advisory policy and practice can
   be found at: https://www.isc.org/security-vulnerability-disclosure-policy


This Knowledge Base article https://kb.isc.org/article/AA-00855 is
the complete and official security advisory document.  There is
also a summary article located on our website and linking to here:
https://www.isc.org/software/bind/advisories/cve-2012-5689.

Legal Disclaimer: 

   Internet Systems Consortium (ISC) is providing this notice on
   an