Re: Trying to understand DNSSEC and BIND versions better
On Jun 12, 2009, at 1:50 AM, Adam Tkac wrote: On Wed, Jun 10, 2009 at 08:37:52PM -0700, Chris Buxton wrote: A few of our customers, running servers that they describe as experiencing high traffic (by their own standards), have had to have us rebuild BIND from the stock source code for them to solve frequent crashing during such high traffic episodes. Frequent in this case typically means that named either just dies or dumps core within a few seconds of starting up. Have you ever reported the problems to the Red Hat or Debian bug tracker? Generally you don't have to be experienced programmer. Your bug report can contain, for example, "named crashed with this INSIST failure: ..." only. Your vendor will ask you more information if needed. Since the servers that have been affected were not mine, I did not do so. I think it is a good idea to use package from your vendor because you don't have to watch bind-announce, don't have to compile each time when bind is updated etc. You can simply run "yum update" or "apt-get upgrade" and you can be sure you have software without security issues. But feel free to compile named yourself if you prefer this approach. There's a definite argument in favor of this. However, this assumes that the vendors are on the ball. For example, for a long time after 9.3.5-P2 was released, the RH build of BIND on RHEL 5 was still using the -P1 patch. This was a real problem for a small number of our customers. For most servers, the vendor-supplied builds work fine. But IMO for high-traffic servers, it makes sense for the server administrator to do it himself. This would be true whether or not the vendor supplied build had stability problems on that server. Chris Buxton Professional Services Men & Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying to understand DNSSEC and BIND versions better
On Wed, Jun 10, 2009 at 08:37:52PM -0700, Chris Buxton wrote: > On Jun 10, 2009, at 7:01 PM, Chris Adams wrote: >> Once upon a time, Chris Buxton said: >>> On the other hand, the builds from the Linux vendors have been less >>> than perfectly stable at moderately high levels of traffic. >>> Rebuilding >>> from stock source code has always fixed this problem. We've seen this >>> problem with both the Red Hat build and the Debian build. >> >> What do you mean by "moderately high levels of traffic"? We run RHEL 5 >> and its build of BIND with no troubles. I don't really see anything >> in >> the source RPM for BIND that would cause it to be any more or less >> stable than a build from the standard distribution (modulo stability >> bugs in specific BIND versions itself). > > I can't really be any more specific than I have been - the servers in > question are not our servers, and I'm not able to analyze the source > code of the patches and of BIND to see what might be causing problems. > > A few of our customers, running servers that they describe as > experiencing high traffic (by their own standards), have had to have us > rebuild BIND from the stock source code for them to solve frequent > crashing during such high traffic episodes. Frequent in this case > typically means that named either just dies or dumps core within a few > seconds of starting up. Have you ever reported the problems to the Red Hat or Debian bug tracker? Generally you don't have to be experienced programmer. Your bug report can contain, for example, "named crashed with this INSIST failure: ..." only. Your vendor will ask you more information if needed. > The Red Hat BIND SRPM applies a variety of patches that have been back- > ported from later versions. These patches appear to not be 100% > compatible with the older code they use as a base. When we have torn > apart the SRPM, replacing the base source code and disabling all patches > except the one that changes the path to the PID files, and then rebuilt > the RPM, the result has been able to hold up for these customers. In such > cases, we're not changing the configure options, we're installing the > result on the same servers that are falling over with the RH-supplied > version, and the result is a server that runs and doesn't crash or dump > core. I don't think patches are incompatible. As I wrote above please open a bug report if you think they are. I think it is a good idea to use package from your vendor because you don't have to watch bind-announce, don't have to compile each time when bind is updated etc. You can simply run "yum update" or "apt-get upgrade" and you can be sure you have software without security issues. But feel free to compile named yourself if you prefer this approach. Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying to understand DNSSEC and BIND versions better
On Jun 10, 2009, at 7:01 PM, Chris Adams wrote: Once upon a time, Chris Buxton said: On the other hand, the builds from the Linux vendors have been less than perfectly stable at moderately high levels of traffic. Rebuilding from stock source code has always fixed this problem. We've seen this problem with both the Red Hat build and the Debian build. What do you mean by "moderately high levels of traffic"? We run RHEL 5 and its build of BIND with no troubles. I don't really see anything in the source RPM for BIND that would cause it to be any more or less stable than a build from the standard distribution (modulo stability bugs in specific BIND versions itself). I can't really be any more specific than I have been - the servers in question are not our servers, and I'm not able to analyze the source code of the patches and of BIND to see what might be causing problems. A few of our customers, running servers that they describe as experiencing high traffic (by their own standards), have had to have us rebuild BIND from the stock source code for them to solve frequent crashing during such high traffic episodes. Frequent in this case typically means that named either just dies or dumps core within a few seconds of starting up. The Red Hat BIND SRPM applies a variety of patches that have been back- ported from later versions. These patches appear to not be 100% compatible with the older code they use as a base. When we have torn apart the SRPM, replacing the base source code and disabling all patches except the one that changes the path to the PID files, and then rebuilt the RPM, the result has been able to hold up for these customers. In such cases, we're not changing the configure options, we're installing the result on the same servers that are falling over with the RH-supplied version, and the result is a server that runs and doesn't crash or dump core. We have not bothered to build a .deb package for Ubuntu, just compiled the stock source code with fairly standard options. Again, this has always solved the problem for the affected customers. One such case was the most reliable at producing rapid core dumps that I have personally seen, until we upgraded them. Chris Buxton Professional Services Men & Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying to understand DNSSEC and BIND versions better
Once upon a time, Chris Buxton said: > On the other hand, the builds from the Linux vendors have been less > than perfectly stable at moderately high levels of traffic. Rebuilding > from stock source code has always fixed this problem. We've seen this > problem with both the Red Hat build and the Debian build. What do you mean by "moderately high levels of traffic"? We run RHEL 5 and its build of BIND with no troubles. I don't really see anything in the source RPM for BIND that would cause it to be any more or less stable than a build from the standard distribution (modulo stability bugs in specific BIND versions itself). -- Chris Adams 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
Re: Trying to understand DNSSEC and BIND versions better
On Jun 9, 2009, at 5:21 PM, Mark Andrews wrote: In message <20090609113700.ga6...@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 <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 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. The change to the default value of allow-recursion is still tripping up our customers. Otherwise, I agree. On the other hand, the builds from the Linux vendors have been less than perfectly stable at moderately high levels of traffic. Rebuilding from stock source code has always fixed this problem. We've seen this problem with both the Red Hat build and the Debian build. Chris Buxton Professional Services Men & Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying to understand DNSSEC and BIND versions better
In message <20090609113700.ga6...@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 <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 > > 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-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 , 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 " is your friend. This will let > > > you see what is failing to validate. > > > > > > "dig +cd +multi DNSKEY " will provide you with the > > > keyids necessary to check the signatures. > > > > > > "dig +cd +multi DS " will provide you with the DS > > > records s
Re: Trying to understand DNSSEC and BIND versions better
On Tue, Jun 09, 2009 at 11:22:12AM +1000, Mark Andrews wrote: > > 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 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 > > -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 , 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 " is your friend. This will let > > you see what is failing to validate. > > > > "dig +cd +multi DNSKEY " will provide you with the > > keyids necessary to check the signatures. > > > > "dig +cd +multi DS " 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 ." 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 fou
Re: Trying to understand DNSSEC and BIND versions better
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 , 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 " is your friend. This will let > you see what is failing to validate. > > "dig +cd +multi DNSKEY " will provide you with the > keyids necessary to check the signatures. > > "dig +cd +multi DS " 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 ." 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 >
RE: Trying to understand DNSSEC and BIND versions better
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 , 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 " is your friend. This will let you see what is failing to validate. "dig +cd +multi DNSKEY " will provide you with the keyids necessary to check the signatures. "dig +cd +multi DS " 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 ." 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 > 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/l
Re: Trying to understand DNSSEC and BIND versions better
In message , 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 " is your friend. This will let you see what is failing to validate. "dig +cd +multi DNSKEY " will provide you with the keyids necessary to check the signatures. "dig +cd +multi DS " 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 ." 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 > 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
Trying to understand DNSSEC and BIND versions better
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)? 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). 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. 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 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
