Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On 27-Aug-14 20:35, Doug Barton wrote: On 8/27/14 3:03 PM, Timothe Litt wrote: So you really meant that validating resolvers should only consult DLV if their administrator knows that users are looking-up names that are in the DLV? That's how I read your advice. You're correct. I don't see how that can work; hence we'll disagree. I think the only viable strategy for*resolvers* is to consult the DLV - as long as it exists. So that leads to a Catch-22, as ISC has stated that they will continue to provide the DLV as long as it is used. You're saying that people should continue to consult it as long as it exists. Now that the root is signed the traditional argument against continued indiscriminate use of the DLV is that it makes it easier for registries, service providers, etc. to give DNSSEC a low priority. You don't need me to provide DNSSEC for you, you can use the DLV. Based on my experience I think there is a lot of validity to that argument, although I personally don't think it's persuasive on its own. I don't want to see indiscriminate use of the DLV. See below. While I appreciate the tone of reasoned discourse in the message I'm responding to, what you have done is provide additional details to support your thesis that changing providers is hard. I'm not arguing the contrary position, so we can agree to agree on that. What you haven't done is provide any evidence to refute my thesis that It's hard != It's impossible. I'll even go so far as to agree with you that in some cases it's really, really hard. For me, it's impossible. I've stated why. I am a very small player - I run a network for my extended (multi-state) family, and some free services for a few hundred former colleagues. I considered the options that you suggested - they are not practical, affordable or both. No ISP in my geography will provide DNSSEC for reverse DNS. I have asked (in dnssec-deployment) for help in pressuring the ISPs to solve this problem. Comcast (which is not in my geography) has acknowledged the issue, and has had it on their list for several years. None of the others have gone even that far. What that leaves us with is your position (which I will state in an admittedly uncharitable way), Some of us would like to have the benefits of protecting our authoritative data with DNSSEC without having to endure the cost and inconvenience of migrating our resources to providers that support it. Therefore the entire Internet should use the DLV. In contrast, my position is that people and/or organizations which need the protection of DNSSEC should vote with their feet. In this way providers that offer DNSSEC will be rewarded, and those that do not will be punished. I would vote with my feet if I could. I can't. The problem with your market driven approach is that ISPs are largely unregulated monopolies. At least, for those of us who are based in residences/small businesses. I'm fortunate to have 2 cables pass my house - fiber and cable TV. Only the fiber provider has enough outbound bandwidth for site-site backup, which I get for $low 3 figures/mo. The cable TV-based provider says 'yes since you have business class service (static IPs), we will provide a fiber to your premises. First, there's the engineering study for $5 figures, then a construction fee, then %4 figures/month...unless you want serious bandwidth, in whch case it's more. So there's no competition. Neither cares about DNSSEC. Neither is required to care by regulation, RFC, ICANN/IANA or organized community pressure. The answer is different when you're an enterprise with a large budget. I've been there. Let us consolidate your voice data networks; sure, we'll eat the engineering costs of switching you to a few OC-48 fibers; saves us money maintaining all those copper wires. You want a couple of dark fibers, and a couple of hundred PI IP addresses routed - no problem. Switch your phone system to VoIP too? Oh, you got a quote from them, including running new fiber from the highway to your plant for free? Let me re-work our numbers. Can we shine your shoes? When you pay several $100K/mo for bandwidth per site, it's amazing how responsive vendors can be. So your approach works for some, according to the golden rule (she who has the gold, makes the rules.) Completely aside from what I believe to be the absurdity of your argument, the position I suggest will almost certainly result in market forces which encourage the deployment of DNSSEC. At bare minimum it has the moral value of rewarding providers who have done the right thing. I don't think it's absurd to note that people in my position - and there are a lot of us - are forced to use DLV for some cases. The most prominent is reverse DNS. We *can't* switch providers. We *can't* get IP addresses from other sources (and get them routed) without literally going bankrupt. Since no one can predict what names a validating resolver will be
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On 8/28/14 10:55 AM, Timothe Litt wrote: Aside from the use of the word 'absurdity', I'm not offended. I am trying to educate. And while I recognize that I'm arguing pragmatism with a market purist, It's nice to be called pure, in some context anyway. :) However as I pointed out I'm not simply arguing market forces, I'm also arguing the morality of rewarding those providers who do the right thing; and I'm quite specifically arguing the anti-pragmatist perspective that voting with your feet is important. Chris, I purposely did not invoke the spectre of Jim Reid because I did not agree with his violent opposition to the DLV when it was created. But now that we're in the signed root phase of DNSSEC deployment I think that argument has a lot more validity. hopefully the OP (and others) will learn why some of us have a slightly different view of how to get to the end goal. I agree that illuminating the different points of view is valuable, and I am happy to agree to disagree with you (and Chris Thompson) on this topic. And why my advice for resolvers is 'check DLV', while my advice for domain owners is 'take reasonable steps to stay/get out of DLV, but use it if you *must*'. We're actually not that far apart... ... I'm sorry to say that we are still quite far apart on specifics though. You continue to use the word impossible when what you mean is outside of the constraints I have created for myself. I was trying not to devolve into a discussion of your specific situation, but one really simple solution to your particular use case would be to move your stuff to a colo facility where they provide proper reverse DNS, signed delegations, etc. There are a world of other options, but you have designated a set of parameters within which you wish to operate, and a provider that does DNSSEC is outside of your parameters. That doesn't make it impossible, that makes it something you're not willing to do. Chris' message was an excellent example of his particular value of really, really hard, but even he points out that it's not the same as impossible. His organization has done the cost/benefit analysis and determined that having a DNSSEC chain from the root for their reverse delegations is not worth the cost of moving away from JANET. I don't know the politics anywhere near as well as Chris does, but I know them well enough to know that his organization is probably correct in their analysis. In any case, their network, their rules. I have no problem with that. And I want to reiterate one last time that I'm NOT saying that no one should use the DLV, or that no one should put new entries into it. If you or Chris have people that need to validate your reverse DNS, they should be given the information they need about using the DLV to do that. What I AM saying is that people should not be routinely advised to use the DLV, and that resolver operators should only use it if they have a good reason to. And with that, I'll let others chime in, as I don't think I'm saying anything new here. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
Timothe Litt l...@acm.org wrote: There are still registrars that don't accept DNSSEC records, and a non-trivial number of domain holders can't easily switch registrars. In some cases it isn't possible to switch to a better registrar, e.g. if you need DNSSEC for your reverse DNS. So yes, there is still value in DLV. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On 8/26/14 10:35 AM, Timothe Litt wrote: I think this is misleading, or at least poorly worded and subject to misinterpretation. I chose my words carefully, and I stand by them. I did not say that the DLV has no value, and I specifically mentioned that there are circumstances when it is valuable and should be used. You clearly have a different view, which is fine. When it comes to gTLDs, I completely reject the notion that users cannot change registrars. It can be hard, no doubt, but it's a cost/benefit analysis. If the benefit of DNSSEC outweighs the difficulty of moving, then it's worth it. If not, it's not. The fact that it's hard doesn't mean it's impossible. That said, I do recognize that there are situations where a chain of trust to the root is not possible (such as some reverse zones). Again, this becomes a cost/benefit analysis. For reverse zones if DNSSEC is important it may be worth the effort of changing providers, or even getting a PI assignment. For TLDs where DNSSEC is not yet available, a change may be in order. If enough people vote with their feet in this way those providers and TLDs that lose customers may reconsider their offerings. No one said it would be easy. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On 27-Aug-14 14:54, Doug Barton wrote: On 8/26/14 10:35 AM, Timothe Litt wrote: I think this is misleading, or at least poorly worded and subject to misinterpretation. I chose my words carefully, and I stand by them. The OP was asking about configuring a resolver (bind's). Where I thought there could be confusion is in conflating two issues: 1) Should validating resolvers consult the DLV? 2) Should entries be made in the DLV? So you really meant that validating resolvers should only consult DLV if their administrator knows that users are looking-up names that are in the DLV? That's how I read your advice. I don't see how that can work; hence we'll disagree. I think the only viable strategy for *resolvers* is to consult the DLV - as long as it exists. If you meant that an administrator should only put entries in DLV for a domain: a) If there is no direct trust path to the root; and b) the domain benefits from being DNSSEC-secured (know your user base) then we agree. I did not say that the DLV has no value, and I specifically mentioned that there are circumstances when it is valuable and should be used. You clearly have a different view, which is fine. When it comes to gTLDs, I completely reject the notion that users cannot change registrars. It can be hard, no doubt, but it's a cost/benefit analysis. If the benefit of DNSSEC outweighs the difficulty of moving, then it's worth it. If not, it's not. The fact that it's hard doesn't mean it's impossible. Impossible is a very high standard. DNSSEC is only one part of the cost/benefit analysis in choosing/sticking with a registrar. And part of the benefit of DNSSEC goes to the registrant's users, not all to the registrant - this is hard to account for. Also, it's not just the technical/financial difficulty of switching registrars. Some have policies/practices that some users find unacceptable; unfortunately, for quite some time those were the ones that offered DNSSEC. That's improving, but it's still an issue in some circles. DLV has a different set of costs (and benefits - especially when some resolvers don't consult it). If the question is how can I implement DNSSEC in my zones, the preferred path is certainly not DLV. But if the choice is a difficult/expensive switch of registrar or no DNSSEC, DLV is worth considering. That said, I do recognize that there are situations where a chain of trust to the root is not possible (such as some reverse zones). Again, this becomes a cost/benefit analysis. For reverse zones if DNSSEC is important it may be worth the effort of changing providers, or even getting a PI assignment. For TLDs where DNSSEC is not yet available, a change may be in order. If enough people vote with their feet in this way those providers and TLDs that lose customers may reconsider their offerings. No one said it would be easy. :) Doug I agree that a chain to the root is the preferred option. I would love to vote with my feet. I have a few small problems with that strategy. There is no ISP in my geography that provides dnssec reverse delegation for IPv4. Not for lack of complaints/escalations from me. There is only one ISP here that offers fiber speeds at prices that an individual can afford. So it can afford not to care. For IPv6 - well, I can't get IPv6 directly from any ISP, but my tunnel provider does allow DNSSEC reverse delegation. When my ISP finally implements IPv6 (promised for over 2 years, but again, they don't care), I'll have to choose between a direct IPv6 connection with no reverse DNSSEC, or sticking with my tunnel. A provider-independent IP addresses is out of reach for all but the largest/best financed organizations. Not just getting them, but the additional costs of having to get them routed. And just try to get an ISP to route a small number of IP addresses for a home/small business (or even medium business) customer...at any price. So yes, there are trade-offs and a cost/benefit analysis is helpful. And if you're a big enough customer and/or you're fortunate enough to have a choices that enable a direct trust chain to the root, we agree that is the preferred choice from a strictly DNSSEC perspective. Certainly DNSSEC is not easy. It's getting somewhat easier, though not fast enough. One way to make it easier - for now - is to encourage *resolvers* to consult DLV. That allows validated resolution of the domains that require DLV. That's a good thing. And that's where this thread started. I think that's the only part that's strictly on-topic for this list... smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On 8/27/14 3:03 PM, Timothe Litt wrote: So you really meant that validating resolvers should only consult DLV if their administrator knows that users are looking-up names that are in the DLV? That's how I read your advice. You're correct. I don't see how that can work; hence we'll disagree. I think the only viable strategy for*resolvers* is to consult the DLV - as long as it exists. So that leads to a Catch-22, as ISC has stated that they will continue to provide the DLV as long as it is used. You're saying that people should continue to consult it as long as it exists. Now that the root is signed the traditional argument against continued indiscriminate use of the DLV is that it makes it easier for registries, service providers, etc. to give DNSSEC a low priority. You don't need me to provide DNSSEC for you, you can use the DLV. Based on my experience I think there is a lot of validity to that argument, although I personally don't think it's persuasive on its own. While I appreciate the tone of reasoned discourse in the message I'm responding to, what you have done is provide additional details to support your thesis that changing providers is hard. I'm not arguing the contrary position, so we can agree to agree on that. What you haven't done is provide any evidence to refute my thesis that It's hard != It's impossible. I'll even go so far as to agree with you that in some cases it's really, really hard. What that leaves us with is your position (which I will state in an admittedly uncharitable way), Some of us would like to have the benefits of protecting our authoritative data with DNSSEC without having to endure the cost and inconvenience of migrating our resources to providers that support it. Therefore the entire Internet should use the DLV. In contrast, my position is that people and/or organizations which need the protection of DNSSEC should vote with their feet. In this way providers that offer DNSSEC will be rewarded, and those that do not will be punished. Completely aside from what I believe to be the absurdity of your argument, the position I suggest will almost certainly result in market forces which encourage the deployment of DNSSEC. At bare minimum it has the moral value of rewarding providers who have done the right thing. I realize that it's unpopular to state some of these ideas in such a direct way, and I hope no one is offended by one person's opinion. I also realize that those who wish to receive the benefits of DNSSEC without enduring the aforementioned costs will not like my argument. I can't help you there. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
Why would you expect them to succeed? If you use DLV you are
expecting anything for which DLV is used as a trust anchor to be
safe from being spoofed. The *only* way this can happen is to fail
if the DLV lookup fails for any reason.
Mark
In message 53fc7b35.6040...@redhat.com, Tomas Hozza writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello.
I found out that when bind is configured as recursive resolver with
dnssec-lookaside set to 'auto' and dlv.isc.org is unreachable, all
lookups for unsigned (UNSECURE) names fail even if the validation
succeeds (IOW the validation of NSEC3 answer proves that DS does not
exist so domain (name) is not signed).
I tested it with one server set up as forwarder running on 127.0.0.1@80
configured not to answer queries for dlv.isc.org (query will timeout).
I have bind (9.9.4-P2) configured with:
forward only;
forwarders { 127.0.0.1 port 80; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
Doing a lookup for (unsigned) google.com A record times out:
# dig @127.0.0.1 google.com A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 12157
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 26 14:08:03 CEST 2014
;; MSG SIZE rcvd: 39
in named log I can see:
...
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: in authva
lidated
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: resuming
nsecvalidate
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates potential closest encloser: 'com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 pro
ves
name does not exist: 'google.com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates optout
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: nonexiste
nce
proof(s) found
26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received validat
ion
completion event
26-Aug-2014 13:45:49.127 validator @0x7ff9745af3d0: dns_validator_destroy
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): nonexistence
validation OK
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): clone_results
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): done
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): stopeverything
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): cancelqueries
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): sendevents
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: in
dsfetched2: ncache nxrrset
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: plain DNSS
EC
returns unsecure (google.com): looking for DLV
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: looking fo
r
DLV google.com.dlv.isc.org
...
This looks to me that the result of DNSSEC validation of A record
for google.com proved that it is UNSECURE.
However the validation using DLV proceeds and fails in the end since
dlv.isc.org can not be resolved.
Doing a lookup for (signed) nic.cz A record succeeds:
[root@unused-4-247 ~]# dig @127.0.0.1 nic.cz A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 nic.cz A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 25002
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nic.cz. IN A
;; ANSWER SECTION:
nic.cz. 1163IN A
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
So you care enough about security to implement DNSSEC, but you run your
forwarder on port 80. Interesting...
- Kevin
On 8/26/2014 8:19 AM, Tomas Hozza wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello.
I found out that when bind is configured as recursive resolver with
dnssec-lookaside set to 'auto' and dlv.isc.org is unreachable, all
lookups for unsigned (UNSECURE) names fail even if the validation
succeeds (IOW the validation of NSEC3 answer proves that DS does not
exist so domain (name) is not signed).
I tested it with one server set up as forwarder running on 127.0.0.1@80
configured not to answer queries for dlv.isc.org (query will timeout).
I have bind (9.9.4-P2) configured with:
forward only;
forwarders { 127.0.0.1 port 80; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
Doing a lookup for (unsigned) google.com A record times out:
# dig @127.0.0.1 google.com A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 12157
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.IN A
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 26 14:08:03 CEST 2014
;; MSG SIZE rcvd: 39
in named log I can see:
...
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: in
authvalidated
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: resuming
nsecvalidate
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking for
relevant NSEC3
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates potential closest encloser: 'com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 proves
name does not exist: 'google.com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates optout
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: nonexistence
proof(s) found
26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received validation
completion event
26-Aug-2014 13:45:49.127 validator @0x7ff9745af3d0: dns_validator_destroy
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): nonexistence
validation OK
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): clone_results
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): done
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): stopeverything
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): cancelqueries
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): sendevents
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: in
dsfetched2: ncache nxrrset
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: plain DNSSEC
returns unsecure (google.com): looking for DLV
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: looking for
DLV google.com.dlv.isc.org
...
This looks to me that the result of DNSSEC validation of A record
for google.com proved that it is UNSECURE.
However the validation using DLV proceeds and fails in the end since
dlv.isc.org can not be resolved.
Doing a lookup for (signed) nic.cz A record succeeds:
[root@unused-4-247 ~]# dig @127.0.0.1 nic.cz A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 nic.cz A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 25002
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nic.cz.IN A
;; ANSWER SECTION:
nic.cz. 1163IN A 217.31.205.50
;; Query time: 7 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 26 14:12:21 CEST 2014
;; MSG SIZE rcvd: 51
I think this behavior (with unsigned records) may not be completely correct.
I think
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On Tue 26 Aug 2014 02:32:24 PM CEST, Kevin Darcy wrote:
So you care enough about security to implement DNSSEC, but you run your
forwarder on port 80. Interesting...
- Kevin
It is completely artificial setup for testing purpose only.
On 8/26/2014 8:19 AM, Tomas Hozza wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello.
I found out that when bind is configured as recursive resolver with
dnssec-lookaside set to 'auto' and dlv.isc.org is unreachable, all
lookups for unsigned (UNSECURE) names fail even if the validation
succeeds (IOW the validation of NSEC3 answer proves that DS does not
exist so domain (name) is not signed).
I tested it with one server set up as forwarder running on 127.0.0.1@80
configured not to answer queries for dlv.isc.org (query will timeout).
I have bind (9.9.4-P2) configured with:
forward only;
forwarders { 127.0.0.1 port 80; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
Doing a lookup for (unsigned) google.com A record times out:
# dig @127.0.0.1 google.com A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 12157
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.INA
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 26 14:08:03 CEST 2014
;; MSG SIZE rcvd: 39
in named log I can see:
...
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: in
authvalidated
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: resuming
nsecvalidate
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking
for
relevant NSEC3
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking
for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates potential closest encloser: 'com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
proves
name does not exist: 'google.com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates optout
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS:
nonexistence
proof(s) found
26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received
validation
completion event
26-Aug-2014 13:45:49.127 validator @0x7ff9745af3d0: dns_validator_destroy
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): nonexistence
validation OK
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): clone_results
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): done
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): stopeverything
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): cancelqueries
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): sendevents
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: in
dsfetched2: ncache nxrrset
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: plain
DNSSEC
returns unsecure (google.com): looking for DLV
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: looking
for
DLV google.com.dlv.isc.org
...
This looks to me that the result of DNSSEC validation of A record
for google.com proved that it is UNSECURE.
However the validation using DLV proceeds and fails in the end since
dlv.isc.org can not be resolved.
Doing a lookup for (signed) nic.cz A record succeeds:
[root@unused-4-247 ~]# dig @127.0.0.1 nic.cz A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 nic.cz A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 25002
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nic.cz.INA
;; ANSWER SECTION:
nic.cz.1163INA217.31.205.50
;;
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/2014 02:27 PM, Mark Andrews wrote:
Why would you expect them to succeed?
Because validation using root servers and authoritative servers proved
that the domain is intentionally unsecure.
If you use DLV you are
expecting anything for which DLV is used as a trust anchor to be
safe from being spoofed. The *only* way this can happen is to fail
if the DLV lookup fails for any reason.
I can understand that. It just didn't seem correct to me for the reason
stated above. Thanks for acknowledging that this behavior is expected.
Tomas
Mark
In message 53fc7b35.6040...@redhat.com, Tomas Hozza writes:
Hello.
I found out that when bind is configured as recursive resolver with
dnssec-lookaside set to 'auto' and dlv.isc.org is unreachable, all
lookups for unsigned (UNSECURE) names fail even if the validation
succeeds (IOW the validation of NSEC3 answer proves that DS does not
exist so domain (name) is not signed).
I tested it with one server set up as forwarder running on 127.0.0.1@80
configured not to answer queries for dlv.isc.org (query will timeout).
I have bind (9.9.4-P2) configured with:
forward only;
forwarders { 127.0.0.1 port 80; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
Doing a lookup for (unsigned) google.com A record times out:
# dig @127.0.0.1 google.com A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 12157
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 26 14:08:03 CEST 2014
;; MSG SIZE rcvd: 39
in named log I can see:
...
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: in authva
lidated
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: resuming
nsecvalidate
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates potential closest encloser: 'com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 pro
ves
name does not exist: 'google.com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates optout
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: nonexiste
nce
proof(s) found
26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received validat
ion
completion event
26-Aug-2014 13:45:49.127 validator @0x7ff9745af3d0: dns_validator_destroy
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): nonexistence
validation OK
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): clone_results
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): done
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): stopeverything
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): cancelqueries
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): sendevents
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: in
dsfetched2: ncache nxrrset
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: plain DNSS
EC
returns unsecure (google.com): looking for DLV
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: looking fo
r
DLV google.com.dlv.isc.org
...
This looks to me that the result of DNSSEC validation of A record
for google.com proved that it is UNSECURE.
However the validation using DLV proceeds and fails in the end since
dlv.isc.org can not be resolved.
Doing a lookup for (signed) nic.cz A record succeeds:
[root@unused-4-247 ~]# dig @127.0.0.1 nic.cz A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 nic.cz A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode:
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
In message 53fc827e.7090...@redhat.com, Tomas Hozza writes:
On 08/26/2014 02:27 PM, Mark Andrews wrote:
Why would you expect them to succeed?
Because validation using root servers and authoritative servers proved
that the domain is intentionally unsecure.
No. It only proves that there is not a trust path from the root
to the zone. This is *not* the same thing as saying the zone is
unsigned. It is insecure *with* *respect* *to* the root trust
anchor. It may or may not be insecure w.r.t. other trust anchors
like those distributed in the dlv.isc.org zone.
If you use DLV you are
expecting anything for which DLV is used as a trust anchor to be
safe from being spoofed. The *only* way this can happen is to fail
if the DLV lookup fails for any reason.
I can understand that. It just didn't seem correct to me for the reason
stated above. Thanks for acknowledging that this behavior is expected.
Tomas
Mark
In message 53fc7b35.6040...@redhat.com, Tomas Hozza writes:
Hello.
I found out that when bind is configured as recursive resolver with
dnssec-lookaside set to 'auto' and dlv.isc.org is unreachable, all
lookups for unsigned (UNSECURE) names fail even if the validation
succeeds (IOW the validation of NSEC3 answer proves that DS does not
exist so domain (name) is not signed).
I tested it with one server set up as forwarder running on 127.0.0.1@80
configured not to answer queries for dlv.isc.org (query will timeout).
I have bind (9.9.4-P2) configured with:
forward only;
forwarders { 127.0.0.1 port 80; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
Doing a lookup for (unsigned) google.com A record times out:
# dig @127.0.0.1 google.com A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 12157
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.IN A
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 26 14:08:03 CEST 2014
;; MSG SIZE rcvd: 39
in named log I can see:
...
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: in auth
va
lidated
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: resumin
g
nsecvalidate
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates potential closest encloser: 'com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 a
t
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 p
ro
ves
name does not exist: 'google.com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates optout
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 a
t
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: nonexis
te
nce
proof(s) found
26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received valid
at
ion
completion event
26-Aug-2014 13:45:49.127 validator @0x7ff9745af3d0: dns_validator_destroy
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): nonexistence
validation OK
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): clone_results
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): done
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): stopeverything
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): cancelqueries
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): sendevents
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: in
dsfetched2: ncache nxrrset
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: plain DN
SS
EC
returns unsecure (google.com): looking for DLV
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: looking
fo
r
DLV google.com.dlv.isc.org
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On Tue 26 Aug 2014 03:07:22 PM CEST, Mark Andrews wrote:
In message 53fc827e.7090...@redhat.com, Tomas Hozza writes:
On 08/26/2014 02:27 PM, Mark Andrews wrote:
Why would you expect them to succeed?
Because validation using root servers and authoritative servers proved
that the domain is intentionally unsecure.
No. It only proves that there is not a trust path from the root
to the zone. This is *not* the same thing as saying the zone is
unsigned. It is insecure *with* *respect* *to* the root trust
anchor. It may or may not be insecure w.r.t. other trust anchors
like those distributed in the dlv.isc.org zone.
OK, now I understand why it has to fail if configured to use DLV
but the validation using DLV failed for whatever reason.
Thank you!
If you use DLV you are
expecting anything for which DLV is used as a trust anchor to be
safe from being spoofed. The *only* way this can happen is to fail
if the DLV lookup fails for any reason.
I can understand that. It just didn't seem correct to me for the reason
stated above. Thanks for acknowledging that this behavior is expected.
Tomas
Mark
In message 53fc7b35.6040...@redhat.com, Tomas Hozza writes:
Hello.
I found out that when bind is configured as recursive resolver with
dnssec-lookaside set to 'auto' and dlv.isc.org is unreachable, all
lookups for unsigned (UNSECURE) names fail even if the validation
succeeds (IOW the validation of NSEC3 answer proves that DS does not
exist so domain (name) is not signed).
I tested it with one server set up as forwarder running on 127.0.0.1@80
configured not to answer queries for dlv.isc.org (query will timeout).
I have bind (9.9.4-P2) configured with:
forward only;
forwarders { 127.0.0.1 port 80; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
Doing a lookup for (unsigned) google.com A record times out:
# dig @127.0.0.1 google.com A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 12157
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.IN A
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 26 14:08:03 CEST 2014
;; MSG SIZE rcvd: 39
in named log I can see:
...
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: in auth
va
lidated
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: resumin
g
nsecvalidate
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates potential closest encloser: 'com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 a
t
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 p
ro
ves
name does not exist: 'google.com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates optout
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 a
t
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: nonexis
te
nce
proof(s) found
26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received valid
at
ion
completion event
26-Aug-2014 13:45:49.127 validator @0x7ff9745af3d0: dns_validator_destroy
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): nonexistence
validation OK
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): clone_results
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): done
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): stopeverything
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): cancelqueries
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): sendevents
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: in
dsfetched2: ncache nxrrset
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: plain DN
SS
EC
returns unsecure (google.com): looking for DLV
26-Aug-2014 13:45:49.128 validating
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 8/26/14 5:50 AM, Tomas Hozza wrote: | On 08/26/2014 02:27 PM, Mark Andrews wrote: | Why would you expect them to succeed? | | Because validation using root servers and authoritative servers | proved that the domain is intentionally unsecure. Tomas, It seems that Mark straightened you out a bit. :) I think it's worthwhile to discuss a little more of the theory for those watching the thread, and for the archives. The point of DLV initially was to provide a mechanism for sharing trust anchors for those that did not have a path through the root (which in the early days of course was everyone). Thus Mark's point that the lack of a path through the root not being conclusive is quite important. The other thing worth pointing out is that while it's certainly fine to test the DLV, and understand how it works, at this point in the evolution of DNSSEC the commonly accepted wisdom is that it should not be used routinely; and in fact should only be used when the admin knows that there is a TA in it that she needs, and that is not available with a path through the root. FWIW, Doug -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCAAGBQJT/LtLAAoJEFzGhvEaGryE8KcH/0V5YLHU5qDKp0zlaqt6TRlH Yt9taFQuQZhn3tdbYb/Y3L7HLkRhQGGHXvsCjbaF91tnaCtHKY7Jmrd0KQLszgkJ aXNocB8vG8nk8HNOVc3WQr0SNlGxTgX5zBzxTaonGW1RpxRjOoo2wFrZnRbYCR+G aHlvkRnjuzggtHHjMHNuMmnt54fraW62waDNgJrb7GDZjaiCmfg14o/VsH4h2J7U 5B0/kF0fHGjJ8QKafxNQfjlYe/25hqDae0NwxCAg3SQWHfxXHzOpf7Hi/mR7DbbS x1yOSOPdg7pgbJV+JpsMPaz4s0hOTWGnD9ykYM096dsjh6Jh3ztDNAyZ6Vqt2GY= =uQ3S -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
