Dan York

Just a guy in Vermont trying to connect all the dots...

Author's posts

Deployment Guide: DNSSEC for Internet Service Providers (ISPs)

An Internet Service Provider needs to offer high value while containing costs. One way to increase your services’ value is to ensure your customers get to the intended websites, protecting them from going to phishing sites or sites that distribute malware.

One way to offer such protection at relatively little cost is through DNS Security Extensions, an Internet standard commonly known as “DNSSEC“. By deploying “DNSSEC-validating” DNS resolvers within your network, you will provide a higher level of security and trust to your customers and help prevent certain types of attacks and redirection. You also will enable customers to use innovative services that are now becoming available to add more trust and integrity protection to Web certificates (SSL/TLS).

DNSSEC ensures that the information your users retrieve from the DNS is the same information that the domain’s operator entered into the DNS. It verifies that this information was not modified so that your users are directed to their intended destinations.

DNSSEC has two components: the signing of DNS records for a domain and the validation of those cryptographic signatures by caching recursive nameservers. For an ISP, the deployment of DNSSEC-validating DNS resolvers is the most critical element of DNSSEC adoption and this document explains what is necessary to roll out DNSSEC validation support to your customers.

Initial deployment of DNSSEC validation is usually quite inexpensive, requiring a relatively small investment in new hardware and software and only a modest time investment; typical deployment may be completed with as little as a week of total effort by experienced system administrators, depending on how many recursive nameservers and end users are involved.

Hardware and Software

Caching recursive nameservers are the most important part of a DNSSEC validation deployment since they cache and validate answers to DNS queries submitted by end users. Modern, off-the-shelf server hardware is sufficiently powerful to operate a DNSSEC-validating caching recursive nameserver. In addition, it is perfectly feasible to operate such a nameserver on a virtual machine.

Your choice of nameserver and its vintage are important to your success with DNSSEC. DNS infrastructures based on the BIND DNS server should run at least version 9.7, whose features simplify DNSSEC management. All versions of Unbound natively support DNSSEC validation, although version 1.4 and later have features that simplify DNSSEC management.

Microsoft Windows Server 2012 now includes full DNSSEC support, allowing administrators to retrieve the necessary root trust anchors via command-line instructions. A whitepaper by Netherlands DNSSEC authority Surfnet explains this process; you can download the PDF of their guide to DNSSEC installation here.

Effects on Network

In your planning, you should be aware that DNSSEC traffic has several effects on network traffic:

  • DNSSEC adds digital signatures to DNS response packets, which often exceed 1,500 bytes. While large DNS responses are also possible without DNSSEC, you must consider the additional bandwidth demands that DNSSEC places on the network, and ensure that only legitimate hosts are allowed to query your recursive nameservers.
  • Traditionally, the DNS relies on the UDP protocol to transmit queries and responses, but if a DNS response exceeds the maximum allowed packet size, TCP may be used and even required for DNSSEC validation. Check with your firewall vendor and system administrators to ensure your network allows DNS over TCP.
  • Your network equipment must be able to handle large UDP packets (>512 bytes, ≤4,000 bytes).

Pre-Deployment Checklist

This checklist can help you to plan your deployment:

  • Software supports DNSSEC: BIND version 9.7+, Unbound version 1.4+, Microsoft Windows Server 2012, Knot DNS 1.4.0, PowerDNS 3.0+
  • Server systems are sufficiently modern
  • Network infrastructure can handle DNSSEC requirements
  • DNS over TCP is allowed
  • Large UDP DNS packets are allowed through firewall
  • UDP fragments are not blocked by firewall

Beginning Your Deployment

After your install your recursive caching nameservers (or have existing nameservers where you want to start validating), they must be configured with a “trust anchor” in order to validate DNSSEC signatures. You can obtain the trust anchor for the root of the DNS from sources such as https://www.iana.org/dnssec. You can check the trust anchor’s validity by obtaining it from multiple independent sources (i.e. multiple root servers) and comparing the files.

When you enable DNSSEC validation on your recursive caching nameserver you may see validation failures in the log files. While these errors could be signs of a cache-poisoning attack, they may also result from operational errors (particularly in these early days of DNSSEC deployment). This could be something as simple as a zone owner’s failure to re-sign their zone information.

Validation failures for a zone will mean that your users will not be able to connect to that domain. When errors of this type appear it is far better to inform users about the source of the problem and how they were protected from using potentially insecure information, rather than disabling validation in order to provide continued access to the “broken” domain. Standards concerning how to perform this notification continue to evolve, though some organizations have used a dedicated website or social-media channel to post notifications of current validation failures. Regardless of what system you create, it is important that your customers and customer-support team can easily find the information.

Certain ISPs may also install a temporary “negative trust anchor” for broken sites while notifying the zone’s operators of problems or errors that will probably severely degrade their users’ Internet experience. An Internet Draft document is available that explains this process.

While feedback from people currently operating validating caching recursive nameservers show that enabling DNSSEC validation does not necessarily increase user help-desk calls, it is still sensible to train help-desk staff concerning DNSSEC and potentially provide them with tools (i.e. a non-validating resolver) to help with debugging.

Conclusions

DNSSEC rollout is progressing steadily on the Internet, and deployment of validating caching recursive nameservers is an important part of this trend. By deploying DNSSEC within your network you will increase your customers’ Internet security. Doing so provides significant benefits at a minimal cost, and we urge you to begin this process today.

FIR #729 – 11/11/13 – For Immediate Release

Shel traveling, Inside PR joins the FIR Podcast Network, Listener Survey results update; Quick News: Google Helpouts announced, Facebook ditches 'Like', Google tests new 'follow users' tech; Ragan promo; News That Fits: Communication and the Twitter IPO; Dan York's Tech Report, the Media Monitoring Minute, listener comments, Michael Netzley's Asia Report, Cision study on UK journalists use of social media; shoutout to Effective Edge Communications; music by Manic Street Preachers; and more.

First Nine English-Language newgTLDs Delegated by ICANN – .Camera, .Clothing, .Singles and More… (Featured Blog)

This past week brought word that the first nine Latin / ASCII "new Generic Top Level Domains (newgTLDs)" were delegated by ICANN and are now found in the root of DNS. This means that the registries behind these newgTLDS can now start the process of making "second-level domains" (the ones we normally register) available in each of these TLDs. More...

First Nine English-language NewgTLDs Delegated By ICANN – .Camera, .Clothing, .Singles and more… (Featured Blog)

More...

TDYR #046 – A Great Week In Vancouver – Now On To Toronto

TDYR #046 - A Great Week In Vancouver - Now On To Toronto by Dan York

Deploy360@IETF88: Day 3 – Perpass, IPv6 Operations and Operational Security

IETF LogoOn Day 3 of IETF88 our focus is again on IPv6 as well as the overall topic of hardening the security of the Internet.  The first sessions we’re primarily tracking is the IPv6 Operations (V6OPS) which has a whole range of documents under consideration relating to IPv6 addressing. The second session is Operational Security (OPSEC) where there are two drafts related to IPv6 security.

On a broader topic, we’ll be watching the IETF 88 Technical Plenary focused on “Hardening The Internet” and then the “Perpass” working group coming up after that.

My earlier posts about DNSSEC sessions and IPv6 sessions at IETF 88 explain in more detail what we’ll be watching.

Information about the four sessions today, including the links for the audio streams, the slides and the Jabber chat rooms, is:

For these sessions and all the others, the “tools-style agenda” for IETF 88 provides many helpful links for remote participants.

If you’d like to meet with the Deploy360 team here at IETF88, please see our post about where we’ll be at IETF88.

Deploy360@IETF88: Day 2 – SIDR, DNSOP, 6tisch, 6lo and the IPv6 Briefing Panel

IETF LogoDay 2 at IETF88 includes the primary sessions this week about DNSSEC (in DNSOP) as well as secure routing (SIDR).  There are also two working groups focusing on IPv6 in various network configurations (6lo and 6tisch).  Do note that the meeting of the GROW working group was canceled for today.

The other big event happening in just a few hours is the “Internet Society @ IETF Briefing Panel: IPv6 – What Does Success Look Like?” where we will be live-streaming out what looks like will be an outstanding discussion about the state of IPv6 deployment today and where it will be going.  The session starts at 11:45am Pacific time (19:45 UTC).

For more information about these sessions today, we’d encourage you to read our “Rough Guide to IETF88″ documents about:

Information about the four sessions today, including the links for the audio streams, the slides and the Jabber chat rooms, is:

For these sessions and all the others, the “tools-style agenda” for IETF 88 provides many helpful links for remote participants.

If you’d like to meet with the Deploy360 team here at IETF88, please see our post about where we’ll be at IETF88.

Watch Live – What Does “Success” For IPv6 Look Like? (Briefing Panel on Nov 5) (Featured Blog)

Now that IPv6 deployment is happening in major networks around the world, the question becomes -- what does "success" look like for IPv6? How much IPv6 traffic is "enough"? What are major milestones we should be tracking in IPv6 deployment? What is next for IPv6? More...

Deploy360@IETF88: Day 1 – 6Man and v6OPS

IETF LogoOur first day here at IETF88 is a quieter day for us on the Deploy360 team in terms of the number of sessions but  today’s sessions are two of the biggest in terms of content related to our work with IPv6.   The “6man” working group is focused on the “maintenance” of IPv6 and continuing the evolution of the IPv6 protocol.  The 6man agenda is FULL of talks about suggested fixes and improvements – and should generate some good discussion and actions.

Similarly, today’s “IPv6 Operations” (v6ops) sessions has what should be very interesting discussions:

Xbox One and Teredo
Balanced Security for IPv6 Residential CPE
An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices
NAT64 Operational Experiences
Recommendations of Using Unique Local Addresses
464XLAT CLAT IPv4 Address

Information about the two sessions today is here, including the links for the audio streams, the slides and the Jabber chat rooms:

For these sessions and all the others, the “tools-style agenda” for IETF 88 provides many helpful links for remote participants.

If you’d like to meet with the Deploy360 team here at IETF88, please see our post about where we’ll be at IETF88.


An audio version of this post is also available:

Meet The Deploy360 Team At IETF 88 In Vancouver This Week

IETF LogoThe 88th meeting of the Internet Engineering Task Force (IETF) takes place this week in Vancouver, BC, and Megan Kruse and myself (Dan York) will be there participating in Working Group sessions, recording some video interviews, helping with the live video stream of the IETF 88 Technical Plenary and the ISOC@IETF panel on IPv6 and just generally meeting with people about how we accelerate the deployment of IPv6, DNSSEC and routing technologies!

If you’d like to meet with us at IETF 88, the best bet is to probably send an email to:

deploy360@isoc.org

as that gets to both of us and the rest of the team.  As to where you can find us at IETF 88, you can expect to find Megan and I in most of the sessions related to IPv6, DNSSEC or routing resiliency/security.  Here are some of the prime ones where one or both of us will be:

You can also expect us to be in other sessions where IPv6 or DNS or routing security are mentioned.  We’re around and we’d definitely be interested in meeting with people while here.  Please do drop us an email message or find us in person.