Resolving DNSsec

1. Rev 1.0

2. Resolving DNSsec Mats Dufberg TeliaSonera, Sweden

3. 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.0

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

5. 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.0

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

7. Levels of DNSsec resolving • Dedicated DNSsec resolver does the job, the client is not aware of DNSsec. • Dedicated DNSsec resolver does the job, but the client request DNSsec answer. • The client does the validation itself. Rev 1.0

8. 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.0

9. 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.0

10. 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.0

11. 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.0

12. 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.0

13. 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.0

14. 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.0

15. 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.0

16. 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.0

17. 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.0

18. 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.0

19. 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.0

20. 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.0

21. 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.0

22. 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.0

23. 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.0

24. 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.0

25. 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. Rev 1.0

26. …thanks

27. Rev 1.0