BIND versions on RHEL (e.g. 9.3.4-6.0.3.P1.el5_2) have backported
patches from later BIND versions so it isn't exactly the same animal as
the EOL 9.3 which is why it isn't listed simply as 9.3

-----Original Message-----
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark Andrews
Sent: Friday, June 05, 2009 12:23 AM
To: Chris Adams
Cc: comp-protocols-dns-b...@isc.org
Subject: Re: Trying to understand DNSSEC and BIND versions better 


In message <eysdnvogu5esgrxxnz2dnuvz_vudn...@posted.hiwaay2>, Chris
Adams write
s:
> Since I read that the root is supposed to be signed by the end of the
> year, I am just trying to understand DNSSEC support and the various
> versions of BIND a little better here, so please don't throw too many
> rocks if I ask something stupid...
> 
> I run the nameservers for an ISP.  For the recursive servers, what are
> the hazzards in enabling DNSSEC (once the root is signed, so no DLV
> necessary I guess)?

        Once the root is signed you will be able to validation answers
        where there is a unbroken chaing of trust.  DLV will still be
        useful for zones were the TLD isn't yet signed or there is
        another break in the chain of trust.

> I know the things that generally break with
> "regular" DNS, but I don't know that with DNSSEC (I know there have
been
> DLV troubles but that's it).

        Not having a clean EDNS path between the validator and
        authoritative server can result in validation failures.
        EDNS responses are bigger that plain DNS and may result in
        fagmented responses.  You need to ensure that any NAT's and
        firewalls are configured to handle fragments UDP responses
        up 4096 bytes with a modern BIND.  Any forwarders used
        should also support EDNS and preferably be performing
        validation as well.

        Failure to re-sign a zone will cause lookups to fail.
        Failure to update DS records on DNSKEY changes will cause
        lookups to fail.  Failure to update DLV records on DNSKEY
        changes will cause lookups to fail.

        "dig +cd +dnssec <query>" is your friend.  This will let
        you see what is failing to validate.

        "dig +cd +multi DNSKEY <zone>" will provide you with the
        keyids necessary to check the signatures.

        "dig +cd +multi DS <zone>" will provide you with the DS
        records so you can check the linkage between parent and
        child.  Look at the key id field.

        "dig +cd +multi DLV <zone>.<dlvroot>" will provide you with the
DS
        records so you can check the linkage between parent and
        child.  Look at the key id field.

        If the zone is using NSEC3 then nsec3hash can be used to
        check workout in the NSEC3 records are sane.

        "date -u +%Y%m%d%H%M%S" returns the system date in a form
        that is easy to comare to the dates in the RRSIG records.

        A understand of how DNSSEC works is useful.

        Checking if you get a DNSKEY returned, without +cd, at each zone
        cut is useful for working out where to examine more closely.

        dig, date and a understanding of DNSSEC is all you should
        need to identify a configuration error.  If the keyid match
        and timestamps are good and associated NSEC/NSEC3 appear
        to be sane the you will most probably have found a
        implementation bug.

> Currently, my servers run BIND 9.3.4-10.P1 (as patched by Red Hat in
> RHEL; we typically stick with their security patched version, since
> that's what we pay them for).  What does that mean with .ORG for
> example, where NSEC3 is used?  Would we just not see NXDOMAIN
responses
> as validated (and what happens to unvalidated responses)?  I've put in
a
> request to Red Hat to update to a version that supports NSEC3 but I
> don't know what their response will be yet.

        BIND 9.3 is already at EOL.

> For our authoritative servers, we'll need to set up a system to sign
the
> zones.  Is it expected that ISPs will sign every zone they serve, or
> just the domains we consider "important"?  What kind of problems might
> be expected here?
> 
> In both cases, what kind of CPU and/or RAM overhead will large-scale
use
> of DNSSEC add?
> -- 
> Chris Adams <cmad...@hiwaay.net>
> Systems and Network Administrator - HiWAAY Internet Services
> I don't speak for anybody but myself - that's enough trouble.
> _______________________________________________
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: ma...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
 
Please consider our environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
information and is for the sole use of the intended recipient(s). If you are 
not the intended recipient, any disclosure, copying, distribution, or use of 
the contents of this information is prohibited and may be unlawful. If you have 
received this electronic transmission in error, please reply immediately to the 
sender that you have received the message in error, and delete it. Thank you.
----------------------------------
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to