Sebastian Castro | 29 Jul 00:44 2015
Picon

Call for Presentations - DNS-OARC Fall Workshop, Oct 2015 -- Deadline Extended

The next DNS-OARC Fall Workshop will take place in Montreal on Oct 3rd
and 4th, the weekend before NANOG65. DNS-OARC is requesting proposals
for presentations, with a preference for DNSSEC work. We are looking for
the whole spectrum, from measurement work using passive and active
techniques, to applications and potential new uses of DNSSEC.

This workshop intends to build from previous strong DNS-OARC workshops,
where operational content and research is welcome. Presentations from
DNS operators are particularly welcome, as well as from DNS researchers.
All DNS-related subjects are accepted, introduction to new tools,
visualizations, data analysis, DNSSEC and novel uses of the DNS.  If you
are an DNS-OARC member, and have a sensitive topic you would like to
present for members-only, we will accommodate those talks too. Time will
be available for lighting talks to fit short presentations (5 to 10
minutes).

Workshop Milestones
17 June 2015, Call for Presentations posted
17 June 2015, Open for submissions
14 August 2015, Deadline for submission (Deadline extended by two weeks)
20 August 2015, Final Program published
1 October 2015, Final deadline for slideset submission

Details for abstract submission will be published here:

        https://indico.dns-oarc.net/event/24/call-for-abstracts/

The workshop will be organized on different tracks, depending on the
topics and the timing of each presentation. If you are interested in a
lightning talk, let us know at the time of submission.
(Continue reading)

Julie Hedlund | 27 Jul 16:02 2015
Picon

Call for Participation -- ICANN DNSSEC Workshop at ICANN 54 in Dublin, Ireland

Call for Participation -- ICANN DNSSEC Workshop at ICANN 54 in Dublin, Ireland

 

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 54 meeting on 21 October in Dublin, Ireland.  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 Buenos Aires, Argentina on 24 June 2015. The presentations and transcripts are available at: https://buenosaires53.icann.org/en/schedule/wed-dnssec  

 

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

 

* Email clients and servers using DNSSEC, OPENPGPKEY, or S/MIME 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, XMPP, SMTP, S/MIME or PGP/GPG.

* Innovative uses of APIs to do something new and different using DNSSEC/DANE.

* S/MIME and Microsoft Outlook integration with active directory.

 

Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation 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 Europe 

 

For this panel we are seeking participation from those who have been involved in DNSSEC deployment in Europe 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:  Are you interested in reporting on DNSSEC validation of your ISPs? 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.  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: 

* Can you describe your experiences with negative Trust Anchors and operational realities?

* 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.)?

 

4. 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?

 

5.  DANE and DNSSEC application automation

 

For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also 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 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?

* 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 application automation 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.

 

6.  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?

  

7.  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?

 

8. 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-dublin-pYXoxzOOsG8@public.gmane.org by **Monday, 17 August 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, 6830 bytes
<div>
<div>
<div><p class="MsoNormal"><span lang="EN-GB">Call for Participation -- ICANN DNSSEC Workshop at ICANN 54 in Dublin, Ireland</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span>&nbsp;</span></p></div>
<div>
<div><p class="MsoNormal"><span lang="EN-GB">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 54 meeting on 21 October in Dublin, Ireland.&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 Buenos Aires, Argentina on 24 June 2015. The presentations and transcripts are available&nbsp;at:&nbsp;<a href="https://buenosaires53.icann.org/en/schedule/wed-dnssec">https://buenosaires53.icann.org/en/schedule/wed-dnssec</a>.&nbsp;</span><span>&nbsp;&nbsp;<p></p></span></p></div>
<div><p class="MsoNormal"><span>&nbsp;</span></p></div>
<div><p class="MsoNormal"><span>At ICANN 54 we are particularly interested in live demonstrations of uses of DNSSEC or DANE. &nbsp;Examples might include:<p></p></span></p></div>
<div><p class="MsoNormal"><span>&nbsp;</span></p></div>
<div><p class="MsoNormal"><span><span>* Email clients and servers using DNSSEC,&nbsp;</span><span></span><span>OPENPGPKEY, or S/MIME</span><span>&nbsp;</span><span></span><span>for secure email.<p></p></span></span></p></div>
<div><p class="MsoNormal"><span>* Tools for automating the generation of DNSSEC/DANE records.<p></p></span></p></div>
<div><p class="MsoNormal"><span>* Services for monitoring or managing DNSSEC signing or validation.<p></p></span></p></div>
<div><p class="MsoNormal"><span>* Tools or services for using DNSSEC/DANE along with other existing protocols and&nbsp;<p></p></span></p></div>
<div><p class="MsoNormal"><span><span>&nbsp; services such as SSH,&nbsp;</span><span>XMPP, SMTP, S/MIME</span><span>&nbsp;or PGP/GPG.<p></p></span></span></p></div>
<div><p class="MsoNormal"><span>* Innovative uses of APIs to do something new and different using DNSSEC/DANE.<p></p></span></p></div>
</div>
</div>
<div><p class="MsoNormal"><span>* S/MIME and Microsoft Outlook integration with active directory.</span><span><p></p></span></p></div>
<div>
<div>
<div><p class="MsoNormal"><span>&nbsp;</span></p></div>
<div><p class="MsoNormal"><span>Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE&nbsp;</span><span>related innovation&nbsp;</span><span></span><span>can be used to increase the overall security of the Internet.<p></p></span></p></div>
<div><p class="MsoNormal"><span>&nbsp;</span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">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:</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">1.&nbsp;&nbsp;DNSSEC activities in Europe&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span><span lang="EN-GB">For this panel we are seeking participation from those who have been&nbsp;involved in DNSSEC deployment in Europe 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;Are you interested in r</span><span lang="EN-GB">eporting on DNSSEC&nbsp;</span><span lang="EN-GB">validation</span><span lang="EN-GB">&nbsp;of&nbsp;</span><span lang="EN-GB">your&nbsp;</span><span lang="EN-GB">ISPs?&nbsp;</span><span lang="EN-GB"></span><span lang="EN-GB">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.</span></span><span><p></p></span></p></div>
<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><p></p></p>
<div><p class="MsoNormal"><span>2.&nbsp;&nbsp;Potential impacts of Root Key Rollover<p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">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.</span></p></div>
</div>
<div><p class="MsoNormal"><span>&nbsp;</span><span><p></p></span></p></div>
<div>
<div>
<div><p class="MsoNormal"><span lang="EN-GB">3. &nbsp;Implementing DNSSEC validation at Internet Service Providers (ISPs)</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span>&nbsp;</span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">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;</span><span><p></p></span></p></div>
<div>
<p class="MsoNormal"><span lang="EN-GB">* Can you describe your experiences with negative Trust Anchors and operational realities?</span><span lang="EN-GB"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-GB">* What does an ISP need to do to prepare its network for implementing DNSSEC validation? &nbsp;</span><span><p></p></span></p>
</div>
<div><p class="MsoNormal"><span lang="EN-GB">* How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation? &nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* What measurements are available about the degree of DNSSEC validation currently deployed? &nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* What tools are available to help an ISP deploy DNSSEC validation?</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* What are the practical server-sizing impacts of enabling DNSSEC validation on ISP DNS Resolvers (ex. cost, memory, CPU, bandwidth, technical support, etc.)?</span><span><p></p></span></p></div>
</div>
<div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">4. The operational realities of running DNSSEC</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">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?</span><span><p></p></span></p></div>
<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><p></p></p>
<div><p class="MsoNormal"><span lang="EN-GB">5. &nbsp;DANE and DNSSEC application automation</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available.&nbsp;</span><span>There also is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations&nbsp;&nbsp;on topics such as:</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* What tools, systems and services are available to help automate DNSSEC key management?</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* Can you provide an analysis of current tools/services and identify gaps?</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* Where are the best opportunities for automation within DNSSEC signing and validation processes?</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* What are the costs and benefits of different approaches to automation?</span><span><p></p></span></p></div>
</div>
</div>
</div>
<div>
<div><p class="MsoNormal"><span lang="EN-GB">* What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries?</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* What tools and services are now available that can support DANE usage?</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* How soon could DANE and other DNSSEC applications become a deployable reality?</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet?</span><span><p></p></span></p></div>
<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><p></p></p>
<div><p class="MsoNormal"><span lang="EN-GB">We would be particularly interested in any live demonstrations of DNSSEC / DANE application automation 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><span><p></p></span></p></div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><p></p></p>
<div><p class="MsoNormal"><span lang="EN-GB">6. &nbsp;When unexpected DNSSEC events occur</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">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?</span></p></div>
<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span>&nbsp;</span><p></p></p>
</div>
<div>
<div><p class="MsoNormal"><span lang="EN-GB">7. &nbsp;DNSSEC and DANE in the enterprise</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">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:</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so?</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* What are the challenges to deployment for these organizations and how could DANE and other DNSSEC applications address those challenges?</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* How should an enterprise best prepare its IT staff and network to implement DNSSEC?</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* What tools and systems are available to assist enterprises in the deployment of DNSSEC?</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">* How can the DANE protocol be used within an enterprise to bring a higher level of security to transactions using SSL/TLS certificates?</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span>8. Hardware Security Modules (HSMs) use cases and innovation<p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">We are interested in demonstrations of HSMs, presentations of HSM-related innovations and real world use cases of HSMs and key management.</span><span>&nbsp;<p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">In addition, we welcome suggestions for additional topics.</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">If you are interested in participating, please send a brief (1-2 sentence)&nbsp;description of your proposed presentation&nbsp;to</span><span lang="EN-GB">&nbsp;</span><a href="mailto:dnssec-dublin <at> isoc.org" class="">dnssec-dublin@...</a>&nbsp;<span>by&nbsp;**Monday, 17 August 2015**≤p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">We hope that you can join us.</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">Thank you,</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">Julie Hedlund</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">&nbsp;</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">On behalf of the DNSSEC Workshop Program Committee:</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">Mark Elkins,&nbsp;DNS/ZACR</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">Cath Goulding, Nominet UK</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">Jean Robert Hountomey, AfricaCERT</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">Jacques Latour, .CA</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">Xiaodong Lee, CNNIC</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">Luciano Minuchin, NIC.AR</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">Russ Mundy, Parsons</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">Ond&#345;ej Sur&yacute;, CZ.NIC</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">Yoshiro Yoneya, JPRS</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span lang="EN-GB">Dan York, Internet Society</span><span><p></p></span></p></div>
<div><p class="MsoNormal"><span>&nbsp;</span></p></div>
</div>
</div>
</div>
wbrown | 23 Jul 20:47 2015

With appologies to Douglas Adams.

DNS is definitive.  Reality is frequently inaccurate.






Confidentiality Notice:
This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system.
<div>DNS is definitive. &nbsp;Reality is frequently
inaccurate.
<br><br><br><br><br><br>
<br>
Confidentiality Notice: <br>
This electronic message and any attachments may contain confidential or
privileged information, and is intended only for the individual or entity
identified above as the addressee. If you are not the addressee (or the
employee or agent responsible to deliver it to the addressee), or if this
message has been addressed to you in error, you are hereby notified that
you may not copy, forward, disclose or use any part of this message or
any attachments. Please notify the sender immediately by return e-mail
or telephone and delete this message from your system.<br>
</div>
Rubens Kuhl | 15 Jul 17:45 2015
Picon

5s TTL on IANA /8s


% dig  <at> a.in-addr-servers.arpa. 12.in-addr.arpa. ns
...
12.in-addr.arpa.    5    IN    NS    cmtu.mt.ns.els-gms.att.net.
12.in-addr.arpa.    5    IN    NS    dbru.br.ns.els-gms.att.net.
12.in-addr.arpa.    5    IN    NS    cbru.br.ns.els-gms.att.net.
12.in-addr.arpa.    5    IN    NS    dmtu.mt.ns.els-gms.att.net.

% dig  <at> b.in-addr-servers.arpa. 1.in-addr.arpa. ns
1.in-addr.arpa.        5    IN    NS    ns1.apnic.net.
1.in-addr.arpa.        5    IN    NS    ns2.lacnic.net.
1.in-addr.arpa.        5    IN    NS    ns3.apnic.net.
1.in-addr.arpa.        5    IN    NS    ns4.apnic.net.
1.in-addr.arpa.        5    IN    NS    sec1.authdns.ripe.net.
1.in-addr.arpa.        5    IN    NS    apnic1.dnsnode.net.
1.in-addr.arpa.        5    IN    NS    tinnie.arin.net.

	• 200.in-addr.arpa.       5       IN      NS      sec1.authdns.ripe.net.
	• 200.in-addr.arpa.       5       IN      NS      ns-lacnic.nic.mx.
	• 200.in-addr.arpa.       5       IN      NS      ns3.afrinic.net.
	• 200.in-addr.arpa.       5       IN      NS      a.arpa.dns.br.
	• 200.in-addr.arpa.       5       IN      NS      ns.lacnic.net.
	• 200.in-addr.arpa.       5       IN      NS      sec3.apnic.net.
	• 200.in-addr.arpa.       5       IN      NS      ns2.lacnic.net.
	• 200.in-addr.arpa.       5       IN      NS      tinnie.arin.net.
	• ;; Received 256 bytes from 2001:67c:e0::1#53(2001:67c:e0::1) in 225 ms
	•  

I tried to think on operational reasons to keep TTLs so low for these resources but couldn't think of
anything... any ideas ? 

Rubens

_______________________________________________
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
彭勇华 | 15 Jul 04:20 2015
Picon

multi CNAMEs for a given host

I am just interested, this provider says they can have multi CNAME 
records for a given host.
https://www.cloudxns.net/Index/Extend.html
Multi CNAMEs are answered to client by RR based on weight.
How do you think of that? Thanks.
Frank Bulk | 14 Jul 07:08 2015
Picon

Verifying that a recursor is performing DNSSec validation

Is there an existing tool, ideally a NAGIOS-friendly one, that performs a
check against a resolver that it gets an AD back on DNSSec query for a zone
that is properly signed, failure for one that is not properly signed, and
nothing for one that isn't signed?
http://docs.menandmice.com/display/MM/How+to+test+DNSSEC+validation

I'd rather not re-invent the wheel if it already exists.

Regards,

Frank Bulk

William Sotomayor | 8 Jul 20:07 2015
Picon

The root zone at past 1000.


Well we've had December 2012 come and go, and now we're at 1003 entries
in the root zone.  I think we're all still here and the Internet seems
functional for various definitions of 'functional'.

wfms
dns | 1 Jul 02:00 2015
Picon

dns-operations dontprobe reminder 20150701-0000

Dear All,

This is a reminder, sent out once every 3 months that the DNS-OARC
runs the 'Don't Probe List' on behalf of the community.  This is a
database listing IP addresses and hostnames of DNS servers that 
should be excluded from Internet-wide DNS scans conducted by 
researchers.

Researchers are invited to request secure access to the latest version
of the database, while DNS operators are invited to submit any systems
they wish to have excluded from such scanning.

For more information on the 'Don't Probe List', please follow the link
provided below:

	https://www.dns-oarc.net/oarc/services/dontprobe

Best regards,

DNS-OARC Admin

Randy Bush | 28 Jun 08:45 2015

Re: .MW inconsistent zone updates?

the occasional packet can get through

rip.psg.com:/root# ping 196.45.188.5
PING 196.45.188.5 (196.45.188.5): 56 data bytes
64 bytes from 196.45.188.5: icmp_seq=2 ttl=44 time=360.147 ms
64 bytes from 196.45.188.5: icmp_seq=55 ttl=44 time=377.265 ms
64 bytes from 196.45.188.5: icmp_seq=78 ttl=43 time=368.701 ms
64 bytes from 196.45.188.5: icmp_seq=82 ttl=43 time=369.133 ms
64 bytes from 196.45.188.5: icmp_seq=85 ttl=43 time=360.161 ms
64 bytes from 196.45.188.5: icmp_seq=91 ttl=44 time=359.521 ms
64 bytes from 196.45.188.5: icmp_seq=97 ttl=43 time=360.262 ms
64 bytes from 196.45.188.5: icmp_seq=99 ttl=44 time=360.025 ms
64 bytes from 196.45.188.5: icmp_seq=105 ttl=43 time=360.261 ms
64 bytes from 196.45.188.5: icmp_seq=108 ttl=44 time=358.269 ms
64 bytes from 196.45.188.5: icmp_seq=158 ttl=44 time=360.564 ms
^C
--- 196.45.188.5 ping statistics ---
164 packets transmitted, 11 packets received, 93.3% packet loss
round-trip min/avg/max/stddev = 358.269/363.119/377.265/5.672 ms

rip.psg.com:/root# traceroute 196.45.188.5
traceroute to 196.45.188.5 (196.45.188.5), 64 hops max, 52 byte packets
 1  psg0 (147.28.0.4)  0.297 ms  0.228 ms  0.120 ms
 2  ge-100-0-0-15.r05.sttlwa01.us.bb.gin.ntt.net (165.254.106.17)  0.732 ms  0.838 ms  0.614 ms
 3  be3048.ccr21.sea02.atlas.cogentco.com (154.54.11.9)  23.479 ms  22.984 ms  23.227 ms
 4  be2085.ccr21.slc01.atlas.cogentco.com (154.54.2.198)  31.595 ms  31.877 ms  31.835 ms
 5  be2126.ccr21.den01.atlas.cogentco.com (154.54.25.65)  42.463 ms
    be2127.ccr22.den01.atlas.cogentco.com (154.54.25.69)  45.835 ms
    be2126.ccr21.den01.atlas.cogentco.com (154.54.25.65)  42.331 ms
 6  be2128.ccr21.mci01.atlas.cogentco.com (154.54.25.174)  54.302 ms
    be2130.ccr22.mci01.atlas.cogentco.com (154.54.26.122)  53.716 ms
    be2128.ccr21.mci01.atlas.cogentco.com (154.54.25.174)  54.322 ms
 7  be2156.ccr41.ord01.atlas.cogentco.com (154.54.6.86)  65.782 ms
    be2157.ccr42.ord01.atlas.cogentco.com (154.54.6.118)  66.233 ms
    be2156.ccr41.ord01.atlas.cogentco.com (154.54.6.86)  65.815 ms
 8  be2351.ccr21.cle04.atlas.cogentco.com (154.54.44.86)  76.760 ms
    be2185.ccr22.cle04.atlas.cogentco.com (154.54.43.178)  73.506 ms  74.382 ms
 9  be2482.ccr41.jfk02.atlas.cogentco.com (154.54.27.158)  89.064 ms
    be2483.ccr42.jfk02.atlas.cogentco.com (154.54.29.202)  88.665 ms
    be2482.ccr41.jfk02.atlas.cogentco.com (154.54.27.158)  89.158 ms
10  be2317.ccr41.lon13.atlas.cogentco.com (154.54.30.186)  160.581 ms
    be2490.ccr42.lon13.atlas.cogentco.com (154.54.42.86)  162.390 ms
    be2317.ccr41.lon13.atlas.cogentco.com (154.54.30.186)  161.606 ms
11  be2494.ccr22.lon01.atlas.cogentco.com (154.54.39.129)  165.021 ms
    be2178.ccr21.lon01.atlas.cogentco.com (130.117.50.205)  178.197 ms  176.103 ms
12  be2644.rcr12.b023101-0.lon01.atlas.cogentco.com (154.54.38.34)  162.512 ms
    be2422.rcr12.b023101-0.lon01.atlas.cogentco.com (154.54.37.54)  165.632 ms  165.704 ms
13  149.6.99.3 (149.6.99.3)  161.139 ms
    149.6.99.2 (149.6.99.2)  165.569 ms  164.094 ms
14  81.199.204.85.satcom-systems.net (81.199.204.85)  165.263 ms  164.139 ms  163.508 ms
15  81.199.204.86.satcom-systems.net (81.199.204.86)  381.022 ms  379.915 ms  379.769 ms
16  * * *
17  kalata.sdnp.org.mw (41.77.11.210)  382.879 ms * *
18  * * *
19  chambo.sdnp.org.mw (196.45.188.5)  369.388 ms *  367.459 ms
Randy Bush | 28 Jun 08:38 2015

Re: .MW inconsistent zone updates?

rip.psg.com:/root# ping 196.45.188.5
PING 196.45.188.5 (196.45.188.5): 56 data bytes
^C
--- 196.45.188.5 ping statistics ---
9 packets transmitted, 0 packets received, 100.0% packet loss
rip.psg.com:/root# ping 41.221.99.135
PING 41.221.99.135 (41.221.99.135): 56 data bytes
^C
--- 41.221.99.135 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

and, of course

rip.psg.com:/root# dig  <at> 196.45.188.5
^Crip.psg.com:/root# dig  <at> 196.45.188.5 mw. axfr

; <<>> DiG 9.10.2 <<>>  <at> 196.45.188.5 mw. axfr
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

and a border router thinks

r0.sea#sh ip bg 196.45.188.5
BGP routing table entry for 196.45.188.0/24, version 44268490
BGP Bestpath: deterministic-med
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1          3         
  Refresh Epoch 1
  2914 174 12491 37098
    165.254.106.17 from 165.254.106.17 (129.250.0.167)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 2914:420 2914:1007 2914:2000 2914:3000 3130:380
      path 10CCC390 RPKI State not found
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  1239 174 12491 37098
    144.232.9.61 (metric 11) from 147.28.7.2 (147.28.7.2)
      Origin IGP, localpref 100, valid, internal
      path 126AB9A4 RPKI State not found
      rx pathid: 0, tx pathid: 0

---

fom the other side of the states

nfs0.dfw.rg.net:/root# ping 196.45.188.5
PING 196.45.188.5 (196.45.188.5) 56(84) bytes of data.
64 bytes from 196.45.188.5: icmp_seq=2 ttl=41 time=337 ms
64 bytes from 196.45.188.5: icmp_seq=8 ttl=41 time=336 ms
64 bytes from 196.45.188.5: icmp_seq=16 ttl=41 time=336 ms
^C
--- 196.45.188.5 ping statistics ---
18 packets transmitted, 3 received, 83% packet loss, time 17111ms
rtt min/avg/max/mdev = 336.549/336.915/337.556/0.809 ms
nfs0.dfw.rg.net:/root# 41.221.99.135
41.221.99.135: command not found
nfs0.dfw.rg.net:/root# ping 41.221.99.135
PING 41.221.99.135 (41.221.99.135) 56(84) bytes of data.
^C
--- 41.221.99.135 ping statistics ---
30 packets transmitted, 0 received, 100% packet loss, time 29232ms

---

from tokyo

PING 196.45.188.5 (196.45.188.5) 56(84) bytes of data.
64 bytes from 196.45.188.5: icmp_seq=6 ttl=43 time=410 ms
64 bytes from 196.45.188.5: icmp_seq=7 ttl=43 time=410 ms
64 bytes from 196.45.188.5: icmp_seq=10 ttl=43 time=410 ms
^C
--- 196.45.188.5 ping statistics ---
14 packets transmitted, 3 received, 78% packet loss, time 12999ms
rtt min/avg/max/mdev = 410.219/410.391/410.594/0.755 ms

---

iceland is actually ok

[root <at> bikeshed ~]# ping 196.45.188.5
PING 196.45.188.5 (196.45.188.5): 56 data bytes
64 bytes from 196.45.188.5: icmp_seq=0 ttl=47 time=233.191 ms
64 bytes from 196.45.188.5: icmp_seq=1 ttl=47 time=232.945 ms
64 bytes from 196.45.188.5: icmp_seq=2 ttl=47 time=232.979 ms
64 bytes from 196.45.188.5: icmp_seq=3 ttl=47 time=234.207 ms
64 bytes from 196.45.188.5: icmp_seq=4 ttl=47 time=233.077 ms
^C
--- 196.45.188.5 ping statistics ---
6 packets transmitted, 5 packets received, 16.7% packet loss
round-trip min/avg/max/stddev = 232.945/233.280/234.207/0.471 ms
Gunter Grodotzki | 25 Jun 10:23 2015
Picon

.MW inconsistent zone updates?

Hello,

I did a domain update last week on cheki.mw, but it seems like some OPs 
are either sleeping or their syncing is not really working ;)

The following auth-ns is still delivering a old record:
mw.            21599    IN    NS    rip.psg.com.

$ dig +nocomments ns cheki.mw  <at> rip.psg.com

; <<>> DiG 9.9.5-9-Debian <<>> +nocomments ns cheki.mw  <at> rip.psg.com
;; global options: +cmd
;cheki.mw.            IN    NS
cheki.mw.        86400    IN    NS ns-1722.awsdns-23.co.uk.
cheki.mw.        86400    IN    NS ns-1022.awsdns-63.net.
cheki.mw.        86400    IN    NS ns-1137.awsdns-14.org.
cheki.mw.        86400    IN    NS    ns-279.awsdns-34.com.
;; Query time: 356 msec
;; SERVER: 147.28.0.39#53(147.28.0.39)
;; WHEN: Thu Jun 25 10:21:58 SAST 2015
;; MSG SIZE  rcvd: 178

Others, like the following, show the correct entry:
mw.            21599    IN    NS    chambo.sdnp.org.mw.
$ dig +nocomments ns cheki.mw  <at> chambo.sdnp.org.mw

; <<>> DiG 9.9.5-9-Debian <<>> +nocomments ns cheki.mw  <at> chambo.sdnp.org.mw
;; global options: +cmd
;cheki.mw.            IN    NS
cheki.mw.        86400    IN    NS athena.ns.cloudflare.com.
cheki.mw.        86400    IN    NS arch.ns.cloudflare.com.
;; Query time: 231 msec
;; SERVER: 196.45.188.5#53(196.45.188.5)
;; WHEN: Thu Jun 25 10:22:29 SAST 2015
;; MSG SIZE  rcvd: 94

Regards,
Gunter Grodotzki

Gmane