Trying to understand DNSSEC and BIND versions better
Mark Andrews
marka at isc.org
Wed Jun 10 00:21:26 UTC 2009
In message <20090609113700.GA6813 at evileye.atkac.englab.brq.redhat.com>, Adam Tk
ac writes:
> On Tue, Jun 09, 2009 at 11:22:12AM +1000, Mark Andrews wrote:
> >
> > 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
>
> This is neverending discord between you (upstream) and vendors.
>
> You are right the ideal approach is to backport all fixes but it
> simply consumes much manpower. Update to newer version is not possible
> because there are configuration incompatibilities.
>
> Optimal software from economic perspective is usually different from
> optimal software from programming perspective. If you combine both
> perspectives you probably get answer why vendors backport patches only
> for issues which are reported by their customers.
>
> Regards, Adam
There are very few backwards compatiblilty issues with BIND
in terms of configuration files. If you ignore the logging
stanza you should be able take most BIND 8.1 configuration
files and have BIND 9.6.1 use it. There are even tools in
the distribution to take a BIND 4 configuration file and
convert it to BIND 8/9 format and use it.
The master files go back to the earliest version of BIND 4.
New version are just less tolerent of errors in the master
files. Correct master files from 2 decades ago just work.
Almost all the changes in major revisions is new functionality.
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
> > _______________________________________________
> > bind-users mailing list
> > bind-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> --
> Adam Tkac, Red Hat, Inc.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users
mailing list