Edward Lewis | 27 Mar 22:31 2015
Picon

resimprove and Re: DNS Flush Protocol

On 3/27/15, 16:00, "Paul Vixie" <paul@...> wrote:

>Warren Kumari wrote:
>> ...
>>
>> I was saying is that we don't really need to reach *every* recursive,
>> whatever we do manage to do will be better than the current position.
>
>i disagree. a solution for the big resolvers will decimate incentive for
>any other solution for all resolvers. we need the weight of the big
>resolvers behind any standard we push in this area.

I agree with the former and disagree with the latter.

If the one continues to assume the commercial world adheres to RFCs and
refuses to entertain measurements of activity, irrelevance is the eventual
result.

Concentration of the recursive service market matters, if it is true.
(Mindful that all statistics are subject to bias and error.)

>> Sure, a fully awesome, all shining, all dancing cache flush solution
>> that can securely flush all caches everywhere would be best, but until
>> this comes along, something, anything really, is better than posting
>> on DNS-Operations.... W
>
>warren, have you read
><http://datatracker.ietf.org/doc/draft-vixie-dnsext-resimprove/> and do
>you have comments?

(Continue reading)

George Michaelson | 27 Mar 21:15 2015
Picon

Re: DNS Flush Protocol

OK. thats a good motivation. Nicely stated.

Models based on in-band proof(s) of possession might then in some
sense, be better. While I hate meta-protocol usage, since we don't
have a c&c channel that zone owners share with resolver owners, it
might be a tool in the locker.

How do you feel about state in the resolver to rendesvous on? Because
if we can do DNS 'query knocking' with held state, we can signal both
intentionality, and proof of possession. Obvious DoS risk of making a
resolver hold state but its probably no worse than the Amp Attack
risks.

Or if we have held-open session, then sequences of queries can be more
meaningful. I connect, I prove something doesn't exist with zero TTL,
I perform state change in the zone and re-query which shows you I
effected change for a prior query..

-G

On 27 March 2015 at 15:08, Paul Vixie <paul@...> wrote:
>
>
> George Michaelson wrote:
>> I would agree that assumptions are a road to perdition.
>>
>> But the model of concentration of eyeballs through resolvers is not
>> new. So, whilst I agree in *principle* I think it bears thinking
>> about: do you actually really expect a disruptive (sea)change  here?
>
(Continue reading)

George Michaelson | 27 Mar 20:40 2015
Picon

Re: DNS Flush Protocol

I would agree that assumptions are a road to perdition.

But the model of concentration of eyeballs through resolvers is not
new. So, whilst I agree in *principle* I think it bears thinking
about: do you actually really expect a disruptive (sea)change  here?

I mean, I think its more likely we get a sea-change in the signed root
outcomes, than less people use 8.8.8.8 and 4.4.4.4 personally. Or
Comcast, given their centrality in current (and forseeable future)
market share now they're getting the eyes behind TW. Or China's
concentration of views behind 3-4 carriers.

So yes. But then again.. Perhaps.. No.

On 27 March 2015 at 14:16, Paul Vixie <paul@...> wrote:
> see also:
>
> http://www.techrepublic.com/blog/data-center/opendns-and-neustars-real-time-directory-aim-to-speed-dns-update-times/
> _______________________________________________
> dns-operations mailing list
> dns-operations@...
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
George Michaelson | 27 Mar 17:30 2015
Picon

Re: DNS Flush Protocol

There has been some theorising about not having cache any more.
Anywhere.  Or, in enforcing rigidly low small cache values which
represent low thousands of queries against the authority, so they act
as a 1-in-n hit reducer but in human scale time (minutes, seconds
even) there is no visible cacheing.

I doubt anyone wants to go their either. But, as an overhead in
protocol and design, its actually very low. We just need people to
upgrade to code which empties the LRU very very very aggressively.

Mind you, I'd like a pony too (EC-DSA everywhere, 5011 intent
signalling in resolver on query so we know where it is, better than
SERVFAIL signalling in DNSSEC failure...)

The problem with cache busting was pretty clear in HTTP back when
Squid mattered. Its really not very clean to send queries THROUGH a
service, asking it to do meta-state on the query, rather than doing
in-system work. It has twisty corners.

-G
Mike Jones | 27 Mar 16:48 2015
Picon

DNS Flush Protocol

Every couple of months someone posts on a selection of industry
mailing lists that something has happened and can everyone please
flush their DNS caches for mywebsite.com. Often someone follows up the
discussion by suggesting some kind of automated system, which results
in a mention of opendns/googles flush pages, there is a little more
suggestion that a community flush system would be useful, then the
thread fizzles out.

I hereby propose an automated cache flush mechanism. I have no idea
what such a protocol should look like, however support for it probably
needs to be built in to standard DNS software. BIND needs a setting
that can tell it to register with "cacheflushservice.net" which will
result in the "cacheflushservice.net" server sending out a request to
flush google.com to all registered servers whenever I ask them to
flush google.com for me.

Comments? Ideas? Does someone want to make a slightly more formal
proposal for what such a protocol should look like?

- Mike Jones
David C Lawrence | 26 Mar 19:40 2015

Seeking edns-client-subnet implementers

At IETF this week it was decided to refocus the effort on the
edns-client-subnet draft on only documenting the existing behaviour of
deployed implementations.

To clarify some areas that were un/under-specified I am looking for
implementers of both recursive and authoritative servers at the
following "Participants" companies listed at
http://www.afasterinternet.com/participants.htm
namely:

  * EdgeCast
  * CDNetworks
  * BitGravity
  * Comodo
  * Incapsula
  * Tencent
  * DNSPod
  * Amazon / AWS

I've got contacts for others on the list already.

If you have an implementation but are not on that Participants page I
would like to hear from you too.

Thank you.

Florian Weimer | 20 Mar 07:33 2015
Picon

DNSSEC: Needs for zone transitions to Insecure

Are there still situations where a zone owner may have to transition
the zone to Insecure temporarily to keep it available (or make it
available again)?  What about transfers between registrars?

Are there zone signing mistakes which may need this step?
Julie Hedlund | 18 Mar 15:48 2015
Picon

REMINDER Re: Call for Participation -- ICANN DNSSEC Workshop at ICANN 53

REMINDER re: Call for Participation -- ICANN DNSSEC Workshop at ICANN 53 in Buenos Aires, Argentina

 

The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop at the ICANN 53 meeting on 24 June 2015 in Buenos Aires, Argentina.  The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments.  For reference, the most recent session was held at the ICANN meeting in Singapore on 11 February 2015. The presentations and transcripts are available at: http://singapore52.icann.org/en/schedule/wed-dnssec.  

At ICANN 53 we are particularly interested in live demonstrations of uses of DNSSEC or DANE.  Examples might include:

* Email clients and servers using DNSSEC/DANE for secure email.
* Tools for automating the generation of DNSSEC/DANE records.
* Services for monitoring or managing DNSSEC signing or validation.
* Tools or services for using DNSSEC/DANE along with other existing protocols and 
  services such as SSH, FTP or PGP/GPG.
* Innovative uses of APIs to do something new and different using DNSSEC/DANE.

Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE can be used to increase the overall security of the Internet.

We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE.  Examples of the types of topics we are seeking include:

 

1.  DNSSEC activities in Latin America 

 

For this panel we are seeking participation from those who have been involved in DNSSEC deployment in Latin America and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment.  In particular, we will consider the following questions:  What can DNSSEC do for you? What doesn't it do?  What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC?  We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers.

 

2.  Potential impacts of Root Key Rollover
 

Given many concerns about the need to do a Root Key Rollover, we would like to bring together a panel of people who can talk about what the potential impacts may be to ISPs, equipment providers and end users, and also what can be done to potentially mitigate those issues. In particular, we are seeking participation from vendors, ISPs, and the community that will be affected by distribution of new root keys.  We would like to be able to offer suggestions out of this panel to the wider technical community.  If you have a specific concern about the Root Key Rollover, or believe you have a method or solution to help address impacts, we would like to hear from you.

 

3.  New gTLD registries and administrators implementing DNSSEC

 

With the launch of the new gTLDs, we are interested in hearing from registries and operators of new gTLDs about what systems and processes they have implemented to support DNSSEC.  As more gTLDs are launched, is there DNSSEC-related information that can be shared to help those launches go easier?

 

4.  Guidance for Registrars in supporting DNSSEC 

 

The 2013 Registrar Accreditation Agreement (RAA) for registrars and resellers requires them to support DNSSEC from  January 1, 2014. We are seeking presentations discussing:

* What are the specific technical requirements of the RAA and how can registrars meet those requirements?

* What tools and systems are available for registrars that include DNSSEC support?

* What information do registrars need to provide to resellers and ultimately customers?

 

We are particularly interested in hearing from registrars who have signed the 2013 RAA and have either already implemented DNSSEC support or have a plan for doing so. 
 
5.  Implementing DNSSEC validation at Internet Service Providers (ISPs)


Internet Service Providers (ISPs) play a critical role by enabling DNSSEC validation for the caching DNS resolvers used by their customers.  We have now seen massive rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world.  We are interested in presentations on topics such as: 

* What does an ISP need to do to prepare its network for implementing DNSSEC validation?  

* How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation?  

* What measurements are available about the degree of DNSSEC validation currently deployed?  

* What tools are available to help an ISP deploy DNSSEC validation?

* What are the practical server-sizing impacts of enabling DNSSEC validation on ISP DNS Resolvers (ex. cost, memory, CPU, bandwidth, technical support, etc.)?

 

6. The operational realities of running DNSSEC

 

Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What is the best practice around key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? What operational statistics have we gathered about DNSSEC? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones?

 

7.  DNSSEC automation

 

For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. Topics for which we would like to see presentations include:

* What tools, systems and services are available to help automate DNSSEC key management?

* Can you provide an analysis of current tools/services and identify gaps?

* Where are the best opportunities for automation within DNSSEC signing and validation processes?

* What are the costs and benefits of different approaches to automation?

 

8.  When unexpected DNSSEC events occur

 

What have we learned from some of the operational outages that we have seen over the past 18 months? Are there lessons that we can pass on to those just about to implement DNSSEC? How do you manage dissemination of information about the outage? What have you learned about communications planning? Do you have a route to ISPs and registrars? How do you liaise with your CERT community?

 

9.  DANE and DNSSEC applications

 

There is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as:

* What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries?

* What tools and services are now available that can support DANE usage?

* How soon could DANE and other DNSSEC applications become a deployable reality?

* How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet?

 

We would be particularly interested in any live demonstrations of DNSSEC / DANE applications and services.  For example, a demonstration of the actual process of setting up a site with a certificate stored in a TLSA record that correctly validates would be welcome.  Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome.

 

10.  DNSSEC and DANE in the enterprise

 

Enterprises can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the domains owned by the enterprise. We are seeking presentations from enterprises that have implemented DNSSEC on validation and/or signing processes and can address questions such as:

* What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so?

* What are the challenges to deployment for these organizations and how could DANE and other DNSSEC applications address those challenges?

* How should an enterprise best prepare its IT staff and network to implement DNSSEC?

* What tools and systems are available to assist enterprises in the deployment of DNSSEC?

* How can the DANE protocol be used within an enterprise to bring a higher level of security to transactions using SSL/TLS certificates?

 

11. Hardware Security Modules (HSMs) use cases and innovation

 

We are interested in demonstrations of HSMs, presentations of HSM-related innovations and real world use cases of HSMs and key management. 
  

In addition, we welcome suggestions for additional topics.

 

If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-buenosaires-pYXoxzOOsG8@public.gmane.org by **Wednesday, 01 April 2015**
 

We hope that you can join us.

 

Thank you,

 

Julie Hedlund

 

On behalf of the DNSSEC Workshop Program Committee:
Mark Elkins, DNS/ZACR

Cath Goulding, Nominet UK

Jean Robert Hountomey, AfricaCERT

Jacques Latour, .CA

Xiaodong Lee, CNNIC

Luciano Minuchin, NIC.AR

Russ Mundy, Parsons

Ondřej Surý, CZ.NIC

Yoshiro Yoneya, JPRS

Dan York, Internet Society

Attachment (smime.p7s): application/pkcs7-signature, 6818 bytes
<div><span><div>
<div>
<div class="">
<div class=""><div class="">
<span class=""><div class=""><div class="">
<span class=""><div class=""><span class=""><div class=""><span class=""><div class=""><span class=""><div class=""><span class=""><div class="">
<div class=""><span lang="EN-GB" class="">REMINDER re: Call for Participation -- ICANN DNSSEC Workshop at ICANN 53 in Buenos Aires, Argentina<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class="">
<span lang="EN-GB" class="">The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security&nbsp;and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop at&nbsp;the ICANN 53 meeting on 24 June 2015 in Buenos Aires, Argentina.&nbsp;&nbsp;The DNSSEC&nbsp;Workshop has been a part of ICANN meetings for several years and has&nbsp;provided a forum for both experienced and new people to meet, present and&nbsp;discuss current and future DNSSEC deployments.&nbsp;&nbsp;For reference, the most&nbsp;recent&nbsp;session was held at the ICANN meeting in Singapore on 11 February 2015. The presentations and transcripts are available&nbsp;at:&nbsp;</span><a href="http://singapore52.icann.org/en/schedule/wed-dnssec" class="">http://singapore52.icann.org/en/schedule/wed-dnssec</a>.&nbsp;&nbsp;</div>
<div class=""><br class=""></div>
<div class="">At ICANN 53 we are particularly interested in live demonstrations of uses of DNSSEC or DANE. &nbsp;Examples might include:</div>
<div class=""><br class=""></div>
<div class="">* Email clients and servers using DNSSEC/DANE for secure email.</div>
<div class="">* Tools for automating the generation of DNSSEC/DANE records.</div>
<div class="">* Services for monitoring or managing DNSSEC signing or validation.</div>
<div class="">* Tools or services for using DNSSEC/DANE along with other existing protocols and&nbsp;</div>
<div class="">&nbsp; services such as SSH, FTP or PGP/GPG.</div>
<div class="">* Innovative uses of APIs to do something new and different using DNSSEC/DANE.</div>
<div class=""><br class=""></div>
<div class="">Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE can be used to increase the overall security of the Internet.</div>
<div class=""><br class=""></div>
<div class=""><span lang="EN-GB" class="">We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE. &nbsp;Examples of the types of topics we are seeking include:<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">1.&nbsp;&nbsp;DNSSEC activities in Latin America&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">For this panel we are seeking participation from those who have been&nbsp;involved in DNSSEC deployment in Latin America and also from those who have not deployed DNSSEC but who have a keen&nbsp;interest in the challenges and benefits of deployment. &nbsp;In particular, we will consider the following questions: &nbsp;What can DNSSEC do for you? What doesn't it do? &nbsp;What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? &nbsp;We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers.<p class=""></p></span></div>
<p class="MsoNormal"><span lang="EN-GB" class="">&nbsp;</span></p>
<div class="">2.&nbsp;&nbsp;Potential impacts of Root Key Rollover</div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Given many concerns about the need to do a Root Key Rollover, we would like to bring together a panel of people who can talk about what the potential impacts may be to ISPs, equipment providers and end users, and also what can be done to potentially mitigate those issues.&nbsp;In particular, we are seeking participation from vendors, ISPs, and&nbsp;the community that will be affected by distribution of new root keys. &nbsp;We would like to be able to offer suggestions out of this panel to the wider technical community. &nbsp;If you have a specific concern about the Root Key Rollover, or believe you have a method or solution to help address impacts, we would like to hear from you.<p class=""></p></span></div>
<p class="MsoNormal"><span lang="EN-GB" class="">&nbsp;</span></p>
<div class=""><span lang="EN-GB" class="">3. &nbsp;New gTLD registries and administrators implementing DNSSEC<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">With the launch of the new gTLDs, we are interested in hearing from registries and operators of new gTLDs about what systems and processes they have implemented to support DNSSEC. &nbsp;As more gTLDs are launched, is there DNSSEC-related information that can be shared to help those launches go easier?</span></div>
</div></span></div></span></div></span></div></span></div></span><div class="">
<p class="MsoNormal"><span lang="EN-GB" class="">&nbsp;</span></p>
<div class=""><span lang="EN-GB" class="">4. &nbsp;Guidance for Registrars in supporting DNSSEC&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">The 2013 Registrar Accreditation Agreement (RAA) for registrars and resellers requires them to support DNSSEC from&nbsp;&nbsp;January 1, 2014. We are seeking presentations discussing:<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What are the specific technical requirements of the RAA and how can registrars meet those requirements?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What tools and systems are available for registrars that include DNSSEC support?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What information do registrars need to provide to resellers&nbsp;and&nbsp;ultimately customers?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">We are particularly interested in hearing from registrars who have signed the 2013 RAA and have either already implemented DNSSEC support or have a plan for doing so.&nbsp;</span></div>
</div>
</div></div></span><div class=""><span class="">&nbsp;</span></div>
<span class=""><div class=""><div class="">
<div class="">
<div class=""><span lang="EN-GB" class="">5. &nbsp;Implementing DNSSEC validation at Internet Service Providers (ISPs)<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class=""><br class=""></span></div>
<p class="MsoNormal"><span lang="EN-GB" class=""></span></p>
<div class=""><span lang="EN-GB" class="">Internet Service Providers (ISPs) play a critical role by enabling DNSSEC validation for the caching DNS resolvers used by their customers. &nbsp;We have now seen massive rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world. &nbsp;We are interested in presentations on topics such as:&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What does an ISP need to do to prepare its network for implementing DNSSEC validation? &nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation? &nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What measurements are available about the degree of DNSSEC validation currently deployed? &nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What tools are available to help an ISP deploy DNSSEC validation?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What are the practical server-sizing impacts of enabling DNSSEC validation on ISP DNS Resolvers (ex. cost, memory, CPU, bandwidth, technical support, etc.)?</span></div>
</div>
<span class=""><div class=""><span class=""><div class=""><span class=""><div class=""><span class=""><div class=""><span class=""><div class="">
<div class=""><span lang="EN-GB" class=""><p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">6. The operational realities of running DNSSEC<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Now that DNSSEC has become an operational norm for many registries,&nbsp;registrars, and ISPs, what have we learned about how we manage DNSSEC?&nbsp;What is the best practice around key rollovers? How often do you review your&nbsp;disaster recovery procedures? Is there operational familiarity within your&nbsp;customer support teams? What operational statistics have we&nbsp;gathered about DNSSEC? Are there experiences being documented in the form&nbsp;of best practices, or something similar, for transfer of signed zones?<p class=""></p></span></div>
<p class="MsoNormal"><span lang="EN-GB" class="">&nbsp;</span></p>
<div class=""><span lang="EN-GB" class="">7. &nbsp;DNSSEC automation<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. Topics for which we would like to see presentations include:<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What tools, systems and services are available to help automate DNSSEC key management?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* Can you provide an analysis of current tools/services and identify gaps?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* Where are the best opportunities for automation within DNSSEC signing and validation processes?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What are the costs and benefits of different approaches to automation?<p class=""></p></span></div>
<p class="MsoNormal"><span lang="EN-GB" class="">&nbsp;</span></p>
<div class=""><span lang="EN-GB" class="">8. &nbsp;When unexpected DNSSEC events occur<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">What have we learned from some of the operational outages that we have&nbsp;seen over the past 18 months? Are there lessons that we can pass on to&nbsp;those just about to implement DNSSEC? How do you manage dissemination of&nbsp;information about the outage? What have you learned about communications&nbsp;planning? Do you have a route to ISPs and registrars? How do you liaise&nbsp;with your CERT community?<p class=""></p></span></div>
<p class="MsoNormal"><span lang="EN-GB" class="">&nbsp;</span></p>
<div class=""><span lang="EN-GB" class="">9. &nbsp;DANE and DNSSEC applications<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">There is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as:<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What tools and services are now available that can support DANE usage?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* How soon could DANE and other DNSSEC applications become a deployable reality?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet?<p class=""></p></span></div>
<p class="MsoNormal"><span lang="EN-GB" class="">&nbsp;</span></p>
<div class=""><span lang="EN-GB" class="">We would be particularly interested in any live demonstrations of DNSSEC / DANE applications and services. &nbsp;For example, a demonstration of the actual process of setting up a site with a certificate stored in a TLSA record that correctly validates would be welcome. &nbsp;Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome.</span></div>
</div></span></div></span></div></span></div></span></div></span><span class=""><div class=""><span class=""><div class=""><span class=""><div class=""><span class=""><div class=""><span class=""><div class="">
<div class=""><span lang="EN-GB" class=""><p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">10. &nbsp;DNSSEC and DANE in the enterprise<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Enterprises can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the domains owned by the enterprise. We are seeking presentations from enterprises that have implemented DNSSEC on validation and/or signing processes and can address questions such as:<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What are the challenges to deployment for these organizations and how could DANE and other DNSSEC applications address those challenges?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* How should an enterprise best prepare its IT staff and network to implement DNSSEC?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* What tools and systems are available to assist enterprises in the deployment of DNSSEC?<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">* How can the DANE protocol be used within an enterprise to bring a higher level of security to transactions using SSL/TLS certificates?</span></div>
<div class=""><span lang="EN-GB" class=""><p class="">&nbsp;</p></span></div>
<div class="">11. Hardware Security Modules (HSMs) use cases and innovation</div>
<div class=""><span lang="EN-GB" class=""><p class="">&nbsp;</p></span></div>
<div class="">
<span lang="EN-GB" class="">We are interested in demonstrations of HSMs, presentations of HSM-related innovations and real world use cases of HSMs and key management.</span>&nbsp;</div>
<div class=""><span lang="EN-GB" class="">&nbsp;&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">In addition, we welcome suggestions for additional topics.<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class="">
<span lang="EN-GB" class="">If you are interested in participating, please send a brief (1-2 sentence)&nbsp;description of your proposed presentation&nbsp;to&nbsp;<a href="mailto:dnssec-buenosaires <at> isoc.org" class="">dnssec-buenosaires@...</a></span>&nbsp;by&nbsp;**Wednesday, 01 April 2015**≤/div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">We hope that you can join us.<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Thank you,<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Julie Hedlund<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">&nbsp;<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">On behalf of the DNSSEC Workshop Program Committee:</span></div>
<div class=""><span lang="EN-GB" class="">Mark Elkins,&nbsp;DNS/ZACR<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Cath Goulding, Nominet UK<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Jean Robert Hountomey, AfricaCERT<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Jacques Latour, .CA<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Xiaodong Lee, CNNIC<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Luciano Minuchin, NIC.AR<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Russ Mundy, Parsons<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Ond&#345;ej Sur&yacute;, CZ.NIC<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Yoshiro Yoneya, JPRS<p class=""></p></span></div>
<div class=""><span lang="EN-GB" class="">Dan York, Internet Society</span></div>
<div><span lang="EN-GB" class=""><br></span></div>
</div></span></div></span></div></span></div></span></div></span>
</div></div></span>
</div></div>
<blockquote type="cite" class=""><div class=""><span class=""><div class=""><div class=""><span class=""><div class=""><span class=""><div class=""><span class=""><div class=""><span class=""><div class=""><span class=""><div class=""></div></span></div></span></div></span></div></span></div></span></div></div></span></div></blockquote>
</div>
<div apple-content-edited="true" class=""><div apple-content-edited="true" class=""></div></div>
</div>
<span><blockquote><div><div><span><blockquote><div><div><div><p></p></div></div></div></blockquote></span></div></div></blockquote></span>
</div></span></div>
Keith Mitchell | 13 Mar 22:37 2015
Picon

DNS-OARC Spring 2015 Workshop - Amsterdam, 9th-10th May

DNS-OARC is pleased to announce that public registration is now open for
its 2015 Spring Workshop on the 9th and 10th May, in Amsterdam,
The Netherlands.

This will be held at the same location (Hotel Okura) as the subsequent
RIPE70 meeting, and we're grateful to SIDN and Verisign for being our
Gold sponsors for this workshop.

You can find more information about the workshop at:

   https://indico.dns-oarc.net/event/21/

Registration is open at:

   https://indico.dns-oarc.net/event/21/registration/

OARC Workshop meetings are open to OARC members, presenters, and to all
other parties interested in DNS operations and research. RIPE attendees
are particularly welcome this time around.

Due to growing attendance at OARC workshops, and a more costly venue
than usual, we've taken the decision this time to experiment with
charging fees for non-members and late registrations to offset costs.

For Paying Members and Supporters (also accepted Speakers, and
Sponsors), attendance is free up to your representatives limit.

For non-members, or OARC Participants in the legacy non-paying
categories, there will be a registration fee of $150. In addition,
for both member and non-member attendees who register less than 2
weeks before the event, there will be a $100 late registration fee.

These registration fees will allow us to run a workshop without any
space limitations for the first time - we hope you will understand our
need to try this step to keep OARC workshops open and sustainable.

We have arranged for a small block of rooms at the venue hotel, the
Okura, from Fri 8th through Mon 11th May, and additional rooms at nearby
hotels. You can find details of how to book these here:

   https://indico.dns-oarc.net/event/21/page/0

Thank you to everyone who submitted abstracts, we have had another
strong slate of proposed talks and submissions are now closed, though we
expect to be able to accommodate a few lightning talks at the meeting.
The Programme Committee will be reviewing submissions shortly, and we
aim to publish a draft agenda by the end of this month.

Finally, we remain open to additional sponsors for this meeting - if
your organization is interested in sponsorship, please contact Denesh
Bhabuta via <sponsor@...> for more information.

Keith Mitchell
OARC President
bert hubert | 11 Mar 21:13 2015
Picon

introducing: dnsdist

Hi everybody,

From our blog post just now, where we instroduced 'dnsdist' a smart DNS load
balancing tool that is not PowerDNS specific.  The project is very fresh,
which is why we'd appreciate any input on useful features within our chosen
niche.

It has lots of Lua hooks to implement just about anything dynamic, and at
pretty good speeds too (but see the post for full details).

More on:

http://blog.powerdns.com/2015/03/11/introducing-dnsdist-dns-abuse-and-dos-aware-query-distribution-for-optimal-performance/

Summary:

Introducing dnsdist: DNS, abuse- and DoS-aware query distribution for
optimal performance

Over the years, PowerDNS users have frequently asked us about our preferred
DNS load balancing solution, and we’ve never had a satisfying answer for   
that. Users of dedicated hardware often tell us that vendors spend most of 
their time and effort on balancing HTTP, and frequently deliver substandard
or even buggy DNS functionality.

(...)
Putting these three things together (no really satisfying DNS aware load
balancer, drive for the very best performance, ongoing attacks) led us to
pollute the waters of the internet with yet another piece of software:   
dnsdist.

From its README:

“dnsdist is a highly DNS-, DoS- and abuse-aware loadbalancer. Its goal in
life is to route traffic to the best server, delivering top performance to
legitimate users while shunting or blocking abusive traffic.”

The full post is on:

http://blog.powerdns.com/2015/03/11/introducing-dnsdist-dns-abuse-and-dos-aware-query-distribution-for-optimal-performance/

Please let us know your thoughts!

        Bert
_______________________________________________
dns-operations mailing list
dns-operations <at> lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Edward Lewis | 10 Mar 19:51 2015
Picon

What would it take...

...to prevent another DS<-->DNSKEY mishap from happening again?

I'm presenting the message to the DNS Operations list of DNS-OARC.  (Being subscribed to so many DNS lists I keep forgetting if I'm acting as an IETF participant or talking as a past operator of DNS or as ....)

In short, think about when a name server loads a zone with a DNSKEY set in it.  If, at the parent zone, there is a DS set and none of it's contents refer to a record in the DNSKEY set, all DNSSEC validating queries will declare everything in the zone broken.

So, why can't the name server find the DS set, run a check and barf if there's a problem?  Barf - either refusing to load the zone or refusing to change the zone that is already running.

Here are some impediments:

1) The entity responsible for the set up is not likely to be a programmer.
2) Authoritative servers don't launch queries.
3) Authoritative servers don't know anything about the parent zone.
4) The owners of the zone and the operator of the DNS are not always the same entity (person, company).

#1 - The implications of this is - tools/components are needed.  One option are management/diagnostic tools.  Another option is an embedded in the name server component.  More tools is great when you are the jockey, more embedded components is great when you are the customer.

#2 - Software can do what it wants - but sometimes hidden masters are shielded with the public Internet.  (I'll assume the case is that the parent and child zones are on separate sets of machines - when this is't true, we don't have the problem.)  I bet though, that it wouldn't be hard to convince the operators of hidden masters to allow them access port 53 outside the firewall.

#3 - There's a brute force way to overcome this, come down the root to find the cut point.  Or this can be configured somehow (but I hate pinning).  Or maybe just doing a straight forward use of a validating recursive server (but that's more tools, see #1).

#4 - This is a critical aspect of the problem.  Even if the customer tells the DNS hosting company to roll keys, the customer has to be the one who finds the registrar to ensure the DS set is correct in the registry.  That's four participants with the most important (customer) the least capable (or they probably wouldn't be a customer).  Failing to automate away the customer's problem will kill the effort, certainly stall scaling.

The first step is for the operations community to cobble together a solution to this problem.  Perhaps a proposal goes to the IETF for the proper review and legal protection.  And if there's a need to change other policies, an IETF document might be the greatest asset.

This is one way to make DNSSEC less clumsy.

Please - if there are more impediments, suggest them.  I may have missed something.  If you disagree with an impediment, speak out.

Attachment (smime.p7s): application/pkcs7-signature, 6226 bytes
<div>
<div>...to prevent another DS&lt;--&gt;DNSKEY mishap from happening again?</div>
<div><br></div>
<div>I'm presenting the message to the DNS Operations list of DNS-OARC. &nbsp;(Being subscribed to so many DNS lists I keep forgetting if I'm acting as an IETF participant or talking as a past operator of DNS or as ....)</div>
<div><br></div>
<div>In short, think about when a name server loads a zone with a DNSKEY set in it. &nbsp;If, at the parent zone, there is a DS set and none of it's contents refer to a record in the DNSKEY set, all DNSSEC validating queries will declare everything in the zone broken.</div>
<div><br></div>
<div>So, why can't the name server find the DS set, run a check and barf if there's a problem? &nbsp;Barf - either refusing to load the zone or refusing to change the zone that is already running.</div>
<div><br></div>
<div>Here are some impediments:</div>
<div><br></div>
<div>1) The entity responsible for the set up is not likely to be a programmer.</div>
<div>2) Authoritative servers don't launch queries.</div>
<div>3) Authoritative servers don't know anything about the parent zone.</div>
<div>4) The owners of the zone and the operator of the DNS are not always the same entity (person, company).</div>
<div><br></div>
<div>#1 - The implications of this is - tools/components are needed. &nbsp;One option are management/diagnostic tools. &nbsp;Another option is an embedded in the name server component. &nbsp;More tools is great when you are the jockey, more embedded components is great when you are the customer.</div>
<div><br></div>
<div>#2 - Software can do what it wants - but sometimes hidden masters are shielded with the public Internet. &nbsp;(I'll assume the case is that the parent and child zones are on separate sets of machines - when this is't true, we don't have the problem.) &nbsp;I bet though, that it wouldn't be hard to convince the operators of hidden masters to allow them access port 53 outside the firewall.</div>
<div><br></div>
<div>#3 - There's a brute force way to overcome this, come down the root to find the cut point. &nbsp;Or this can be configured somehow (but I hate pinning). &nbsp;Or maybe just doing a straight forward use of a validating recursive server (but that's more tools, see #1).</div>
<div><br></div>
<div>#4 - This is a critical aspect of the problem. &nbsp;Even if the customer tells the DNS hosting company to roll keys, the customer has to be the one who finds the registrar to ensure the DS set is correct in the registry. &nbsp;That's four participants with the most important (customer) the least capable (or they probably wouldn't be a customer). &nbsp;Failing to automate away the customer's problem will kill the effort, certainly stall scaling.</div>
<div><br></div>
<div>The first step is for the operations community to cobble together a solution to this problem. &nbsp;Perhaps a proposal goes to the IETF for the proper review and legal protection. &nbsp;And if there's a need to change other policies, an IETF document might be the greatest asset.</div>
<div><br></div>
<div>This is one way to make DNSSEC less clumsy.</div>
<div><br></div>
<div>Please - if there are more impediments, suggest them. &nbsp;I may have missed something. &nbsp;If you disagree with an impediment, speak out.</div>
<div><br></div>
</div>

Gmane