An integrated testing system for IPv6 and DNSSEC
© Chang. 2016
Received: 29 March 2016
Accepted: 12 July 2016
Published: 27 July 2016
IPv6 protocol, which should replace the actual IPv4 protocol, brings many new possibilities and improvements considering simplicity, routing speed, quality of service, and security. In comparison to IPv4, IPv6 improves mechanisms for assuring a secure and confidential transfer of information. DNS has been extended to provide security services (Domain Name System Security Extensions (DNSSEC)) mainly through public key cryptography. We propose a new approach to DNSSEC that may result in a significantly more efficient protocol. We introduce a new strategy to build chains of trust from root servers to authoritative servers. The techniques we employ are based on symmetric-key cryptography. With the depletion of IPv4 address and rampant information security threat, IPv6 and DNSSEC are widely deployed in recent years, but there is no platform that can integrate all relevant detection information and technical information and provide advice for officers concerned in Taiwan. This paper implements an Auxiliary Deployment System for IPv6 and DNSSEC and presents the results of preliminary testing and statistics which can help technology and promoting staff to do evaluation, promotion, and debugging on IPv6 and DNSSEC deployment easily.
KeywordsIPv6 DNSSEC Security testing
The Internet protocol (IP) address is the necessary network protocols for each individual computer to access the Internet. Before 2013, almost all computers are connected to the Internet via Internet Protocol Version 4 (IPv4) addresses, but unfortunately, with the growth of the Internet population, the use of IPv4 addresses has become less and less. In other words, IP is facing the problem of depletion. Actually, IPv4 address exhaustion has been anticipated since the late 1980s, and as unexpectedly, the top-level exhaustion occurred on January 31, 2011 [1–3] and the RIR (Regional Internet Registries) and the APNIC’s (Asia-Pacific Network Information Centre) exhaustion on April 15, 2011, and some parts of the world have already exhausted their IPv4 allocations [4–6], and the remaining RIRs are expected to deplete their pools within a few years . To deal with the long-anticipated problem of IPv4 address exhaustion, Internet Protocol Version 6 (IPv6) was developed by the Internet Engineering Task Force (IETF) in 1996 that started with RFC 1883.
World Internet usage and population statistics
World Internet usage and population statistics
June 30, 2012
Population (2012 est.)
Internet users Dec. 31, 2000
Internet users latest data
Penetration (% population)
Growth 2000–2012 (%)
Users % of table (%)
Internet population increased rapidly in all regions, but IP which can be directly connected to the Internet is limited. Thus, it is particularly important to promote IPv6. On June 8, 2011, top websites and Internet service providers around the world, including Google, Facebook, Yahoo!, Akamai, and Limelight Networks joined together with more than 1000 other participating websites in World IPv6 Day for a successful global-scale trial of the new Internet Protocol, IPv6 . On June 6, 2012, the Internet Society carried out a World IPv6 Launch day to bring permanent IPv6 deployment for the products and services of the participants . Following the success of the 2011 test day and 2012 launch day, there are more and more government agencies and business organizations to complete the deployment of IPv6.
IPv6 and Domain Name System Security Extensions (DNSSEC) are the next generation of Internet infrastructure. For a more stable and secure network environment, countries around the world are actively promoting the deployment. In view of this, this paper proposes and implements an Auxiliary Deployment System for IPv6 and DNSSEC to help technology and the promoting staff to do evaluation, promotion, and debugging on IPv6 and DNSSEC deployment easily in Taiwan.
The rest of the paper is organized as follows: First, some knowledge and existing tools are introduced in Section 2. Second, the design of Auxiliary Deployment System and its expected results are described in Section 3. Then the implementing process of our system and its demo are given in Section 4. Finally, our conclusion is drawn in Section 5.
IPv6 is the latest version of IP, and it is also called Internet Protocol next generation (IPng). IPv6 is intended to replace IPv4 which was developed by the IETF to solve the increasingly serious problem of IPv4 address exhaustion. In Section 2, we introduce the deployment status of Taiwan and around the world.
2.1.1 Status of IPv6 deployment
Figure 2 shows the status of IPv6-enabled users worldwide as measured by Google. We can see that the number of people using IPv6 significantly increased in recent years.
The Domain Name System Security Extensions (DNSSEC) has been proposed to deal with the lack of data integrity and validation of data sources by IETF. In Section 2.2.1, how DNSSEC works is introduced, and related research on DNSSEC is summarized in Section 2.2.2. At last, Section 2.2.3 describes the deployment status of Taiwan and around the world.
2.2.1 What is DNSSEC?
Due to IP addresses (especially in IPv6) not easily remembered, the DNS has been developed. But DNS provides only the basic mapping services for domain names and IP addresses; hackers can easily tamper with the DNS data or cause the DNS server not to work properly.
According to the research of the past few years, the following problems of DNS were discovered:
DNSSEC public key, defined in RFC 4034.
DNSSEC resource records contain the public key for the zone. They come in two flavors, a zone signing key (ZSK) and a key signing key (KSK). Generally, the KSK signs only certain records within the zone, while the ZSK signs all of the records. You may have as many of each as required for key-rollover protocols or for your needs.
Delegation signer, defined in RFC 4034.
A DS resource records stored key tag, algorithm number, and DNSKEY RR’s digest, used in the DNSKEY certification process. DS resource records and its corresponding DNSKEY resource records have the same owner name, but they are stored in different places. DS resource records appear only in the parent zone, such as “example.com.” DS resource records are then stored in the “com” zone, and its corresponding DNSKEY resource records are to be stored in the “example.com” zone.
DNSSEC look-aside validation, defined in RFC 4431.
The DLV resource record has exactly the same wire and presentation formats as the DS resource record. DLV record does not inherit any of the special processing or handling requirements of the DS record type. Unlike the DS record, the DLV record may not appear on the parent’s side of a zone cut. A DLV record may, however, appear at the apex of a zone.
For example, a DS record has your zone’s name (example.com) while a DLV record has an additional name (example.com.dlv.isc.org.).
Next secure, defined in RFC 4034.
NSEC resource records links to the next record name in the zone and lists the record types that exist for the record’s name. These records can be used by resolvers to verify the non-existence of a record name and type as part of DNSSEC validation.
Next secure ver.3, defined in RFC 5155.
Like NSEC, NSEC3 resource records can also be used by resolvers to verify the non-existence of a record name and type as part of DNSSEC validation. The NSEC3 resource record links to the next record name in the zone and lists the record types that exist for the name covered by the hash value in the first label of the NSEC3 resource records’ own name. NSEC3 resource records have the same functionality as NSEC, except NSEC3 resource records use cryptographically hashed record names to prevent enumeration of the record names in a zone.
Resource record signature, defined in RFC 4034.
RRSIG holds the digital signature of DNSSEC; resolvers can use public key in DNSKEY resource records to verify it.
Simply, DNSSEC is fully compatible with the traditional DNS. And DNSSEC is a set of extensions to DNS which through the mechanism of digital signatures provides the following security guarantees, but not availability or confidentiality.
For data integrity, each DNS zone using DNSSEC requires a pair of keys, namely, “public key and private key,” which are generated by the DNS administrator; the private key is kept secret by the administrator, and the public key is published in the zone file used to define DNSKEY resource records. When the data has been modified, the chain of trust would be broken. Through the layers of verification from the end node to the root zone, we believe that the DNS data are correct. Because root zone was managed by hand, it should not be easily hacked theoretically. DNSSEC allows a resolver to validate that a certain domain name does not exist. When returning a negative DNSSEC response, the DNS server usually includes up to two NSEC records or three NSEC3 records. With these record and hashed data of the DNS record, we can know whether it is true that a URL does not exist.
2.2.2 Related research
DNSSEC in the future is an important network infrastructure. In addition to IETF, in many countries some scholars have conducted research and discussion on this.
On May 3 2007, Mark Santcroos and Olaf M. Kolkman published the “DNS Threat Analysis”; they mentioned that although it has the above advantages, DNSSEC does not solve any of the problems that have to do with transport; in fact, since packets are bigger, they consume more resources in the servers and on the wire and impose rules on firewalls. That may provide new vectors for (D)DOS attacks . Moreover, the key management system is also more complex.
In 2005, Wei-An Chen published “The Easy Security Protection and Validation System for DNS Server using DNSSEC” , and Shiau-Han Jang published “The Study of Apply DNSSEC to building a Protection Mechanism for DNS Pharming”  in 2007. Both discuss and implement DNSSEC system applications.
In 2010, Mantoro, T.; Norhanipah, S.A.; and Bidin, A.F., published “An implementation on Domain Name System security extensions framework for the support of IPv6 environment” . In 2011, papers relating to “against local DNSSEC attacks” , “update scheme” , “OpenID service” , and “mobile peers in HIP networks”  have been published in succession. Lin Tao, Liu Wu, Duan Haixin, and Sun Donghong also published “IPv6 Traffic Hijack Test System and Defense Tools Using DNSSEC” .
In 2013, Migault, D.; Senecal, S.; Francfort, S.; Herbert, E.; and Laurent, M., proposed “PREFETCHing to Overcome DNSSEC Performance Issue on Large Resolving Platform” to improve DNSSEC performance issues .
These studies mentioned above make us more confident that DNSSEC will improve our future network environment, so we should actively promote DNSSEC implementation. Actually, several ISPs have started to deploy DNSSEC-validating DNS recursive resolvers. On May 6, 2013, Google Public DNS has enabled the DNSSEC validation by default.
2.2.3 Status of DNSSEC deployment
In order to solve the traditional DNS problems in security, since 2009, many countries have embarked on the top domain DNSSEC-related experiments, and after more than 1 year of experimental test, in 2011, official succession of import operations of DNSSEC appeared.
DNSSEC deployment status of TLDs
Number of support
2.3 Existing detection platform
Next, we will introduce current testing tools for IPv6 and DNSSEC. For IPv6, there are many tools used to detect IPv6.
Since 2001, CHT-TL IPv6 Testing Lab has provided a test service which was named “IPv6 Ready Logo Program” at present.
While the IPv6 Ready Logo Program provides the detailed examination above, it is not free, and neither is the immediate service. More importantly, the IPv6 Ready Logo Program does not provide the function of statistics and records.
The functions on CentralOps.net
Investigate domains and IP addresses. Get registrant information, DNS records, and more—all in one report.
See if a domain is available for registration.
Validate and troubleshoot email addresses.
See what your browser reveals about you.
See if a host is reachable.
Trace the network path from this server to another.
Look up various domain resource records with this version of the classic NsLookup utility.
Get Whois records automatically for domains worldwide.
Grab a web page, look up a domain, and more.
Do a simple, graphical traceroute.
CentralOps.net is free for everybody. It does not require login; simply pick a tool on the menu and use it. In addition to these real-time services, CentralOps.net also provides paid services on extended or automated use of its tools. CentralOps.net provides a variety of testing services that has the advantage of instant and free, but also does not provide the functionality of statistics and records.
3 System design
3.1 Observed objects
To promote IPv6 and DNSSEC in Taiwan, we designed the Auxiliary Deployment System for IPv6 and DNSSEC. Below we will discuss the target objects of the system services.
IPv6 and DNSSEC are the network infrastructure in the future. Because the benefits of IPv6 and DNSSEC for an average user are relatively non-sense, we expect the government to play the role of a leader. In fact, as mentioned in Section 2, the deployment system which TWNIC launched for IPv6 is also designed for each local government. Academic network has been used by many people, including teachers, students, and staff. And each school usually has a variety of server services, such as DNS service, email servers, web servers, FTP servers. Therefore, we believe it is necessary to be promoted on educational institutions. In this paper, educational institutions are classified to state schools and private schools. We can take to explore the future development of both.
Top 10 websites listed by Alexa Internet in 2014
Although this system is primarily used to investigate and test the deployment status of domestic units, we still have to detect and record for upgraded status of ccTLDs. In addition, we also collect national development IPv6 and DNSSEC-related information via the Internet.
3.2 Target objects
A project manager is the leader who is responsible for IPv6 or DNSSEC deployment. Project managers can view all the information and modify all the services and personnel data. In ADS, a project manager is termed “admin,” a leader of technology or promoting staff in IPv6 or DNSSEC deployment in each area. A district manager can only work through the log information and detection to counseling members in their areas of responsibility. In ADS, a district manager is termed “manager,” any person. In addition to the observed objects that were mentioned in the previous section, we also let general users detect objects what they want to do. Users can even choose to perform a complete inspection or testing in general, which can help them to more easily obtain the desired information.
3.3 Research framework
Detection and statistics are the most important features of this system. Users can use this feature to detect their service to obtain the status of IPv6 and DNSSEC deployment and its environment. When the user wants to view the statistical results, the system will automatically generate plain text and graphical information for users. If the user chooses graphical information, then the user can clearly see the upgrade status of each region.
We use the built-in Linux commands “dig,” “ping,” “nslookup,” and others to detect the target address; through the analysis of the target resource records, we can know its deployment status of IPv6 and DNSSEC. For example, if a website has an AAAA resource record and the system could get a header through sending an IPv6 request like a general browser, then the system will determine that the website can support IPv6 connection.
Our tools for system implementation
Linux-based operating system
Used to collect and analyze data
Used to implement the website of our system
Used to record data
Used to design the user interface
In terms of implementations, first, we will sort out all observed objects to list, then implement a web-based platform. The platform provides promoters to promote IPv6 and DNSSEC easily. Promoters can see the information, including deployment progress of a local government, educational institutions, foundation of government, and some famous website. These information were derived from the system automatically detected. Promoters can understand the progress of their area of responsibility development from these information and as debugging and decision.
4 Experimental result
4.1 DNSSEC deployment status of ccTLDs
This area will hold regular DNSSEC workshops and let domain management unit of countries share experiences and exchange technology. And there is the not-for-profit regional Internet registry for the Asia-Pacific region names APNIC (Asia-Pacific Network Information Centre) which provides number resource allocation and registration services that support the global operation of the Internet.
Including Japan, South Korea, China, and Taiwan, East Asia has a more complete DNSSEC development than the others in the Asia-Pacific region. These countries have more IT industry and better economic development.
On the other hand, many countries in the Southern Asia have not yet begun to deploy DNSSEC because some countries have no funds or resources that can provide construction.
In Europe, the organization responsible for allocating IP addresses is RIPE NCC (Réseaux IP Européens Network Coordination Centre) whose headquarters are in Amsterdam and protected by law in the Netherlands. RIPE NCC is in more than 70 countries worldwide including Russia, the Middle East, and parts of Central Asia; any organizations or individuals can become a member of RIPE NCC.
Because the Internet infrastructure in Europe’s earlier development and national income per capita is higher than others, most countries in this region have completed the deployment of DNSSEC. The countries that have not yet deployed DNSSEC are more concentrated in southern Europe and the Middle East. The reason should be social instability.
Only a few countries with large economies of scale in Americas have completed the deployment of DNSSEC. Several countries of the Caribbean and Latin America have not yet deployed DNSSEC.
There are two organizations responsible for allocating network resources. One is ARIN (American Registry for Internet Numbers), which is responsible for North America and parts of the Caribbean, and the other is LACNIC (Latin American and Caribbean Internet Address Registry) which is responsible for Latin America and parts of the Caribbean.
In Africa, the agency responsible for distribution of network resources is AFRINIC (African Network Information Center).
Because development is lagging behind, only a few large countries have promoted DNSSEC development in Africa.
IPv6 and DNSSEC deployment issues in recent years have been enthusiastically discussed and implemented. Both IPv6 and DNSSEC are indispensable role next-generation systems. For this reason, we introduced related knowledge in the first place and, lastly, proposed an Auxiliary Deployment System for IPv6 and DNSSEC to help our government to more easily promote deployment.
To make the deployment of IPv6 and DNSSEC easier, we designed a web-based system which named Auxiliary Deployment System for IPv6 and DNSSEC for promoters and any person who want to use these. This system is divided into a front-end and a back-end. At the front-end, users can see some information about IPv6 and DNSSEC including news, reports, and various statistics. In addition, users can also detect any domain name to determine whether it supports IPv6 or DNSSEC via complete detection or general detection that the users choose. At the back-end, an admin can manage any services of each organization and carry out some investigation to improve system integrity and understand the needs of users. In addition to interaction with the users, the system also detects a task for service list every hour that is established by our crawler module.
The Auxiliary Deployment System for IPv6 and DNSSEC greatly reduces the complexity of deployment tasks which has many advantages, including a friendly interface, real-time information, integration, security, and free. In the future, we will actively use the system in IPv6 and DNSSEC deployment. Besides the practical application of our system, we will also do data mining of detected records for the associated research.
Hung-Chang Chang received the Ph.D. degrees in Information Management from the National Yunlin University of Science and Technology, Taiwan. He is currently an assistant professor at the Department of Information Management, Shu-Zen Junior College of Medicine and Management, Taiwan. Most of his research areas are information security, software programming, and IoT design.
The author declare that he has no competing interests.
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
- L Smith, I Lipner, Free pool of IPv4 address space depleted, 2011. Number Resource OrganizationGoogle Scholar
- Available Pool of Unallocated IPv4 Internet Addresses Now Completely Emptied, Major Announcement Set on Dwindling Pool of Available IPv4 Internet Addresses https://www.icann.org/en/system/files/press-materials/release-03feb11-en.pdf
- ICANN, nanog mailing list. Five /8s allocated to RIRs – no unallocated IPv4 unicast /8s remain https://books.google.com.tw/books?id=H70iDAAAQBAJ&pg=PA115&lpg=PA115&dq=ICANN,+nanog+mailing+list.+Five+/8s+allocated+to+RIRs+%E2%80%93+no+unallocated+IPv4+unicast+/8s+remain&source=bl&ots=PWlalmdqNd&sig=1rzoAP-4vRgPvkluh-NKDxpeDls&hl=zh-TW&sa=X&ved=0ahUKEwiSrM75-onOAhXImJQKHQucDKkQ6AEILTAC#v=onepage&q=ICANN%2C%20nanog%20mailing%20list.%20Five%20%2F8s%20allocated%20to%20RIRs%20%E2%80%93%20no%20unallocated%20IPv4%20unicast%20%2F8s%20remain&f=false
- Huston, Geoff. "IPv4 Address Report, daily generated". Retrieved 16 January 2011.Two /8s allocated to APNIC from IANA". APNIC. 1 February 2010. Retrieved 3 February 2011.Google Scholar
- APNIC, Two /8s allocated to APNIC from IANA, 2010Google Scholar
- APNIC, APNIC IPv4 address pool reaches final /8, 2011Google Scholar
- ISC: DNS and DNSSEC Terminology (2010). Retrieved 02.15, 2014, from https://dlv.isc.org/about/dnssec_records
- JH-Software: DNS Record types. V52 (2013). Retrieved 02.12, 2014, from http://www.simpledns.com/help/v52/index.html
- R Arends, R Austein, M Larson, D Massey, S Rose, RFC 4034: resource records for the DNS security extensions, 2005Google Scholar
- M Andrews, S Weiler, RFC 4431: the DNSSEC lookaside validation (DLV) DNS resource record, 2006Google Scholar
- B Laurie, G Sisson, R Arends, D Blacka, RFC 5155: DNS security (DNSSEC) hashed authenticated denial of existence, 2008Google Scholar
- Mark Santcroos, Olaf M. Kolkman, “DNS Threat Analysis”, 3 May 2007. Retrieved from NLnet Labs website: http://www.nlnetlabs.nl/downloads/se-consult.pdf
- W-A Chen, The easy security protection and validation system for DNS server using DNSSEC, 2005Google Scholar
- S-H Jang, The study of apply DNSSEC to building a protection mechanism for DNS pharming, 2007Google Scholar
- T Mantoro, SA Norhanipah, AF Bidin, An implementation on domain name system security extensions framework for the support of IPv6 environment”. Multimedia computing and systems (ICMCS), 2011 international conference on, 2011, pp. 1-6–7–9. ISBN 978-1-61284-730-6Google Scholar
- S-J Chu, Lightweight resource record distribution scheme against local DNSSEC attacks, 2011Google Scholar
- C Shu-Lun, Efficient DNSSEC resource record update scheme, 2011Google Scholar
- C Meng-Huan, A DNSSEC-based OpenID service, 2011Google Scholar
- C-C Yu, Authenticating mobile peers in HIP networks with DNSSEC trust chain, 2011Google Scholar
- T Lin, W Liu, H Duan, D Sun, IPv6 traffic hijack test system and defense tools using DNSSEC”. Internet technology and applications (iTAP), 2011 international conference on, 2011, pp. 1-5–16–18. ISBN 978-1-4244-7253-6Google Scholar
- D Migault, S Senecal, S Francfort, E Herbert, M Laurent, PREFETCHing to overcome DNSSEC performance issue on large resolving platform”, in IEEE international conference on trust, security and privacy in computing and communications, vol. 12th, 2013. ISBN: 978-0-7695-5022-0/13Google Scholar