In message <99e6a67a9da87041a8020fbc11f480b3031cc...@exvs01.dsw.net>, "Jeff Lig htner" writes: > 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
I've yet to see a vendor back port every bug fix and that is what would be required to really support a product in a OS which is at EOL by the producer. Mark > -----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=20 > > > 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... > >=20 > > 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? > >=20 > > In both cases, what kind of CPU and/or RAM overhead will large-scale > use > > of DNSSEC add? > > --=20 > > 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 > --=20 > 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 > =20 > 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. > ---------------------------------- -- 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
