Subject: [perpass] Is DNSDEC a viable technology for perpass?

From: Trevor Freeman <[email-masked]>
Date: Mon, 28 Apr 2014 18:38:04 +0000

We have a range of technologies in the toolkit to address issues identified by perpass.

One of the candidate technologies is DNSSEC. At a technology level it has much to commend it.

The vast majority of critical TLDs are signed, so another good point in its favor.

However when you look at the next tier down, the statistics point to a problem.

According to the Verisign labs scoreboard, 340K+ domains in the .com namespace are secured by DNSSEC
http://scoreboard.verisignlabs.com/

If you express that number as % that is about 0.4% and the growth trend is about 0.1% per year
http://scoreboard.verisignlabs.com/percent-trace.png

The trend seems about 2 orders of magnitude below where we need to be for DNSSEC to be viable in a realistic timescale.

Am I misinterpreting the data? If not, then do we have consensus on what is blocking deployment?

Trevor

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Apr 2014 14:47:00 -0400

> Am I misinterpreting the data? If not, then do we have consensus on what is blocking deployment?

Given that most of the registered domains are garbage, I suspect you'd need to use a better methodology to learn anything from this measurement.

---

From: Noel David Torres Taño <[email-masked]>
Date: Mon, 28 Apr 2014 21:01:52 +0100

El lun, 28-04-2014 a las 18:38 +0000, Trevor Freeman escribió:
> The trend seems about 2 orders of magnitude below where we need to be
> for DNSSEC to be viable in a realistic timescale.
> 
>  
> 
Which are the numbers for .org ?

This one should have a little percentage of garbage, parked domains,
etc. Moreover, it is kess used by corporations with large IT departments
and more used by small organizations like Libre Software projects.

And it is very important to trust the software you download.

Regards

Noel
er Envite

---

From: Warren Kumari <[email-masked]>
Date: Mon, 28 Apr 2014 16:20:20 -0400

> One of the candidate technologies is DNSSEC. At a technology level it has

For which aspects of perpass?  DNSSEC provides no encryption, so the
fact that I'm browsing to something on www.nakedfurries.com is visible
to all...

Don't get me wrong -- I'm a big DNSSEC (and DANE :-)) proponent, but
folk often seem to miss the fact that DNSSEC doesn't do what the name
implies...

W

> The trend seems about 2 orders of magnitude below where we need to be for
> DNSSEC to be viable in a realistic timescale.
>
>
>
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Trevor Freeman <[email-masked]>
Date: Mon, 28 Apr 2014 20:46:45 +0000

Hi Warren,

Granted DNNSEC does not by itself provide encryption but that is like saying X.509 does not do encryption, all it does is sign keys.  Generally there are two ways DNNSEC could be useful. One way, as you point out is to authenticate encryption keys. The other way is to detect attempts to subvert DNS name resolution which may induce me to disclose information to someone. We cannot assume all pervasive monitoring is totally passive. 

Trevor

-----Original Message-----
From: Warren Kumari [mailto:[email-masked]] 
Sent: Monday, April 28, 2014 1:20 PM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: [perpass] Is DNSDEC a viable technology for perpass?

> One of the candidate technologies is DNSSEC. At a technology level it 

For which aspects of perpass?  DNSSEC provides no encryption, so the fact that I'm browsing to something on www.nakedfurries.com is visible to all...

Don't get me wrong -- I'm a big DNSSEC (and DANE :-)) proponent, but folk often seem to miss the fact that DNSSEC doesn't do what the name implies...

W

---

From: Trevor Freeman <[email-masked]>
Date: Mon, 28 Apr 2014 21:16:37 +0000

Hi Noel,

If DNNSEC is used in corporations, that may be an interesting data point but perpass is specify looking at the interne so it does not help much.

I understand they could be some benefit to adding some other filter to the data but the number to try and try to add a better quality metric. But absent that, the number is what is it. Happy to have the discussion on how we would consider what to filter on and maybe Verisign could provide more attributes with the data for use to mine the information.

I did some ad-hoc research and amongst the prominent internet services or financial institutions, the seems little evidence of DNSSEC.  The only bright spot seemed to be government web sites, though here the deployment was still inconsistent in that government agencies have many web sites not part of the base domain and these were often not signed.

Trevor

-----Original Message-----
From: perpass [mailto:[email-masked]] On Behalf Of Noel David Torres Taño
Sent: Monday, April 28, 2014 1:02 PM
To: [email-masked]
Subject: Re: [perpass] Is DNSDEC a viable technology for perpass?

El lun, 28-04-2014 a las 18:38 +0000, Trevor Freeman escribió:

> We have a range of technologies in the toolkit to address issues

> identified by perpass.

> One of the candidate technologies is DNSSEC. At a technology level it

> has much to commend it.

> The vast majority of critical TLDs are signed, so another good point

> in its favor.

> However when you look at the next tier down, the statistics point to a

> problem.

> According to the Verisign labs scoreboard, 340K+ domains in the .com

> namespace are secured by DNSSEC

> If you express that number as % that is about 0.4% and the growth

> trend is about 0.1% per year

> Am I misinterpreting the data? If not, then do we have consensus on

> what is blocking deployment?

This one should have a little percentage of garbage, parked domains, etc. Moreover, it is kess used by corporations with large IT departments and more used by small organizations like Libre Software projects.

Regards

Noel

er Envite

---

From: manning bill <[email-masked]>
Date: Mon, 28 Apr 2014 14:30:05 -0700

two data points:

- Comcast has greatly facilitated the e2e authentication model by funding DNSMASQ to support DNSSEC validation.   Since this piece was missing, the landscape has changed.
- Paul Hoffman has pulled together a functional replacement for the DNS APIs…   see:  http://www.vpnc.org/getdns-api/   This gets past the validator and into the Application.

I -think- that there is an actual path now for DNSSEC.  If you are looking for opaqueness,   consider this third bit:

- http://www.isi.edu/ant/tdns/index.html   …   swaps out UDP for TLS as the DNS transport.

YMMV of course.   Chunks of this development and testing will no doubt occur in the ISI/RINOC testbed.

/bill
Neca eos omnes.  Deus suos agnoscet.

---

From: Trevor Freeman <[email-masked]>
Date: Mon, 28 Apr 2014 21:32:06 +0000

I spoke to soon. While the US government domains  is signed, the actual web site is not in many cases.
For example:
www.dhs.gov<http://www.dhs.gov> is a cname entry www.dhs.gov.edgekey.net<http://www.dhs.gov.edgekey.net> which is unsigned.
This is in turn a CNAME to another unsigned domain

www.dhs.gov.edgekey.net is a CNAME to e6485.dscb.akamaiedge.net

From: perpass [mailto:[email-masked]] On Behalf Of Trevor Freeman
Sent: Monday, April 28, 2014 2:17 PM
To: Noel David Torres Taño; [email-masked]
Subject: Re: [perpass] Is DNSDEC a viable technology for perpass?

Hi Noel,

Trevor

-----Original Message-----
From: perpass [mailto:[email-masked]] On Behalf Of Noel David Torres Taño
Sent: Monday, April 28, 2014 1:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [perpass] Is DNSDEC a viable technology for perpass?

Regards

Noel

er Envite

---

From: Dan York <[email-masked]>
Date: Mon, 28 Apr 2014 21:47:00 +0000

Trevor,

On Apr 28, 2014, at 2:38 PM, Trevor Freeman <[email-masked]<mailto:[email-masked]>>
 wrote:

Which of the perpass issues do you see DNSSEC helping with?  If I look at http://tools.ietf.org/html/draft-trammell-perpass-ppa-01 or http://tools.ietf.org/html/draft-tschofenig-perpass-surveillance-01 or other documents that have been circulated, they are almost all related to concerns around privacy and more specifically confidentiality... which is not a focus of DNSSEC.  DNSSEC is focused on ensuring the *integrity* of the information carried in DNS queries, although when coupled with DANE for TLS certificates it can help with confidentiality, too.

Am I misinterpreting the data?

No, you're not misinterpreting the data for .COM.  Only a very small % of .com domains are signed.  The story is better in other TLDs such as .GOV, for instance, where 87% of all domains are DNSSEC-signed ( http://fedv6-deployment.antd.nist.gov/snap-all.html ).  Attaining this high level, of course, took a mandate from the US government to all agencies.

Over in .NL, there are 1.7 million domains signed representing about 31% of all .NL domains (see right sidebar of https://www.sidn.nl/ ).  We are tracking a number of other statistics sites that monitor the DNSSEC status of various TLDs at:
http://www.internetsociety.org/deploy360/dnssec/statistics/

You are correct, though, that overall the % of domains signed with DNSSEC is low.

If not, then do we have consensus on what is blocking deployment?

I don't know that there is a "consensus"... and I could have a long conversation on this topic...  but I know from conversations with a good number of people within what I'll call the "DNSSEC community" over the past couple of years that we have the fundamental bootstrapping issue with DNSSEC where we need both more signing of domains and more deployment of DNSSEC-validating DNS resolvers.  The challenge has been that people say "why should I bother signing my domain when 'no one' is validating" and on the opposite side ISPs and other network operators say "why should I enable DNSSEC validation in my DNS resolvers where there aren't a lot of domains signed".  About 2 years ago a colleague and I wrote a paper for the SATIN conference in the UK and while the situation *has* improved, many of the points are still valid:

http://www.internetsociety.org/deploy360/resources/whitepaper-challenges-and-opportunities-in-deploying-dnssec/

The good news is that we've seen some good growth on the validation side, helped largely by Google turning on full DNSSEC validation in their Public DNS servers and Comcast enabling DNSSEC validation in their large network in North America.  Additionally, many ISPs in countries such as Sweden, the Netherlands, the Czech Republic and Brazil have turned on DNSSEC validation.   Geoff Huston, George Michaelson and the rest of the team at APNIC Labs have done a number of DNSSEC validation measurement projects and presented those at various conferences.   At RIPE67 last October, his set of slides ( https://ripe67.ripe.net/presentations/111-2013-10-15-dnssec.pdf ) was showing the May 2013 data where about 8.3% of all queries were being validated.  That's certainly a good start... and the validation % is much higher in some countries.

We also now have DNSSEC validation easily configurable in most all the major DNS resolvers, including BIND, Unbound and Microsoft Windows Server 2012.  It was also recently added to dnsmasq, a DNS server widely used in many smaller environments.  So the conditions are now right to get more DNSSEC validation occurring - this was one of the roadblocks for some time.   We also have the new getdns API ( http://www.vpnc.org/getdns-api/ ) that provides an easier way for application developers to get to DNS info and to get DNSSEC records.

There are still some operational issues to sort out regarding deploying DNSSEC validation that have been documented by Wes Hardaker, Olafur Gudmundsson and Suresh Krishnaswamy in a draft in the DNSOP working group:

http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance

On the signing side, we know many of the deployment challenges and people are working on them, although many of them are not anything that the IETF can do anything directly about. There are a few standardization issues that are being worked through within the DNSOP working group, such as how a parent zone is alerted when a key changes in a child zone.  There's a secure key transfer mechanism working through EPPEXT.

As an example of one area outside of the IETF, one challenge historically has been that many registrars have not provided any way to let you add DS or DNSKEY records to your domain info, which would then be passed up to your TLD.  That is now changing because ICANN's 2013 Registrar Accreditation Agreement (RAA) requires registrars to support the passing of DNSSEC records - and to sell the newgTLDs, registrars have to sign the 2013 RAA.  So we're seeing more registrars offering at least some base level of DNSSEC support.

Beyond that, it would certainly be helpful if there were more automation in the overall system to make it easier for people to just enable DNSSEC and have it "just work" - for example, it would be great to see more DNS hosting providers offer DNSSEC-signing.  It would also be helpful to have more content distribution networks (CDNs) supporting DNSSEC, as this is a barrier for getting many websites signed.

Perhaps a more fundamental factor "blocking" deployment is just that people don't understand the value of DNSSEC and haven't felt the urgent need to deploy it.  It's on "their list" of things to implement... but hasn't bubbled up enough in the priorities.  Many of us view DANE as a key driver here as it provides a real use case for how DNSSEC can help add a layer of trust to your web security infrastructure.

I could go on... and probably what I should do is write an update to that SATIN paper that provides a more current look at the remaining challenges... but hopefully this provides a view into some of the state of deployment.     I'm glad to expand on any points or be part of a larger discussion around these issues.  I'm employed by the Internet Society on the Deploy360 program where a large part of my work is focused on how we accelerate DNSSEC deployment... so I'm here to help on these points.

Regards,
Dan

P.S. And if anyone is interested in being involved specifically with efforts around advancing DNSSEC deployment (both inside the IETF but more so outside in the larger industry), we have a separate mailing list set up at  https://elists.isoc.org/mailman/listinfo/dnssec-coord  that is open to anyone to join.

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: Dan York <[email-masked]>
Date: Mon, 28 Apr 2014 21:50:17 +0000

Trevor,

On Apr 28, 2014, at 5:32 PM, Trevor Freeman <[email-masked]<mailto:[email-masked]>>
 wrote:

www.dhs.gov.edgekey.net<http://www.dhs.gov.edgekey.net> is a CNAME to e6485.dscb.akamaiedge.net<http://e6485.dscb.akamaiedge.net>

Yes, support of DNSSEC by content distribution networks (CDNs) remains one of the stumbling blocks to getting full DNSSEC support out there for web sites.  Some CDNs *do* support DNSSEC, but not for all customers, and other simply don't.  We definitely need to see more CDN customers *asking* their CDN providers for DNSSEC-signing.

Dan

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Apr 2014 15:07:37 -0700

On Apr 28, 2014, at 2:32 PM, Trevor Freeman <[email-masked]> wrote:

> www.dhs.gov is a cname entry www.dhs.gov.edgekey.net which is unsigned.

Dear Trevor,

Yes, there are many such CNAME wildcards in use.  A poor practice from many perspectives.  

Comcast has been helpful in vetting DNSSEC use. See http://dns.comcast.net.  http://tools.ietf.org/html/draft-start-tls-over-dns-00 solves many deployment and privacy issues.  DNSSEC should be considered a much needed work in progress.

Regards,
Douglas Otis

---

From: Warren Kumari <[email-masked]>
Date: Mon, 28 Apr 2014 18:10:08 -0400

> Granted DNNSEC does not by itself provide encryption but that is like saying X.509 does not do encryption, all it does is sign keys.  Generally there are two ways DNNSEC could be useful. One way, a…

OK, fully agree.

I just (re)read my email to you and realized I sounded like a jackass
-- that was not my intent[0].

W
[0]: When I am *intending* to sound like an ass, y'all will know :-P

---

From: Robin Wilton <[email-masked]>
Date: Tue, 29 Apr 2014 12:39:06 +0000

> Comcast has been helpful in vetting DNSSEC use. See http://dns.comcast.net.  http://tools.ietf.org/html/draft-start-tls-over-dns-00 solves many deployment and privacy issues.  DNSSEC should be cons…

PKI already suffers from the fact that its trust anchors do not align well (or, usually, at all) with the trust factors that underpin applications/services. Cloud architectures seem to me to exacerbate that state of affairs, because they often introduce a further level of abstraction in the certificate structure. I've seen this in two forms, each of which bears similarities to the akamai example Trevor cited above:

1 - you visit "nakedfurries.com" (sorry, Warren ;^)  ) but because their website is hosted, you see certificates for "cloudstorm.net" instead or as well, which doesn't contribute anything meaningful to the user's assessment of trust;

2 - the cloud service provider adds seemingly random qualifiers to the certificate label ( e.g. fjdo7pspddlfhe544gr6g.servicename.com). Again, this doesn't add to the user's trust assessment, and can look suspiciously as though the cert label is being used as the vehicle for a unique tracking ID.

Yrs.,
Robin

---

From: "Rose, Scott" <[email-masked]>
Date: Tue, 29 Apr 2014 12:59:08 +0000

On Apr 28, 2014, at 5:50 PM, Dan York <[email-masked]> wrote:

> Trevor,
> 
> On Apr 28, 2014, at 5:32 PM, Trevor Freeman <[email-masked]>
>  wrote:
> 

(off topic really)

CDN's are the issue here, but another thing seen in DNSSEC deployment in .gov is the problem seen in mandated deployments of other tech in .gov (like IPv6 :).  Admins only do the minimum of what will be checked.  Then on to the next fire.  So if the auditors only know your 2nd level domains, some zones skip signing their lower level delegations.  Or if it is a CNAME to a non-.gov, the target zone isn't signed since it isn't in .gov and won't count against you in the audit. 

Sadly doing what's best is secondary to doing what the audit covers.  

Scott

> [email-masked]   +1-802-735-1624
> Jabber: [email-masked] 

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 29 Apr 2014 22:54:31 +0000

Hi Dan,

Yes I want to consider the DNS authentication of encryption keys as one scenario which has a dependency on DNSSEC so we quickly get full circle.

There have been a number of people who have offered opinions in this area, and none so far have pointed to a technology issue as holding up deployment.  Far from it, there seems to be advances in many area. This all seems goodness.

It seems a little disturbing that it took a stick to get some level of DNSSEC deployment in the .gov domain. That model is hard to replicate elsewhere so I don't see it as a general solution to deployment. I much prefer carrots to drive dependents.  You are correct in that the Dutch government was one of the two governments I could find who's public web site was actually DNSSEC secured, despite many of the parent domain being signed. The only other was Estonia.

As you pointed out, there are a large number of content distribution networks hosting sites on behalf of organizations with signed domains, who have not signed their own domain thereby breaking the chain of trust to the web site dns record. We seem to be missing the carrot to get them to sign. What is the value proposition that would convince them to sign their domain?

I note that there is a session at the forthcoming ICANN DNSSEC workshop on DNSSEC and the enterprise. What about small and mediums sized organizations who have typical  lower security skill and smaller budgets? They are mostly migrating to cloud services of some form.  Aside from inviting speakers, has the been any research done with organizations on why they are not adopting DNSSEC?

It may also be fruitful to think about what are the next set of deployment goals in terms of what scenarios do we want to work. I would submit its time to move on from how many of the TLDS are signed onto tangible goals like what works. Do we want to look at a percentage of the email sent over the internet being DANE protected for example.

Trevor

From: Dan York [mailto:[email-masked]]
Sent: Monday, April 28, 2014 2:47 PM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: [perpass] Is DNSDEC a viable technology for perpass?

Trevor,

Regards,
Dan

---

From: manning bill <[email-masked]>
Date: Tue, 29 Apr 2014 16:02:50 -0700

Not going to speak for Dan, but the problems that were identified a decade ago still seem relevant since you bring them back up; e.g. the small/medium sized entity with
smaller resource pools to support enhanced crypto capabilities.   The answer then (and now) is -outsource-… but this path is fraught with peril if we truly want trusted systems.
Or we can just use the Baidu/Tata/Microsoft key escrow facilities…. and we are back to square one!

Solving this problem requires folks to own/manage their personal digital identity.

/bill

On 29April2014Tuesday, at 15:54, Trevor Freeman <[email-masked]> wrote:

> It seems a little disturbing that it took a stick to get some level of DNSSEC deployment in the .gov domain. That model is hard to replicate elsewhere so I don’t see it as a general solution to deployment. I much prefer carrots to drive dependents.  You are correct in that the Dutch government was one of the two governments I could find who’s public web site was actually DNSSEC secured, despite many of the parent domain being signed. The only other was Estonia.
>

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 29 Apr 2014 23:14:39 +0000

Are you referring to the assumption in the model that a domain in in control of its DNS keys and where we are dealing with small and medium sized org, that may be a stretch.

-----Original Message-----
From: manning bill [mailto:[email-masked]] 
Sent: Tuesday, April 29, 2014 4:03 PM
To: Trevor Freeman
Cc: Dan York; [email-masked]
Subject: Re: [perpass] Is DNSDEC a viable technology for perpass?

Not going to speak for Dan, but the problems that were identified a decade ago still seem relevant since you bring them back up; e.g. the small/medium sized entity with
smaller resource pools to support enhanced crypto capabilities.   The answer then (and now) is -outsource-... but this path is fraught with peril if we truly want trusted systems.
Or we can just use the Baidu/Tata/Microsoft key escrow facilities.... and we are back to square one!

/bill

---

From: manning bill <[email-masked]>
Date: Wed, 30 Apr 2014 11:27:06 -0700

yes.

/bill

---

From: Dan York <[email-masked]>
Date: Wed, 30 Apr 2014 19:08:40 +0000

Trevor,

Comments inline...

On Apr 29, 2014, at 6:54 PM, Trevor Freeman <[email-masked]<mailto:[email-masked]>>
 wrote:

Thanks for explaining where your focus is.

Yes, for the most part the issues holding up DNSSEC deployment are NOT technology-related.   That said, there *are* some remaining technology issues that do cause problems, most notably the key rollover issue being discussed in multiple drafts within DNSOP right now.  Additionally, while we have come far in automation, there are still ways we could make the DNSSEC signing process even easier for smaller and less tech-savvy users.

But overall the technology behind DNSSEC is very solid and is not the deployment challenge.

 It seems a little disturbing that it took a stick to get some level of DNSSEC deployment in the .gov domain. That model is hard to replicate elsewhere so I don’t see it as a general solution to deployment.

Neither do I.  And, as Scott Rose so rightly pointed out in a message earlier in this thread, a mandate often means that people will do exactly the bare minimum necessary to comply with the mandate... and nothing more.  As a result we wind up with implementations that do not, in fact, deliver the full level of security and are not "complete" in the way that we would think want them to be.

Customers asking them for it!  That is the big missing piece that people at multiple CDN providers have said to either me or others I know.  There *is* a certain level of complexity in what they do as a CDN that makes signing it all non-trivial.  However, some CDNs *are* offering DNSSEC-signing to certain customers.... and if more customers were asking for it, I'm sure more CDNs would offer it.  So we go back to needing to get the end customer aware of the value of DNSSEC - and then requesting it from their vendors.

I note that there is a session at the forthcoming ICANN DNSSEC workshop on DNSSEC and the enterprise. What about small and mediums sized organizations who have typical  lower security skill and smaller budgets? They are mostly migrating to cloud services of some form.

Speaking as one of the members of the program committee for that upcoming ICANN DNSSEC Workshop in London, we'd love to have someone offer to speak on that topic.  The call for participation can be found on multiple mailing lists or here:

http://www.internetsociety.org/deploy360/blog/2014/04/call-for-participation-icann-50-dnssec-workshop-on-25-june-in-london/

Aside from inviting speakers, has the been any research done with organizations on why they are not adopting DNSSEC?

Yes, a number of us have spoken with a good number of organizations about why.  In most cases for the folks I've spoken with it comes down to a lack of understanding of what DNSSEC can do... and even when they do understand, the reality that they have 37 other higher IT priorities that they need to get implemented right now because they are very often operating in perpetual crisis mode and whatever has the highest priority gets implemented.  Many people are finally getting around to IPv6 implementations because we are, in fact, finally running out of IPv4 addresses.  There isn't the same urgency *yet* for DNSSEC for many people.   This is why I and others have been talking up the value offered by DANE.

Yes... and we are definitely working on those deployment goals.  But this is where I think we really get out of the IETF territory of standards and get more into the operational side of things.  Rather than discuss this here on the perpass list, I'd encourage you to join the https://elists.isoc.org/mailman/listinfo/dnssec-coord list and engage in this discussion there.    (Unless others feel it should stay on this list... where I'm happy to discuss this, obviously... but I feel like we're going outside of areas that are in scope for the IETF.)

My 2 cents,
Dan

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 30 Apr 2014 12:12:39 -0700

> But overall the technology behind DNSSEC is very solid and is not the deployment challenge.

There is one key problem with DNSSEC to the user's system: 1%+ of the network rejects it, because the user is behind a device which blocks 3rd-party DNS requests and forces all requests through a non-DNSSEC-supporting recursive resolver.  

This means that any protocol which uses DNSSEC to distribute key material needs an alternate mechanism to transmit the DNSSEC information to the client.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Dan York <[email-masked]>
Date: Wed, 30 Apr 2014 20:01:46 +0000

On Apr 30, 2014, at 3:12 PM, Nicholas Weaver <[email-masked]<mailto:[email-masked]>> wrote:

On Apr 30, 2014, at 12:08 PM, Dan York <[email-masked]<mailto:[email-masked]>> wrote:

Yes, this is an issue.  Wes Hardaker, Olafur Gudmundsson and Suresh Krishnaswamy have done a good job of documenting this and other related issues in this I-D:

(And they are certainly open to comments and feedback on the draft.)

Dan