Categories
Deploy360 IPv6

LinkedIn Passes Another IPv6 Milestone

Yesterday, LinkedIn announced that, “Earlier this month, and for the first time in our company’s history, more than 50% of pages on LinkedIn were accessed over IPv6 from mobile devices in the U.S.” This is great news and further proof that IPv6 is the new normal.

LinkedIn has been a trailblazer in IPv6 for many years, participating in World IPv6 Launch and regularly informing their community about the progress they’re making through the engineering blog. We’ve been writing about their efforts since 2014. Yesterday’s blog post from Franck Martin elaborates on LinkedIn’s history with IPv6 and its future plans, stating:

“Since we enabled IPv6 on our mail servers in 2013 and then on our web site in 2014, we have seen increased growth of our external IPv6 traffic. We are currently working on enabling IPv6 on our all of our internal networks and applications in order to begin removing IPv4 internally, beginning in 2018. The external network and public services will still support IPv4 (for compatibility with legacy clients) for years to come, but we anticipate the proportion of our external traffic served over IPv6 to only increase. The community has seen tangible benefits from serving content over IPv6 compared to IPv4. We, too, see some performance improvements on IPv6.”

This is another milestone in the road to full IPv6 deployment, and we applaud LinkedIn’s efforts to date.

Are you ready to get started? Deploy360 aims to help networks of all sizes on their path to IPv6 deployment, so please take a look at our Start Here page to learn more.

Categories
Deploy360 IPv6

Uber Goes IPv6 to Support its Growing Infrastructure

Uber recently announced it’s deploying IPv6. The company has made the decision to deploy IPv6 to support the company’s growing infrastructure, as explained in the engineering team’s announcement where they detail three major areas of infrastructure they need to update – network architecture, software support, and vendor support.

From the post:

“Three key factors made it clear to us that deploying IPv6 across our networks was going to be critical for maintaining our architecture’s stability at scale:

  • Generous IP allocation: The size of our network has grown rapidly over the past few years, supporting thousands of server racks in our data centers. Each rack is allocated a /24 IPv4 subnet out of our Request for Comment (RFC) 1918 IP space, which includes 256 IPv4 addresses per rack. In most of our rack deployments, we host no more than 48 servers.
  • Resource limitation: At this stage in our growth, we have used more than 50 percent of our 10.0.0.0/8 IPv4 subnet for internal usage. If we do not transition to IPv6, it is possible that our RFC1918 (the Internet Engineering Task Force (IETF) memorandum on methods of assigning of private IP addresses) space could be exhausted in the foreseeable future.
  • Overlapping IP addresses: Traditionally, Uber’s networks defined their own IP addresses for their resources. When Uber began merging with other companies, some IPv4 addresses overlapped between two internal networks of different organizations.”

The post explains in some detail how they’re working to update their network architecture including hardware, automation, and network design; updating vast amounts of code through collaborative teamwork; and working with vendors to ensure IPv6 support across the board.

Kudos to Uber for managing this transition and sharing their experiences with others!

If you are ready to get started with IPv6, visit our START HERE page for more information. Looking for something that isn’t there? Contact us! We’re here to help!

Also, in case you missed it yesterday, there’s a new State of IPv6 Deployment report out with tons of statistics, insights, and recommendations. It might be the perfect tool to help you make the case for IPv6 if you’ve been struggling to get the go-ahead.

Categories
Deploy360 Events

Other IPv6 Stuff at APRICOT 2017

We already covered the IPv6 Deployment session during APRICOT 2017, but there were several other IPv6-related sessions that are worth mentioning.

First thing to mention is that there was a tutorial on deployment of IPv6 in a production mobile network. This was a 1.5-hour session led by Jeff Schmidt (Telstra) and provided some insights into what the business and technical considerations were, and what ended-up actually being deployed on their network.

Jon Brewer (NSRC) is someone who always managed to conjure up interesting talks at APRICOT Conferences, and his tutorial on the Internet-of-Things was no exception. Whilst IoT is not specifically IPv6, it’s likely that IPv6 will be required to facilitate the plethora of devices expected in future.

This tutorial discussed core concepts and the types of applications that are enabled by IoT technologies, before covering radio and network protocols for low-power WANs such as the 802 series, 3GPP and LoRaWAN. Higher-level protocols used in IoT are also discussed including CoAP, MQTT, REST and Websockets.

On a related note, there was also a presentation by Jeff Apcar (Cisco) on the Low Power Wide Area (LPWA). This covered this new area of communications where networks of sensors with limited power availability need to be connected across both urban and rural areas; some over long range wireless networks with substantial RF interference.

Last, but not least, there was the IPv6 Readiness Measurement session. This is an initiative of TWNIC (the Taiwan National Internet Registry) aims to encourage organisations working on IPv6 deployment to share their IPv6 measurement methods and results.

The IPv6 situation in India as presented by Ajai Kumar (NIXI) is becoming interesting, with different measurements calculating IPv6 deployment somewhere between 20 and 40% which makes India the economy with the highest rate of deployment in the Asia-Pacific region. Even more encouragingly, some large organisations including the State Bank of India have even higher rates of deployment, most of the major IXPs are IPv6-enabled, whilst the .in ccTLD also support IPv6.

The Asia-Pacific economy with the second-highest level of IPv6 deployment is Japan, whose situation was presented by Tomohiro Fujisaki (NTT). IPv6 deployment continues to increase and currently sits somewhere just over 20%. However, three major cellular operators have announced they will commence IPv6 services in 2017, whilst a number of fixed-line ISPs have already started to offer commercial ISP services. Some government services are now available via IPv6, although support by the major Japanese content providers still needs to improve.

Things are a bit less positive in Korea, Taiwan and Vietnam, although there was substantial progress with IPv6 deployment in Vietnam during 2016, with FPT Telecom becoming the first ISP in the country to offer IPv6 to customers (which we previously discussed). The Taiwanese government has also deployed IPv6 in most of its agencies, has started to offer IPv6 on its public Wi-Fi service (iTaiwan), whilst around 20% of the traffic of TANet (the NREN) is using IPv6.

One of the reasons for limited IPv6 uptake in Korea appears because it has one of the highest user bases in the world, and therefore obtained a large amount of IPv4 resources early on. IPv6 deployment only really started 3 years ago, and then mostly on cellular networks, so that combined with the lack of local content available via IPv6 has provided limited incentives for ISPs to provide this to their customers.

However, regardless of where you are, we encourage you to consider deploying IPv6, so please check our Start Here page for more information!

Categories
Deploy360 Events

NAT64check & More IPv6 @ APRICOT 2017

Some of the Deploy360 team were presenting at APRICOT 2017 last week, and there were other interesting presentations that are worth highlighting. Whilst we’ll cover the dedicated session on IPv6 deployment in this post, we’ll also do a round-up of some of the other IPv6-relevant presentations and tutorials in subsequent posts.

Our colleague Jan Žorž had been asked to chair the APNIC Executive Committee election process, so it meant a mad dash from there to open the IPv6 deployment session with his presentation on the NAT64/DNS64 testing being undertaken by the Go6lab. This debuted at AfriNIC-25 towards the end of last year, but NAT64check has already proved to be an extremely useful tool.

As many mobile operators are moving to IPv6 only which is incompatible with IPv4 on the wire, it’s necessary to employ transition mechanisms such as 464XLAT or NAT64. The NAT64check testbed was therefore developed by Go6lab and SJM Steffann with support from the Internet Society so that operators, service providers, and hardware and software vendors can see how their networks and systems work in these environments.

When using NAT64 there are many things that need to be checked to ensure they work correctly, so NAT64check was developed so that websites can be checked for consistency over IPv4, IPv6-only and NAT64, as well to compare responsiveness using the different protocols. This allows network and system administrators to easily identify anything is ‘broken’ and to pinpoint where the problems are occurring, thus allowing any non-IPv6 compatible elements on the website to be fixed.

If you go to the NAT64check website, you can find a list of which websites that users have checked, and how they display using the different protocols. The tool does a comparison of the images returned, and attempts to identify any broken elements, along with providing information on the responsiveness of the respective connections. And one interesting observation that seems to backup those by APNIC Labs, is that IPv6 connections are typically more responsive if they can be established in the first place. Further evidence that IPv6 does not result in a degraded experience if set-up correctly.

This was followed by a presentation from Abdul Awal (BDREN) on IPv6 deployment in BDREN, the Bangladesh National Research and Education Network, as well as the wider challenges of deploying IPv6 in Bangladesh. There is not currently much deployment of IPv6 in the country, and this has not been helped by a lack of support for AAAA glue records in the .bd ccTLD. However, BDREN has been leading the IPv6 deployment efforts having implemented dual-stack in 2016, and is currently promoting IPv6 on its connected campuses. As a result, the websites of some universities and educational institutes are now available via IPv6, and dual-stack has been enabled at one campus.

More generally, some of the ISPs in Bangladesh had enabled IPv6 on their backbones, but are still not providing IPv6 to their end users citing a lack of demand. It needs impetus from another direction, and whilst directives existed from the Bangladesh Telecommunications Regulatory Commission (BTRC), the government could help by mandating the use of IPv6 in their e-governance platforms, when procuring IT systems, and by establishing a National IPv6 Task Force to help raise awareness and push deployment of IPv6.

Sami Salih (Al Jouf University) then presented IPv6 developments in Sudan and on SudREN, the national research and education network. Sudan had a national IPv6 migration plan and 26 training workshops involving more than 1,000 participants had been organised between 2011 and 2015, as well the SDv6 Task Force being formed. Twelve /32s have been allocated to Sudan by AfriNIC.

SudREN is also leading the IPv6 deployment initiative and has enabled IPv6 on 50% of the core routers, 10% of the routers of their member institutions, and on 100% of all servers. There is a native IPv6 link to the rest of the Internet via Sudatel, with a backup link via Hurricane Electric. Every member institute has been allocated a /48 with a /4o reserved for future demand, which means that SudREN had now assigned 80% of its two /32 blocks. As a result, more than 25% of SudREN are now IPv6 capable, which compares very favourably to other parts of the world.

Rounding off the session was Dat Nguyen Thanh (FPT Telecom) who provided a commercial perspective on IPv6 deployment at FPT. FPT is one of the major ISPs in Vietnam and Cambodia with over 1.6 million subscribers, and has been rolling out IPv6 in its core network. Over half their subscribers are now IPv6 enabled and total traffic amounted to 477 Gb/s, and their method for rolling out IPv6 on CPEs was discussed in detail.

This is a session worth following, and if you missed it live, it’s available on YouTube to watch.

If this inspires you to transition your networks, devices and applications to IPv6, then please see our Start Here page for more information!

Categories
Deploy360 IPv6

The Business Case for IPv6 in Pakistan

We had a very successful ION conference in Islamabad on 25 January 2017, and amongst the interesting topics presented at the conference, it’s worth highlighting the statistics on IPv4 and IPv6 allocation in Pakistan. Let me share those in detail here.

As per the APNIC resource delegation data (as of 1 January 2017). There are 5,314,816 IPv4 address allocated to ISPs and enterprises in Pakistan. However, if you look at the graph then it shows PTCL as the holder of nearly 73% IPv4 addresses in Pakistan, leaving the remaining 27% to the rest of the ISPs and enterprises. PTCL is undoubtedly the biggest broadband provider in Pakistan and also provides services to Ufone (telco operator), so you’d expect them to have the largest user base for both wired and mobile broadband services.

The main concern though, is that it’s now only possible to obtain a /22 IPv4 prefix from APNIC (as per the last /8 policy), and those will soon be exhausted. This means that if ISPs need more IPv4 address, the only option will be to buy them open market. The current going rate for IPv4 addresses is around USD 10 for each address  in a /18 block, plus the APNIC transfer fees, which amounts to nearly USD 164K for 16,384 IPv4 addresses.

The other option is deploying Carrier Grade NAT (CGN) to put many users behind a single IPv4 address.In theory, it’s safe to consider that each user may have around 250 concurrent sessions, so with around 65,000 sessions available per IP address, it’s possible to put 250 users behind a single IPv4 address with CGN. The downside though, are that you need powerful boxes to manage that many sessions and it is difficult to guarantee performance.

There’s another graph showing IPv6 delegations in Pakistan, with a very uniform address allocation to all existing APNIC members (with few negligible exceptions). No single entity has an edge over another, and it doesn’t cost anything extra (if you already hold IPv4 addresses) to obtain IPv6 addresses from APNIC. There’s no need to install complex and difficult to manage CGN solutions, nor buy expensive IPv4 addresses from the open market. It’s an open and level playing field for all operators wanting to serve the 200 million plus population of Pakistan.

For many years there was a big debate in Pakistan about the financial benefit of deploying IPv6, but these statistics clearly illustrate the business case for doing it. You can either deploy IPv6 at minimal cost by upgrading some old hardware (very rare), or deploy CGN and buy IPv4 from open market at significant expense. The choice is yours!

Deploy360 aims to help you deploy IPv6, so please take a look at our Start Here page to understand how you can get started with IPv6.

Categories
Deploy360 IPv6

Microsoft moves to IPv6 only internally

There’s an interesting post on the RIPE Labs discussing how Microsoft is moving to IPv6 only on its internal network. Marcus Keane presented their experiences during RIPE 73, and we also gave that some coverage on Deploy360, but this expands a bit more on their motivations for doing so.

The primary reason is of course the exhaustion of public IPv4 space, but with a large corporate network spread over more than 100 countries, they’re also running out of private IPv4 address space. Whilst operating multiple NATs might temporarily relieve the situation, this is becoming more difficult to manage and the problem has been exacerbated by the acquisition of other companies with their own NATs, plus the expansion of the Azure cloud computing service.

Dual-stack also only partially addresses the problem as not only are IPv4 addresses still required, but this doubles the complexity of designing their network and dealing with issues when they arise. As a result, Microsoft have been experimenting with IPv6-only networks for the past couple of years, and have now started to deploy this on their production networks.

By focusing initially on the guest network, this minimises the risk to existing and possibly more critical systems, and provides more flexibility for changing things if necessary. It’s interesting that some of the deployment issues encountered were due to DHCPv6 bug in Windows 10, plus the need to support Android devices which doesn’t support DHCPv6. Another interesting issue is that whilst Azure Active Directory can be used to authenticate users, the ACLs on the wireless controllers do not currently support IPv6, although this is in the process of being added.

Nevertheless, the article provides an interesting case study on how a large enterprise clearly understands the necessity of deploying IPv6, and is actively taking steps to implement IPv6 in a production environment.

More Information:

Deploy360 also aims to help this process, so please take a look at our Start Here page to understand how you can get started with IPv6.

 

Categories
Deploy360 IPv6

IPv6 inside LinkedIn

There’s a series of interesting articles authored by Franck Martin and Tim Crofts about how LinkedIn has enabled IPv6 and the issues they’ve encountered. LinkedIn has been running IPv6 since 2014, but this year they decided to test what happens with an IPv6-only network instead of a dual-stack one.

The first article commissioned for the anniversary of World IPv6 Launch explains why LinkedIn decided to move their internal network over to IPv6.

In the second article, they describe the challenges of enabling dual stack in their data centres, and they went about configuring their systems to work with IPv6.

The latest article covers their progress towards an IPv6-only data centre, and the issues and challenges they’ve had with installing, configuring and managing servers and software tools in this environment. Although they’re not currently running an IPv6-only data centre, they are currently working towards the goal of removing IPv4 completely in order to simplify management of their systems and network.

More Information:

Well worth reading and more evidence of how major service providers are actively making the transition to IPv6.

Deploy360 also aims to help with this, so please take a look at our Start Here page to understand how you can get started with IPv6.

Categories
Deploy360 IPv6

Liquid Telecom deploys IPv6 in Africa

liquid-telecomWe recently received good news from Liquid Telecom who have implemented native IPv6 in Kenya and Zimbabwe and are actively using it. This was the next phase after their smaller rollout in Kenya undertaken only a few weeks ago. Others talk about being IPv6 ready, but they’ve proudly gone to being truly IPv6 active.

As Andrew Alston, the main architect behind this achievement said to the African Network Operators Group (AfNOG) – “the philosophy behind this shift was that others worry about an IPv4 soft landing, but we deploy IPv6 and ensure we’re ready for the inevitable“.

TwitAt the beginning of this year, Jan Žorž from the Deploy360 team held an advanced workshop on IPv6 security at the Liquid Telecom Kenya headquarters in Nairobi for their networking team, that demonstrated a great interest for the topic along with many questions asked about the particular issues. Our suspicion was that the time had nearly come for deployment and we’re very pleased and proud of Andrew, Chris Mwangi, Anthony Somerset and their excellent team, for Liquid Telecom who are setting a new pace for IPv6 uptake, and for the African continent.

Work is also ongoing on the Liquid Telecom’s FTTH network in Zambia, and we’re looking forward to hearing about the progress. If you look at their network map of Africa, there might be a lot more IPv6 coming.

What can be added? Well done and please continue the path that you have started to take, setting the direction for other network operators to follow. Not deploying IPv6 is just postponing the inevitable.

Please stay tuned for Andrew Alston’s more detailed blog post on the Deploy360 website where he’ll be explain the reasons behind this move, issues they encountered and how they fixed them, along with lessons learned and where they’re heading next.

Jan Žorž

Categories
Deploy360 IPv6

Why you need IPv6 and the sad tale of an ISP that didn’t deploy it

IPv6-imageWe’ve recently come across a couple of videos about IPv6 that we think are worth sharing.

The first comes from Ethan Banks of Packet Pushers who makes the case for why you finally really do need IPv6. Here he argues that where IPv6 is not deployed, it’s starting to have a real business impact in a number of regional markets. As IPv4 reaches a stage of imminent exhaustion, it’s becoming necessary to buy address space at a significant cost, or use multiple layers of Network Address Translation that degrade performance and break applications.

In many cases, users already have IPv6 capability as many mobile operators have been deploying IPv6 for a while, whilst other ISPs particularly in US but also parts of Europe, are also rolling it out. Many operating systems including Windows, even prefer using IPv6 for transport, so there no reason not to support IPv6 on your web sites and other services. Indeed, you’re increasingly likely to be cutting off potential users if you don’t.

Conversely, take a look at the sad tale of an ISP that didn’t deploy IPv6 that was produced by the University of Guadalajara for LACNIC 23. This relates the tale of a large incumbent ISP that decided not to deploy IPv6 whilst a smaller one did. The result is that it loses customers be cause it no longer has sufficient IPv4 addresses, it cannot participate in state tenders that require IPv6 to be supported, and eventually its engineers and then sales team leave for the smaller ISP. Whilst real names have not been used in the video, it’s purportedly based on a true story and should therefore serve as a cautionary tale.

One more video to view if you’re interested in deploying IPv6 is Clinton Work’s presentation at NANOG 65 on deploying IPv6 at scale. Here he presents TELUS’s experiences of planning and deploying IPv6, the technical and training challenges, and their reasons for doing it.

We at Deploy360 want to support those interested in deploying IPv6, so please take a look at our Start Here page to understand how you can get started.

 

Categories
Deploy360 IPv6

Sky Broadband now IPv6 enabled for 90% of customers

skyThe good news in the IPv6 world continues with Sky Broadband announcing that over 90% of its customers are now IPv6 enabled. Sky Broadband is the second-largest UK Internet Service Provider with an estimated 6 million residential subscribers, and once its rollout on home CPEs (Consumer Premises Equipment) is completed at the end of 2016, IPv6 will be available to all customers with the exception of those using older non-compliant equipment.

IPv6 connectivity is being provided as dual stack alongside existing IPv4 connectivity, with link-local WAN addressing and each subscriber being provided with a /56 address prefix. The Sky software also supports a stateful IPv6 firewall.

In a related presentation at NLNOG last week, Richard Patterson of Sky Broadband discussed the lessons learned from rolling out IPv6.

The deployment started at the end of July 2015 and was gradually ramped up until September that year, when there was a pause for six months to ensure their RADIUS authentication and recursive DNS systems were scalable, and to evaluate unexpected behaviour encountered from some end client operating systems. The deployments resumed earlier this year once the issues had been ironed out, although these issues were more due to the loads on supporting systems rather than connectivity failures.

Another positive to be drawn is that when Sky Broadband experienced a widespread network outage last month, this affected IPv4 but not IPv6 connectivity, demonstrating how dual stack networking is able to function seamlessly.

At Deploy360 we’d like to help you take advantage of IPv6, so please take a look at our Start Here page to understand how you can get started.

 

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC)

DNSSEC Algorithm Roll-over

ripelabs_128RIPE Labs have just published an interesting article about their experiences of rolling over the algorithm used to sign a DNSSEC zone. The RIPE NCC was one of the first organisations to sign its zones with DNSSEC which meant using RSA/SHA1 as this was the only defined algorithm at the time.

In recent years it’s been demonstrated that SHA1 has certain vulnerabilities which is why RFC 5072 standardised the use of SHA2, even though many validators did not support it at the time. Since then, SHA2 has has become better supported by validators, and this combined with the fact that the root zone is now signed with SHA2, was the reason for the RIPE NCC to roll over the ‘ripe.net’ domain to the stronger algorithm.

This proved less than straightforward as firstly their original signer software could only sign the zone with either SHA1 or SHA2 but not both. A new version of the signer was therefore required, but after setting up a test system and introducing SHA2, it became apparent that BIND and Google DNS were able to validate the zone, whereas Unbound and Verisign DNS did not.

Further investigation traced this to the use of separate Zone Signing Keys (ZSKs) and Key Signing Keys (KSKs) and expectation of some validators that the algorithm signalled by the Delegation Signer (DS) record is used to sign all records in the zone. This is a more strict interpretation of RFC 6840, and whilst the latest version Unbound does now have an option to relax this validation requirement, implementors should be aware of this issue.

The recommendation of RIPE Labs is that the KSK and ZSK should be rolled at the same time, and the old ZSK should not be withdrawn until the KSK roll-over is complete. NLnet Labs have also published an article on rolling DNSSEC algorithms on OpenDNSSEC as the current version of OpenDNSSEC does not directly support this.

References

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC) Tutorials

Case Study: The Experience of Signing Go6.SI with DNSSEC

Some time ago Matthijs Mekking, one of the authors, maintainers and coders for the OpenDNSSEC project asked me why go6.si domain was not signed. My answer was that I need a short, precise and deployment/operations-oriented document with clearly described steps on how to setup the signing platform, how to add a zone and sign it.

Matthijs accepted the challenge and soon we got the first draft of the document to Go6lab. There were some errors in the procedure, so together we fixed them. Matthijs added some more information that he saw as needed for better understanding and re-tested the procedure again – and this time it worked. After some cycling through the Linux distributions we found that using Fedora and installing OpenDNSSEC from their repository usually brings you the latest version of the code – and the issue that we found in first round of testing was fixed in new version (the issue was that if you had OpenDNSSEC signer as “bump in a wire” between silent primary and secondaries that served the signed zone – signer did not understand “NOTIFY” message from primary and did not transfer new zone for signing).

opendnssec_logo_120We decided to install OpenDNSSEC signer as “bump in a wire”, fetching the unsigned zones from the “silent” primary server, where we edit and change the zones (with notify to signer), sign the zones on signer server and push them over AXFR to two secondary servers that acts like primary and secondary DNS for that zone. Seems easy – and it is, in a way 🙂

The “silent” primary server runs on PowerDNS with a mysql database backend. The two secondary servers that are serving the signed zones are both running bind9.

At first glance all worked fine, following the deployment guide we added go6.si, go6lab.si and zorz.si zones for signing (zorz.si was a test “mule” to see if the process works). The signer got the zones, signed them and pushed them to both name servers nsec1.go6lab.si and nsec2.go6lab.si. Our .si TLD dnsmaster Benjamin Zwittnig inserted for us DS records in .si zone and the whole thing started to work. We are pressing now our registrar to implement the tool to insert DS records to .si zone without bothering Benjamin.  Hopefully this happens soon.

So, with DS records in parent zone we were able to test the whole thing and all was fine… until I stopped changing the zones and the primary server did not send any NOTIFY to signer server that there is a change in the zone for some time. And that “some time” was exactly the time that was set for a zone to expire. What happened was that signer server realized that the zone expired and instead of asking his primary name server for retransmit (AXFR) – the server expired the zone and stopped serving it.

So, zorz.si was off-the-Internet for 20 minutes!  When my monitoring system alerted me that there is something wrong with DNS responses for that domain, I immediately figured out that signer expired the domain without refreshing it at the primary server.

As I needed to solve this issue quickly I created cronjob that forces a NOTIFY for all signed domains on hidden primary server every day at midnight – and so domains never expires on signer server. I also reported this bug to Matthijs and I think that the fix will be done in next release of the software.

It’s good to have a real environment where we can test and stress-out these new tools that are making the Internet a safer place – and also make these tools better with finding bugs before they hit somebody else in a big production environment.

You can now download the latest draft of Matthijs’ opendnssec-start-guide document that I used to set up the whole thing. Please note – it’s a draft, so all comments, suggestions and ideas are more than welcome.

screen-capture-278How did we test if our DNSSEC signing was correct and valid? We used three tools:

… but there are many others out there, described at our DNSEC Tools page.

P.S. If you would like to get started with DNSSEC, please visit our Start Here page to find resources tailored for your type of organization or role.