HOW DNSSEC RESOLUTION PLATFORMS BENEFIT FROM LOAD BALANCING TRAFFIC ACCORDING TO FULLY QUALIFIED DOMAIN NAME Daniel Migault Orange Labs, Issy-les-Moulineaux, France daniel.migault@orange-ftgroup.com Maryline Laurent Institut TELECOM, TELECOM SudParis, CNRS Samovar UMR 5157, Evry, France Maryline.laurent@it-sudparis.eu Abstract—In July 2008, the Kaminsky attack showed that DNS is sensitive to cache poisoning, and DNSSEC is considered the long term solution to mitigate this attack. Compared to DNS, DNSSEC resolution requires cryptographic operations such as signature checks or hashing data. Tests over a lab platform, as well as deployment feed back shows that migration of a DNS platform to DNSSEC requires five times more nodes than with DNS. ISP with already large DNS platform can hardly migrate to DNSSEC with the currently designed platform. In fact currently designed platform split DNS traffic over a n node platform according to the IP addresses of the query. This paper provides an alternative architecture where DNS(SEC) traffic is load balanced according to the Fully Qualified Domain Name (FQDN) of the query. Simulation shows that such an architecture is 1.409 time more efficient than current architecture. This paper briefly describes the DNSSEC protocol, then based on experimental measurements it estimates the cost of migrating from DNS to DNSSEC. The last section compares different load balancing strategies, and shows that load balancing traffic according to FQDN seems promising. Index Terms—DNS, DNSSEC, performance I. WHAT IS DNSSEC DNSSEC [2], [4] and [3] provides mechanisms to authen- ticate the origin of the RRset, integrity protect RRsets, build a chain of trust and prove the non-existence of the FQDN. Authentication and integrity protection are performed by the signatures (RRSIG). This means that each DNSSEC zone MUST be somehow assigned an identity – a Key Signing Key (KSK) – and a key that signs the DNS zone – Zone signing Key (ZSK). The KSK has also cryptographic properties and is used both to identify a zone and to sign the ZSK so that ZSK are bound to the proper KSK. The chain of trust implies that once you trust one entry, you can securely trust the subdomains. This trust delegation is performed through the Delegation Signer (DS) RRset, where a parent specifies the KSK of its child. The proof of non existence can be performed through two different mechanisms. NSEC [2], [3], [4] and NSEC3 [5]. Both mechanisms are based on ordering all RRsets of a zone file as a dictionary. Each FQDN has a specific place in the zone file, and NSECx RRsets provide the link between the FQDNs. NSECx proves the FQDN does not exist since it indicates the FQDN is not at the right place. Furthermore, the response is signed by the authoritative server. By ordering and providing FQDN, NSEC enables zone walking [1], that is to say downloading the whole zone file even though the AXFR is disabled. NSEC3 addresses this problem by considering the hash of the FQDN instead of the FQDN itself. II. PERFORMANCE I SSUE Suppose a resolver sends a DNS query to get the IP address of a given FQDN. In our case we also suppose that the queried FQDN exists and has a valid answer. The response has an ANSWER section that contains a few RRsets such as the different IP addresses that corresponds to the queried FQDN (RRsets of type A for IPv4 or AAAA for IPv6). The response also has an AUTHORITATIVE section that contains the name of the authoritative Name Servers (RRset of type NS) as well as the corresponding IP addresses of the authoritative servers (RRste of type A or of type AAAA). With DNSSEC each different Type comes with a signature, which means that in our case we will has up to 4 signatures (1 for the queried FQDN IP address (A or AAA), one for the authoritative section (NS) and one or two for the additional section depending if there one family of IP addresses or both IPv4 and IPv6 addresses. On the other hand, if the FQDN has no responses we have to consider NSEC3 RRsets to prove the non existence. We will consider the simple case where no wildcard is involved. The ANSWER section is empty. The AUTHORITATIVE section has one NSEC3 RRset that proves the FQDN does not exist. Then we have to prove that the Zone exists, to clearly indicate that the mismatch only occurs with the FQDN. This involves another NSEC3 RRset. At last we have to prove that the FQDN may not result from a wildcard expansion. In other words, we have to prove that the FQDN *.Zone does not exist. This makes 3 signatures to check, as well as 3 hashes to perform. In the latest example above, we supposed that the resolver had the cryptographic material to perform the signature check, or to perform the hash. If not the resolver may request the