Trying to understand DNSSEC and BIND versions better

Tue Jun 9 01:22:12 UTC 2009

In message <99E6A67A9DA87041A8020FBC11F480B3031CCEE4 at 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-bounces at lists.isc.org
> [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Mark Andrews
> Sent: Friday, June 05, 2009 12:23 AM
> To: Chris Adams
> Cc: comp-protocols-dns-bind at isc.org
> Subject: Re: Trying to understand DNSSEC and BIND versions better=20
> 
> 
> In message <eYSdnVoGu5EsGrXXnZ2dnUVZ_vudnZ2d at 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 <cmadams at 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 at 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: marka at isc.org
> _______________________________________________
> bind-users mailing list
> bind-users at 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: marka at isc.org