Rev 1.01 2010-06-03

Mats Dufberg

TeliaSonera, Sweden

Resolving DNSsec

Rev 1.03 2010-06-03

What is TeliaSonera?

• TeliaSonera is one of the major ISP:s in Scandinavia and in the Baltic states.

• TeliaSonera has one of the largest peering network in Europe, North America and in Asia.

• TeliaSonera is the largest ISP in Sweden.

Rev 1.04 2010-06-03

DNS resolving for the customers

• TeliaSonera Sweden has one dedicated, redundant and distributed DNS resolving system for all customers: Dial-up Broadband Fiber to the home Corporate backbone circuits Mobile broadband 3G/GPRS

• In total 1.5-2 million users depend on our DNS resolving system.• Most clients get the DNS resolvers automatically, e.g. DHCP or

PPP.• Some corporate users have their own DNS resolvers, and some

of those do forwarding to ours.

Rev 1.05 2010-06-03

DNS resolving system

• We have multiple Intel based servers with Linux OS. Server program is ISC Bind 9 – currently ver. 9.4 and 9.6 built

with full DNSsec support.• The servers sit in four sites behind load balansers.

Rev 1.06 2010-06-03

DNSsec supported

• DNSsec for resolvning services has been in production since June 2007 for all customers (in Sweden).

• DNSsec for hosting is planned for start of 2011.

Rev 1.07 2010-06-03

Levels of DNSsec resolving

1. Dedicated DNSsec resolver does the job, the client is not aware of DNSsec.

2. Dedicated DNSsec resolver does the job, but the client request DNSsec answer.

3. The client does the validation itself.

Rev 1.08 2010-06-03

The effect of the user of the DNSsec resolving

• DNSsec resolving is backward compatible with DNS resolving. We assume ”level 1”.

The user will not discover that the resolvers are DNSsec enabled, unless they request with DNSsec turned on.

Plain DNS queries will get plain DNS answers even if DNSsec validation has been done.

• We do not expect the users to discover any new behavior of DNS.

• This is good news!

Rev 1.09 2010-06-03

What is required for DNSsec resolving?

• DNSsec compatible server program, e.g. ISC Bind 9.4 or higher. There are other alternatives such as

Nominum CNS NLnet Labs Unbound

• DNSsec validation must be enabled (in Bind).• Select what zone (domain) or zones (domains) to trust, .SE in our

case. For each zone, add a trust anchor.

Trust anchor is equal to the public KSK of the zone. Every KSK in the zone can be added as trust anchor.

If you trust a zone, you will automatically trust sub-zones with correct DNSsec delegation (DS record included).

Rev 1.010 2010-06-03

Trust anchors are needed

• No validation is done for a zone if there is no trust anchor for that zone or its ancestor.

• The root zone will soon be the natural choice.

Rev 1.011 2010-06-03

DNSsec traffic

• How much traffic is effected by the DNSsec update? – Bind does not provide us with any measures, so we can only guess. We could dump the traffic, but we have not. Our focus has been on stability etc rather than measuring

DNSsec traffic.

• .SE is the major TLD for the Swedish user community. Even though there are still few DNSsec delegations, the .SE zone itself is signed. Every query for a new domain will start the validation process.

• The validation process does not require that the query ask for validation. Validation is based the existence of trust anchor and DS record in delegation.

Rev 1.012 2010-06-03

Instability, bugs...

• Problems with DNS resolving are know. What can we expect from DNSsec resolving? Everything that can happen with DNS resolving can happen

with DNSsec resolving. Plus more.

• Areas that we should look at are: Stability Network requirements Performance Resource requirement Support calls from users (customers) Troubleshooting Key management (trust anchors)

Rev 1.013 2010-06-03

Stability

• DNSsec resolving uses code in Bind not else used. Fewer can discover and report the bugs. We saw bugs in bind, especially in 2007.

• DNSsec validation adds a complex step to the resolver process – more things that can go wrong.

• We should expect DNSsec resolving to be less stable than plain DNS resolving.

Rev 1.014 2010-06-03

Network requirements

• DNSsec increases the chance that the answers are larger than can be put into one UDP packet. Make sure that IP fragements can be handled in incoming

answers (from servers on Internet) or set the maximum accepted UDP packet size down.

Make sure that IP fragments can be handled in outgoing answers (to clients) or limit size.

• There are known issues with home routers and DNSsec. It only affects users that has turned DNSsec on.

Rev 1.015 2010-06-03

Performance and resource requirements

• We did not see any effect on performance.• We have not yet seen any increase in CPU or memory usage.• We do not know what resource requirements to expect in the

future. We expect future DNSsec resolving to require faster CPU’s

and more memory than plain DNS resolving.

• By adopting early, we can increase capacity to meet increased load of DNS and increased use of DNSsec at the same time.

Rev 1.016 2010-06-03

Support calls from users and troubleshooting

• We have seen support calls from customers that can be related to DNSsec as such. Most known error so far are .SE domains that are not signed

but the delegation includes a DS record. Our resolvers will refuse to resolv the domain (SERVFAIL), non-

DNSsec aware resolvers accept the domain. Customers complain that our resolvers are broken.

• Bad news is that troubleshooting is much more complex...

• .SE has created a web based tool, DNScheck http://dnscheck.iis.se/, that checks for various errors including DNSsec errors. The code is available as open source.

Rev 1.017 2010-06-03

Key management – managing trust anchors

• DNSsec resolving requires one or more trust anchors. The trust anchor in the resolver is the public KSK of the zone

(domain) to trust.• Until the root zone is signed we only trust .SE.

Rev 1.018 2010-06-03

Renewing the trust anchor

• DNS resolving can be left running by itself.• DNSsec resolving requires that the trust anchor or trust anchors

are updated. The trust anchor in the resolver is the public KSK of the

domain (zone) to trust. Contrary to SSL certificates there is no built in last date of

validity. It is an administrative decision of the domain owner when to

do a key roll-over. We depend on announced roll-over dates.

When the KSK has been rolled over, the trust anchor must be updated.

Rev 1.019 2010-06-03

Missing to renew a trust anchor

• If the trust anchors do not match the KSK’s of the zone, the DNSsec resolver will refuse to return any data for that domain.

• Missed update will make that domain, and all its subdomains, unavailable! We know, because we have been there!

• Make sure to have a process for renewals.

• Make sure to have tools for renewals.

Rev 1.020 2010-06-03

Fetching Trust Anchor for a TLD

• Each TLD will have their own site where the KSK is published. We must trust that the TLD will have systematic procedures

before we include the KSK as Trust Anchor.

• But hopefully we will have a signed root zone in July.

Rev 1.021 2010-06-03

IANA ITAR

• TAR = Trust Anchor Repository• IANA has a TAR for TLDs, ITAR, Interemistic TAR.• KSK records will be available for signed TLDs.• TLDs must enter their KSK, or else it will not be included.

• This TAR might be a good source for Trust Anchors. We can judge the policy it will run under. We have to trust that the TLDs will update, or we cannot trust

the TAR.

• We should be sceptical to TARs run as private initiatives! It is better not to have any trust anchor for a domain than to

trust some private, third party.

Rev 1.022 2010-06-03

DLV

• DLV = DNSsec Lookaside Validation• It is not a standard, it is just a technique available in Bind• DLV lets the resolver fetch the trust anchors via DNS from some

zone in DNS. DLV can be used when the parent zone is not signed. The resolver will depend on the DLV zone. If not available, all

validations will fail!• DLV is a dead-end solution (my opinion )

• E.g. ISC (creator of Bind) runs a DLV.

Rev 1.023 2010-06-03

RFC 5011 – automatic renewal of trust anchors

• RFC 5011: ”Automated Updates of DNS Security (DNSSEC) Trust Anchors” Set by the IETF (proposed standard).

• Defines how to make trust anchor renewal automatic in a DNSsec resolver – if the TLD is compliant in its KSK roll-over. Does not help how to insert initial trust anchor.

• It has not yet been implemented by any TLD (as far as I know).

• Bind 9.7 will support RFC 5011 Support both as authorititative and resolver.

Rev 1.024 2010-06-03

Emergency KSK key roll-over

• Do not expect unplanned renewal of trust anchors due to emergency roll-over of KSK to be handle automatically.

• With many trust anchors the risk is higher that a needed emergency renewal is missed.

• This is an area that requires some additional planning and thoughts.

• If different TLD’s have similar procedure and cooperate we will probably see fewer missed emergency roll-over.

Rev 1.025 2010-06-03

Signed root zone

• The DNSsec model assumes that the root zone is signed.• When the root zone is signed we could concentrate on other

issues instead of trying to find work arounds.• The schedule is that the root zone will be signed in July.

• A signed root zone will make life much easier for all DNSsec resolver operators. We could be able to validate the entire, contiguous DNSsec

space with one trust anchor.

• A signed root will replace other trust anchors. If the signing of the root is delayed considerably or postponed, then we have to go back to IANA ITAR and fetch trust anchors there.

…thanks

Rev 1.027 2010-06-03