Category: DNS

Feb 26

Watch Live Today! DNS Privacy Workshop Streaming from NDSS 2017

lifeguard-beach

Want to learn the latest about DNS privacy? About the latest research and techniques to protect the confidentiality of your DNS info and queries?

Starting at 8:55 am PST (UTC-8) today, there will be what looks to be an outstanding workshop on DNS Privacy streaming live out of the Network and Distributed System Security Symposium (NDSS) in San Diego, California.

View the agenda of the DNS Privacy Workshop to see all the excellent sessions.  You can then join live at:

https://isoc.zoom.us/j/935912695

(Other remote connection options can be found at the bottom of the agenda page.)

Note – this workshop is not about DNSSEC, which is a method to protect the integrity of DNS (to ensure DNS info is not modified in transit), but rather new work being done within the IETF to improve the confidentiality of DNS.

The sessions include:

  • How DNS Works in Tor & Its Anonymity Implications
  • DNS Privacy through Mixnets and Micropayments
  • Towards Secure Name Resolution on the Internet – GNS
  • Changing DNS Usage Profiles for Increased Privacy Protection
  • DNS-DNS: DNS-based De-NAT Scheme
  • Can NSEC5 be practical for DNSSEC deployments?
  • Privacy analysis of the DNS-based protocol for obtaining inclusion proof
  • Panel Discussion: The Tension between DNS Privacy and DNS Service Management
  • The Usability Challenge for DNS Privacy and End Users
  • An Empirical Comparison of DNS Padding Schemes
  • DNS Service Discovery Privacy
  • Trustworthy DNS Privacy Services
  • EIL: Dealing with the Privacy Problem of ECS
  • Panel Discussion: DNS-over-TLS Service Provision Challenges: Testing, Verification, internet.nl

If you are not there in person (as I will not be), you can also follow along on the #NDSS17 hashtag on Twitter. There will also be tweets coming out of:

Stéphane Bortzmeyer will also be attending (and speaking at) the workshop – and he is usually a prolific tweeter at @bortzmeyer.

The sessions will also be recorded for later viewing. I’m looking forward to seeing the activity coming out of this event spur further activity on making DNS even more secure and private.

Please do follow along remotely – and please do share this information with other people you think might be interested. Thank you!

Image from Unsplash – I thought about showing the wide beaches, but the reality is that the conference participants won’t really get a chance to visit them. I thought “Lifeguard” was appropriate, though, because lifeguards are all about protecting people and keeping things safe.

Mar 31

DNS-OARC 24 Streaming Live March 31 / April 1 from Buenos Aires

OARC 24

Today and tomorrow you have a great opportunity to listen to some of the newest research into the Domain Name System (DNS) operations and security through the live video stream of the 24th meeting of the DNS Operations Analysis and Research Center (DNS-OARC). You can watch live at:

https://www.youtube.com/c/DnsoarcNetPlus/live

and view the past recordings on the DNS-OARC YouTube channel.  The DNS-OARC 24 agenda covers a wide range of topics related to the overall operations of DNS.  Some of the sessions that Deploy360 readers may find of interest include:

  • Thursday, March 31
    • How we are developing a next generation DNS API for applications
    • State of the “DNS privacy” project: running code
    • QNAME minimisation in Unbound (DNS privacy)
  • Friday, April 1
    • Knot DNS Resolver
    • Threshold-Cryptography Distributed HSM
    • Review and analysis of attack traffic against A-root and J-root on November 30 and December 1, 2015
    • ECDSA – Reviewed
    • Rolling the Root Key
    • Algorithm roll-over experiences
    • Panel: DNSSEC algorithm flexibility

The last four sessions that I highlighted in bold all fit into the larger work of moving to use newer elliptic curve cryptographic algorithms within DNSSEC that I wrote about recently.  As I mentioned in that article, I’ll be moderating this final panel tomorrow afternoon.

I would encourage people to tune in and watch the sessions.  Do visit the DNS-OARC 24 timetable to find out the times when different sessions will be happening. All times are in Argentina time (ART) which is UTC-3.

And if you want to get started with DNSSEC yourself, please visit our Start here page to begin.

Image credit: a photo of the DNS-OARC 24 room I took this morning.

 

Mar 18

Registration Operations Workshop This Sunday Before IETF92 To Talk About EPP, Encryption, DNS

Registration Operations WorkshopHow can operators of registries such as top-level domains (TLDs) make their operations more efficient and more secure?  What can operators learn from each other?  And what are some of the larger initiatives happening that may affect registry operators?

These are all the kinds of questions that will be discussed this coming Sundary, March 22, 2015, at the 2nd Registration Operations Workshop (ROW) happening at the Fairmont Dallas Hotel on the Sunday before IETF 92 starts.  The ROW workshop is not affiliated with the IETF but has worked with the IETF to use a room at the same venue.  There’s a website where you can learn more at:

http://www.regiops.net/

and Scott Hollenbeck wrote about the call for participation for the event back in February on CircleID. Scott subsequently provided an update to the provreg mailing list (about the Extensible Provisioning Protocol (EPP)) where he outlined the agenda for Sunday’s workshop that will include:

  • A discussion of the new RFC 7451 about registering extensions to EPP.
  • Richard Barnes of Mozilla will focus on the Let’s Encrypt initiative and the Automatic Certificate Management Environment (ACME) protocol.
  • Olafur Gudmundsson of CloudFlare and Jacques Latour of CIRA will focus on a proposal for a new registry access model to update delegation information.

All of those topics are interesting, but this last topic is of particular importance to us here at Deploy360 as it relates to the challenges for automating DNSSEC within the current DNS registration model. Specifically the inability of DNS operators to update the DS record in a TLD registry. This lack of automation may have played a role in the recent HBO NOW problem with misconfigured DNS records – and regardless is clearly a point that needs to be fixed.  Olafur and Jacques will be discussing this issue and seeking input on what can be done.

If you are interested in these topics you can visit the ROW website to register and attend on Sunday.  Remote attendance is possible (for instance, I will be doing so).  You just need to register on the ROW website and they will send you the info about how to participate remotely.

I think this is a great initiative to increase communication between operators who interact with registration systems and I would encourage you to check it out and participate if you can.  Any way we can increase the automation that helps make the Internet more secure is a good thing!

Feb 05

CloudFlare Wants To Update DNS Registration Model To Automate DNSSEC

CloudFlare logoOver on the CloudFlare blog today, Olafur Gudmundsson wrote a lengthy post titled “Updating the DNS Registration Model to Keep Pace with Today’s Internet” where he outlines a critical challenge that CloudFlare has run into on their path to implementing DNSSEC for their customers.

Essentially, the issue is this – on the signing side of DNSSEC, the process works like this:

  1. A “DNS Operator” may host your DNS records and sign them with DNSSEC keys.  As part of doing this, they will generate a “Delegation Signer” or “DS” record that must be provided to the parent zone (typically a top-level domain (TLD)) to complete the “global chain of trust”.
  2. The DNS Operator has to communicate this DS record to the Registrar for the domain.
  3. The Registrar then provides this DS record to the Registry that operates the TLD.

This needs to be done initially when the domain is first signed with DNSSEC – and then the process needs to be performed every time the Key Signing Key (KSK) for the domain is rolled over.  Typically this might be done once each year but could be done more or less frequently.  The key point is that every time there is a key rollover, the new DS record must be communicated up to the TLD.

Here’s one way that I show the process graphically:

DNSSEC Signing Steps

Notice the role of the Registrar here. They are in the middle of the process.

And THAT is CloudFlare’s problem.  They say they are hosting 2 million domains for customers.  In order for CloudFlare to automate DNSSEC signing to be as simple as a clicking/tapping a button in their user interface (as they have done for IPv6), they need to be able to interact easily with the registries for all those domains – and in the current system that means interacting with all the registrars!  Making it more challenging, some registrars have a clue about DNSSEC – and many others still don’t.

It’s a challenging issue.  As Olafur notes, there are now DNS records such as CDS and CDNSKEY, defined in RFC 7344, that can help with this, but they will require registrars to do some work to look for those records. But there are larger issues here that get into business processes, too.  For instance, many registrars are also DNS operators who will gladly host your DNS records for you for a fee – they have very little incentive to help make it easy for other DNS operators to host your domain.   There are a number of other issues.

Olafur began talking about this back at IETF 91 in Hawaii and this will be a big panel discussion at next week’s DNSSEC Workshop at ICANN 52 in Singapore (which will be streamed live and also recorded).

There is also a public mailing list set up for anyone who is interested in helping work on this issue.  You can join the effort and subscribe at:

https://elists.isoc.org/mailman/listinfo/dnssec-auto-ds

This work will be ongoing for quite some time and probably wind up in the DNSOP Working Group within the IETF.  It’s a critically important challenge we need to address to bring further automation to DNSSEC deployment and help many more people secure their domains.

Your feedback on all of this is definitely welcome!  Please do leave a comment here… or on Olafur’s blog post… or on social media… or contact Olafur directly.

And… if you want to get started with DNSSEC, please do visit our Start Here page to begin!

Oct 21

DPRIVE – New IETF Working Group On DNS Privacy

IETF LogoHow can we ensure the confidentiality of DNS queries to protect against pervasive monitoring?  What kind of mechanisms can be developed to increase the privacy of an individual’s DNS transactions?

After holding a BOF session (DNSE) at an earlier IETF meeting, the IETF has now chartered a new Working Group called DPRIVE (DNS PRIVate Exchange) to dig into this matter. Part of the WG charter states:

The set of DNS requests that an individual makes can provide an
attacker with a large amount of information about that individual.
DPRIVE aims to deprive the attacker of this information. (The IETF
defines pervasive monitoring as an attack [RFC7258])

The primary focus of this Working Group is to develop mechanisms that
provide confidentiality between DNS Clients and Iterative Resolvers,
but it may also later consider mechanisms that provide confidentiality
between Iterative Resolvers and Authoritative Servers, or provide
end-to-end confidentiality of DNS transactions. Some of the results of
this working group may be experimental. The Working Group will also
develop an evaluation document to provide methods for measuring the
performance against pervasive monitoring; and how well the goal is met.
The Working Group will also develop a document providing example
assessments for common use cases.

The group has adopted its first document for consideration, Stephane Bortzmeyer’s “DNS privacy considerations”, draft-bortzmeyer-dnsop-dns-privacy, and discussion has already begun on the “dns-privacy” mailing list.  This list is open to anyone to join. You can subscribe at:

https://www.ietf.org/mailman/listinfo/dns-privacy

and the archives are available at:

http://www.ietf.org/mail-archive/web/dns-privacy/current/maillist.html

While this group does not directly relate to the work we do here at Deploy360 related to DNSSEC, it is part of the overall effort to increase the security of the DNS, and so I thought it would be of interest to our readers.

If you are interested in monitoring what is being discussed about DNS privacy, or contributing to those discussions, I would definitely encourage you to subscribe and join in the conversations and the work to make the Internet more secure!

Mar 28

Next DNS-OARC Meeting May 10-11, 2014, Before RIPE68 in Warsaw

dns-oarcIf you are interested in all matters related to DNS, including DNSSEC, the next meeting of the DNS Operations Analysis and Research Center (DNS-OARC) will take place May 10-11, 2014, in Warsaw, Poland.  Sponsored this time by Microsoft, the “OARC 2014 Spring Workshop” is immediately before the RIPE 68 meeting taking place in the same location.

The agenda for the OARC 2014 Spring Workshop is still evolving but already includes a range of what look like excellent presentations related to DNSSEC and other similar topics.  The attendee list, too, is also filling up with many people with deep experience from across the industry.

It should be an excellent event for those interested in DNS and DNSSEC!

Meeting registration is free if you can get to Warsaw.  If you were already planning to go to the RIPE 68 meeting why not go a couple of days earlier and immerse yourself in DNS? :-)

Mar 27

New IETF Mailing List To Discuss Privacy and Confidentiality of DNS

IETF LogoHow can we better protect the privacy and confidentiality of DNS queries? While DNSSEC protects the integrity of answers coming back from DNS (i.e. ensuring they aren’t modified in transit), what can be done to protect the confidentiality and privacy of information retrieved from DNS?  Particularly against the kind of pervasive monitoring and large-scale network sniffing we’ve become aware of?

We mentioned previously that at IETF 89 this month in London there was the “Encryption of DNS requests for confidentiality” (DNSE) BOF looking at these topics.  There was vigorous discussion during that BOF and then at the DNSOP working group meeting.  That large amount of interest has now sparked the creation of a new mailing list for all those interested in participating.  This “dns-privacy” list is public and open to anyone to subscribe:

List address: dns-privacy@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/dns-privacy
Archive: http://www.ietf.org/mail-archive/web/dns-privacy/

As you can see from the mailing list archive, there is already some discussion underway.  If you want some background the Internet drafts draft-bortzmeyer-dnsop-dns-privacy and draft-koch-perpass-dns-confidentiality may be useful.

While this doesn’t specifically related to the DNSSEC topic we cover here on Deploy360, it is part of the same overall space of “making DNS more secure” and so I thought it would be useful to point people to this new list.

Working together as an industry and community, we can make DNS more secure!  Please do join in and help out.

Mar 24

Watch/Listen Live TODAY To The “DNSSEC For Everybody: A Beginner’s Guide”

ICANN 49 SingaporeIn just about 1.5 hours from now here at ICANN 49 in Singapore we’ll be part of the “DNSSEC For Everybody: A Beginner’s Guide” session.  Running from 17:00 – 18:30 Singapore time, the session will start at the very basic level of why should anyone care about DNSSEC and get into what kind of problem we are trying to solve.  This session includes a skit where we visually act out DNS and DNSSEC transactions.

You can listen remotely via an audio stream or listen and view the slides via a a virtual meeting room.  Details are on the program page.

The session will be recorded for later viewing, which may be appreciated by any readers in the Western hemisphere (such as those in the USA) for whom Singapore time at UTC+8 will be very early in the morning. :-)

Feb 27

8 Sessions About DNSSEC / DANE / DNS At IETF 89 Next Week

IETF LogoWow! IETF 89 next week in London is going to be an extremely busy week for those of us interested in DNSSEC, DANE  and DNS security in general. As I explained in a post today, “Rough Guide to IETF 89: DNSSEC, DANE and DNS Security“, there are 5 new working groups and BOFs related to DNS and DNSSEC in addition to the three already existing working groups.

I go into a great bit of detail in the Rough Guide blog post, but here are the quick summaries of what is happening this week:

  • The DANE Working Group is focused on how to use the DANE protocol to add more security to TLS/SSL connections. The DANE WG agenda at IETF 89 is about using DANE with email and IM, operational guidance and much more.
  • The DNS Operations (DNSOP) Working Group has a very full agenda with the biggest DNSSEC-related piece being the drafts around how to deal with the critical issue of the uploading of DS records from DNS operators to registries.  Some other great DNSSEC work being discussed there, too.
  • The brand new Using TLS in Applications (UTA) Working Group that has as a primary goal to deliver a set of documents that are “go to” security guides aimed at helping developers add TLS support into their applications.  We’re interested in the potential DNSSEC/DANE connection there.
  • The new Public Notary Transparency (trans) Working Group on Wednesday that is looking at how to update the experimental RFC 6962, “Certificate Transparency”, to reflect recent implementation and deployment experience.  Our particular interest is that part of the charter is to ensure that this mechanism can work in the presence of DANE records in addition to regular web certificate-based system.
  • The new EPP Extensions (eppext) working group that is focused is looking at draft-ietf-eppext-keyrelay that defines a mechanism that can be used to securely transfer a DNSSEC-signed domain from one operator to another.
  • The “Encryption of DNS requests for confidentiality” (DNSE) BOF is exploring how to protect the confidentiality of DNS requests from sniffing.   The DNSE BOF will use draft-bortzmeyer-dnsop-dns-privacy and draft-koch-perpass-dns-confidentiality as starting points for discussion.
  • The Domain Boundaries (dbound) BOF is looking at how domain names are used in setting security policies.  Our interest is in understanding how this may fit into the other DNS security components of the work we are doing such as DNSSEC and DANE.
  • The Extensions for Scalable DNS Service Discovery (dnssd) Working Group is continuing their discussions about how DNS-SD (RFC6763) and mDNS (RFC6762) can be used beyond the local network. Our interest is in how this all gets done securely.

We will finish out the week with a breakfast meeting Friday morning with people involved in the DNSSEC Coordination effort (and anyone can join the mailing list) where we’ll have some conversation and food before heading off to the DNSOP and/or UTA working groups.

It’s going to be a crazy-busy week… but I’m looking forward to seeing all that we can get done!

Relevant Working Groups and BoFs

dnssd (Extensions for Scalable DNS Service Discovery) WG
Monday, March 3, 2014, 1300-1500 UTC, Sovereign Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: https://datatracker.ietf.org/wg/dnssd/charter/

dnse (Encryption of DNS request for confidentiality) BOF
Tuesday, March 4, 2014, 1420-1550 UTC, Viscount Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dnse/
List of BOFs: http://trac.tools.ietf.org/bof/trac/

trans (Public Notary Transparency) WG
Wednesday, March 5, 2014, 1520-1620 UTC, Blenheim Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/trans/
Documents: https://datatracker.ietf.org/wg/trans/
Charter: https://datatracker.ietf.org/wg/trans/charter/

dane (DNS-based Authentication of Named Entities) WG
Thursday, March 6, 2014, 0900-1130 UTC, Park Suite
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dane/
Documents: https://datatracker.ietf.org/wg/dane/
Charter: http://datatracker.ietf.org/wg/dane/charter/

dbound (Domain Boundaries) BOF
Thursday, March 6, 2014, 1520-1650 UTC, Blenheim Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dbound/
List of BOFs: http://trac.tools.ietf.org/bof/trac/

eppext (Extensible Provisioning Protocol Extensions) WG
Thursday, March 6, 2014, 1700-1830 UTC, Park Suite
Agenda: https://datatracker.ietf.org/meeting/89/agenda/eppext/
Documents: https://datatracker.ietf.org/wg/eppext/
Charter: http://tools.ietf.org/wg/eppext/charter/

dnsop (DNS Operations) WG
Friday, March 7, 2014, 0900-1130 UTC, Sovereign Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charter/

uta (Using TLS in Applications) WG
Friday, March 7, 2014, 0900-1130 UTC, Richmond/Chelsea/Tower Rooms
Agenda: https://datatracker.ietf.org/meeting/89/agenda/uta/
Documents: https://datatracker.ietf.org/wg/uta/
Charter: http://tools.ietf.org/wg/uta/charter/

Remote Participation

You don’t have to be in London to participate in the meetings of IETF 89. You can also:

  • Listen to live audio streams.
  • Participate in Jabber chat rooms to ask questions.
  • Download the slides planned for each session.
  • Listen and watch “Meetecho” conferencing sessions that provide an integrated view of slides, audio, chat and video.

Information about how to participate can be found on the IETF 89 Remote Participation page.  Keep in mind that times for London are in UTC.

Feb 25

SSAC Issues New Report On DDoS Attacks Against DNS

SSAC logoWhat can be done to prevent Distributed Denial of Service (DDoS) attacks against the DNS infrastructure? What can individuals or organizations who operate DNS servers do to their own systems to help reduce the threat of DDoS attacks?   ICANN’s Security and Stability Advisory Committee (SSAC) took on this issue recently and released a new report this week: “SAC065: SSAC Advisory on DDoS Attacks Leveraging DNS Infrastructure“.  It is available as a free PDF download in English.

While the report is not about DNSSEC, per se, it is about the overall issue of “DNS security” and outlines steps that can be taken to reduce the potential of DNS-based DDoS attacks.  This is critical if we are to get DNSSEC more widely deployed because there are some DNS server operators who have pushed back about DNSSEC citing concerns about the larger size of DNSSEC packets could help amplify DDoS attacks.

The recommendations for the industry include the following (with the report providing more detail on each):

Recommendation 2: All types of network operators should take immediate steps to prevent network address spoofing.

Recommendation 3: Recursive DNS server operators should take immediate steps to secure open recursive DNS servers.

Recommendation 4: Authoritative DNS server operators should investigate deploying authoritative response rate limiting.

Recommendation 5: DNS operators should put in place operational processes to ensure that their DNS software is regularly updated and communicate with their software vendors to keep abreast of latest developments.

Recommendation 6: Manufacturers and/or configurators of customer premise networking equipment, including home networking equipment, should take immediate steps to secure these devices and ensure that they are field upgradable when new software is available to fix security vulnerabilities, and aggressively replacing the installed base of non-upgradeable devices with upgradeable devices.

We agree with those recommendations and definitely encourage people to read the SSAC report and implement as many recommendations as possible.

Working together we can make the Internet more secure!