Re: www.ncbi.nlm.nih.gov / pubmed
On 08/18/2010 06:55 PM, Dave Sparro wrote: On 8/18/2010 1:12 PM, Casey Deccio wrote: On Wed, Aug 18, 2010 at 9:48 AM, Dave Sparrodspa...@gmail.com wrote: On 8/18/2010 8:30 AM, Phil Mayers wrote: ...since the ncbi zone is an unsigned child zone, there needs to be an NSEC/NSEC3 record to prove the absence of the DS record, and have a secure delegation to an unsigned child zone. It sounds to me like DNSSEC validation is working as designed. If your DNS server's users are complaining about not being able to resolve something that fails validation, the question you need to ask is do your end-users really want you to do DNSSEC validation for them? If you're asking for a workaround for when validation fails, there's not much point to doing the validation. Insecure delegations are not a work-around, but are rather a provision for delegated child zones that have not implemented DNSSEC. The parent zone (and its authoritative servers) must be properly configured to handle authenticated denial of existence using NSEC or NSEC3. Specifically, they must use these RRs to prove the non-existence of a DS RR for an unsigned child zone, whose existence would otherwise indicate a secure delegation. If the proper NSEC/NSEC3 RRs are not returned, or are not thought to be authentic, then there is a broken chain because the resolver cannot prove that the delegation is insecure. In the following diagram, note the diamond-shaped NSEC3 node, whose presence (when properly authenticated) proves the insecure delegation to ncbi.nlm.nih.gov: http://dnsviz.net/d/www.ncbi.nlm.nih.gov/dnssec/ It seems to me that the OP wanted a work-around to the fact that his end users couldn't use the website due to a validation failure. It still seems to me that working around that situation misses the point of using DNSSEC. I did, and I disagree that it misses the point. I wanted a *short term* workaround for that zone, while the site fixed their DNSSEC. I had satisfied myself that it was a DNSSEC signing mistake, and faced an unpalatable choice - disable validation globally for the duration of a single site repair period (sacrificing the benefits of DNSSEC) or lose connectivity to that site. Had the site been more important to us, it would have been no choice at all - I would have been instructed to disable validation. I think DNSSEC is very important, but I also think mistakes will happen, and that sites will want the ability to be forgiving for a grace period. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
I agree with this idea. Sorta like when a browser is presented with an invalid SSL cert by a website. It could be that you put in example.com when the cert is for www.example.com or in the case of a self-signed cert, as long as I am not giving them sensitive data, I, the user, can accept or deny the invalid cert. And we have the choice(at least in Firefox) to accept that invalid cert forever or just for the current session with that site. I agree that this would be a useful feature. Maybe an add-on 'zone' file where we enumerate the broken domains we want to accept with an expiration date, not to exceed x numbers of days. That way we don't add a domain and mistype the expiration date or forget we created an exception for it. Lyle Giese LCR Computer Services, Inc. I did, and I disagree that it misses the point. I wanted a *short term* workaround for that zone, while the site fixed their DNSSEC. I had satisfied myself that it was a DNSSEC signing mistake, and faced an unpalatable choice - disable validation globally for the duration of a single site repair period (sacrificing the benefits of DNSSEC) or lose connectivity to that site. Had the site been more important to us, it would have been no choice at all - I would have been instructed to disable validation. I think DNSSEC is very important, but I also think mistakes will happen, and that sites will want the ability to be forgiving for a grace period. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: www.ncbi.nlm.nih.gov / pubmed
It comes right up in Firefox but prompts for a username and password. Dig shows: dig www.ncbi.nlm.nih.gov ; DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 www.ncbi.nlm.nih.gov ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 22983 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ncbi.nlm.nih.gov. IN A ;; ANSWER SECTION: www.ncbi.nlm.nih.gov. 600 IN CNAME www.wip.ncbi.nlm.nih.gov. www.wip.ncbi.nlm.nih.gov. 30IN A 130.14.29.110 ;; AUTHORITY SECTION: wip.ncbi.nlm.nih.gov. 3600IN NS gslb03.nlm.nih.gov. wip.ncbi.nlm.nih.gov. 3600IN NS gslb01.nlm.nih.gov. wip.ncbi.nlm.nih.gov. 3600IN NS gslb02.nlm.nih.gov. ;; Query time: 84 msec ;; SERVER: 10.0.4.99#53(10.0.4.99) ;; WHEN: Wed Aug 18 08:14:44 2010 ;; MSG SIZE rcvd: 139 -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Phil Mayers Sent: Wednesday, August 18, 2010 6:49 AM To: bind-users@lists.isc.org Subject: www.ncbi.nlm.nih.gov / pubmed All, It seems this zone is broken as of a couple of days ago. Is anyone else seeing it? Is there an appropriate bind workaround? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Proud partner. Susan G. Komen for the Cure. 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
Re: www.ncbi.nlm.nih.gov / pubmed
On 18/08/10 13:30, Phil Mayers wrote: On 18/08/10 13:15, Lightner, Jeff wrote: It comes right up in Firefox but prompts for a username and password. Do you have DNSSEC validation enabled? Because as per my email, it's a DNSSEC problem. Damn - in fact sorry, scratch that. I realise my original email said nothing of the sort! I blame the stress of moving house ;o) After a bit of investigation, it seems that the problem is a missing NSEC/NSEC3 record in the empty reply for: $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds ...since the ncbi zone is an unsigned child zone, there needs to be an NSEC/NSEC3 record to prove the absence of the DS record, and have a secure delegation to an unsigned child zone. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On 18/08/10 13:15, Lightner, Jeff wrote: It comes right up in Firefox but prompts for a username and password. Do you have DNSSEC validation enabled? Because as per my email, it's a DNSSEC problem. After a bit of investigation, it seems that the problem is a missing NSEC/NSEC3 record in the empty reply for: $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds ...since the ncbi zone is an unsigned child zone, there needs to be an NSEC/NSEC3 record to prove the absence of the DS record, and have a secure delegation to an unsigned child zone. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On Wed, Aug 18, 2010 at 5:30 AM, Phil Mayers p.may...@imperial.ac.uk wrote: After a bit of investigation, it seems that the problem is a missing NSEC/NSEC3 record in the empty reply for: $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds ...since the ncbi zone is an unsigned child zone, there needs to be an NSEC/NSEC3 record to prove the absence of the DS record, and have a secure delegation to an unsigned child zone. The problem was that three out of the five servers authoritative for nlm.nih.gov were serving a version of the zone that did not include DNSKEY RRs or any other DNSSEC-required RRs (RRSIG, NSEC3, etc). If your resolver queried any of those three it got a response, but it was incomplete. This has been a fairly common problem among new DNSSEC deployments. Sometimes the problem is a slave that is not DNSSEC capable. Sometimes it's a slave not NSEC3-capable serving a zone signed with NSEC3 (which creates the issue for insecure delegations). In this case, I'm pretty sure the servers are capable of DNSSEC because they are serving the signed nih.gov zone just fine, so perhaps they got their nlm.nih.gov zone data from the wrong place. Often, BIND users don't notice these types of errors because BIND makes a special effort to find a valid response, if validation is enabled. However, if your validating server is behind an upstream proxy DNS recursive server, you may not have that choice. Likewise, a zone may not have the redundancy administrators think it has if you're only getting valid DNSSEC responses from a fraction of your authoritative servers. Regards, Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On 8/18/2010 8:30 AM, Phil Mayers wrote: On 18/08/10 13:15, Lightner, Jeff wrote: It comes right up in Firefox but prompts for a username and password. Do you have DNSSEC validation enabled? Because as per my email, it's a DNSSEC problem. After a bit of investigation, it seems that the problem is a missing NSEC/NSEC3 record in the empty reply for: $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds ...since the ncbi zone is an unsigned child zone, there needs to be an NSEC/NSEC3 record to prove the absence of the DS record, and have a secure delegation to an unsigned child zone. It sounds to me like DNSSEC validation is working as designed. If your DNS server's users are complaining about not being able to resolve something that fails validation, the question you need to ask is do your end-users really want you to do DNSSEC validation for them? If you're asking for a workaround for when validation fails, there's not much point to doing the validation. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On Wed, Aug 18, 2010 at 9:48 AM, Dave Sparro dspa...@gmail.com wrote: On 8/18/2010 8:30 AM, Phil Mayers wrote: ...since the ncbi zone is an unsigned child zone, there needs to be an NSEC/NSEC3 record to prove the absence of the DS record, and have a secure delegation to an unsigned child zone. It sounds to me like DNSSEC validation is working as designed. If your DNS server's users are complaining about not being able to resolve something that fails validation, the question you need to ask is do your end-users really want you to do DNSSEC validation for them? If you're asking for a workaround for when validation fails, there's not much point to doing the validation. Insecure delegations are not a work-around, but are rather a provision for delegated child zones that have not implemented DNSSEC. The parent zone (and its authoritative servers) must be properly configured to handle authenticated denial of existence using NSEC or NSEC3. Specifically, they must use these RRs to prove the non-existence of a DS RR for an unsigned child zone, whose existence would otherwise indicate a secure delegation. If the proper NSEC/NSEC3 RRs are not returned, or are not thought to be authentic, then there is a broken chain because the resolver cannot prove that the delegation is insecure. In the following diagram, note the diamond-shaped NSEC3 node, whose presence (when properly authenticated) proves the insecure delegation to ncbi.nlm.nih.gov: http://dnsviz.net/d/www.ncbi.nlm.nih.gov/dnssec/ Regards, Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On 8/18/2010 1:12 PM, Casey Deccio wrote: On Wed, Aug 18, 2010 at 9:48 AM, Dave Sparrodspa...@gmail.com wrote: On 8/18/2010 8:30 AM, Phil Mayers wrote: ...since the ncbi zone is an unsigned child zone, there needs to be an NSEC/NSEC3 record to prove the absence of the DS record, and have a secure delegation to an unsigned child zone. It sounds to me like DNSSEC validation is working as designed. If your DNS server's users are complaining about not being able to resolve something that fails validation, the question you need to ask is do your end-users really want you to do DNSSEC validation for them? If you're asking for a workaround for when validation fails, there's not much point to doing the validation. Insecure delegations are not a work-around, but are rather a provision for delegated child zones that have not implemented DNSSEC. The parent zone (and its authoritative servers) must be properly configured to handle authenticated denial of existence using NSEC or NSEC3. Specifically, they must use these RRs to prove the non-existence of a DS RR for an unsigned child zone, whose existence would otherwise indicate a secure delegation. If the proper NSEC/NSEC3 RRs are not returned, or are not thought to be authentic, then there is a broken chain because the resolver cannot prove that the delegation is insecure. In the following diagram, note the diamond-shaped NSEC3 node, whose presence (when properly authenticated) proves the insecure delegation to ncbi.nlm.nih.gov: http://dnsviz.net/d/www.ncbi.nlm.nih.gov/dnssec/ It seems to me that the OP wanted a work-around to the fact that his end users couldn't use the website due to a validation failure. It still seems to me that working around that situation misses the point of using DNSSEC. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On Wed, Aug 18, 2010 at 10:55 AM, Dave Sparro dspa...@gmail.com wrote: It seems to me that the OP wanted a work-around to the fact that his end users couldn't use the website due to a validation failure. It still seems to me that working around that situation misses the point of using DNSSEC. I read your response only in the context of the quoted text and didn't notice the text from the original post asking if there was a BIND work-around. Hence my lengthy discourse on insecure delegation... Regarding the work-around, I'm not sure how BIND's keep trying algorithm is currently implemented and if it induces queries to other servers to find NSEC/NSEC3 RRs if they aren't present in the first response accompanying an NXDOMAIN or authoritative response with empty answer section. Regards, Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
