Author: Simla Budhu 

Your website is down. You receive messages like ‘this site cannot be reached’ or ‘domain not found’. You have conducted all the necessary checks: the domain is still registered at the registry-level; the servers are running; and nothing has changed to your mind. Panic sets in and you start calling your internet service provider or domain name registrar. Tempers flare as downtime means loss of money and impairment of brand reputation, both of which are not negotiable in your personal and commercial world, so somebody has to fix this situation quickly or else. Nobody tells you that sometimes the domain exists, everything is working as it should, but the Internet does not trust it. 

This is not a bad thing as you start unpacking the intricacies of domain names and the Internet, and realize that the Internet is not as simple or easy as it’s made out to be. Most users want to type in a domain name and get to a website. But behind the scenes there is a complex registry engine that is designed not just to connect you to the Internet but to verify that connection so that you can be protected within the digital space that you choose to play in. At the heart of the domain name there is a security layer known as DNSSEC-Domain Name System Security Extensions. It’s like a digital verification mechanism that ensures that you visit an authentic website instead of a manipulated or malicious version- all designed to protect you from financial and reputational harm. 

Without going into the technical nitty gritties of DNSSEC as that would boggle the mind, it suffices to say that it is like checking a seal on a package, if the seal is broken or does not match you will not trust that package and the converse is obviously true. In the digital world, the domain is the identity and the DNSSEC is the validation of that identity. Usually the system will say ‘I don’t trust this-block it’ instead of ‘something looks wrong’. Trust has broken and sometimes there is the perception  that the domain does not exist or the site does not exist. Using another analogy, think about arriving at passport control with a valid passport and visa, only to be turned away because the system cannot verify you at that particular moment. You have not ceased to exist. You have just been rejected because the trust anchor has not been satisfied.

Your natural reaction is to renew the domain, restart systems or escalate infrastructure complaints to the techies to fix. The consequences could be delayed recovery as the issue has been misdiagnosed, coupled with unnecessary costs. Upon further interrogation, you realise that you cannot assume that the Internet is binary – it works or it doesn’t. The real effect of broken trust within a DNSSEC root cause analysis is that the Internet just rejects something that is completely valid. Sounds like an anomaly and it is- your domain does not exist but it does!

Again, it bears repetition that this is a trust failure. Like many security systems, DNSSEC introduces many complexities, sensitivities and risks, particularly those that temporarily block legitimate services, create confusion and undermine confidence. Such instances are a global reality as opposed to a rare phenomenon. Even the most mature domain name ecosystems have experienced moments when DNSSEC rollovers have resulted in failed security validation responses; legitimate domain names being rejected; and users experiencing widespread access issues. Not because systems were broken or breached but because the trust chain that is applied within DNSSEC implementations could not be established at that specific moment in time.

Historically, performance standards within the domain name/Internet ecosystem were driven by ‘Is the system running?’, but as the landscape changes and becomes more secure, complex and dependent on layered verification systems, the critical question is ‘whether the system is trusted?’ If you are not trusted then you might as well not exist. Here is the contradiction, registries pride themselves on managing your domain name so that it functions perfectly and is fully operational, but it can still be treated as an alien/foreign element on the Internet. The emphasis has therefore changed – truth is no longer enough, it must be verified, synchronised and trusted everywhere, all at once. But this is not possible. Why?

Domain name and website authentication during a secure validation process  is dependent on everyone in the value chain (registries, registrars, end users) having the same version of the truth at the same time. If some parts of the Internet are ahead or behind then the trust chain is broken. For example, there could be mismatches where new keys are activated before all systems recognise them; caching delays where some networks use old information even after changes have been made; resolver differences which happen when internet service providers use different methods to update or validation the trust anchor; or configuration errors where small mistakes in key set or records can break the chain of trust. So should mayhem and anxiety be the order of the day in such cases? 

No, the right response for a registry is not to create panic but to control what is happening in a responsible and accountable manner. Globally, the accepted approach in these situations is to fix the issue quickly, communicate clearly and proportionately with stakeholders and avoid unnecessary public alarm, especially where no material security or data breach has taken place. This approach ensures operational stability and prevents confusion from spreading faster than the problem itself. 

What can you, as the end user do, when you see ‘the domain/website does not exist’ but you believe that it should be working for all intents and purposes?

Here are a  few  basic things to consider to avoid confusion and frustration:

• Be patient – wait for a short while and try again as the registry and registrar channels are quite adept in managing such incidents, understanding at all times the impact that such disruptions may cause to your business and personal brand.
• Conduct checks from another network or device (e.g. mobile data versus Wi-FI).
• Avoid making changes immediately (like renewing your domain or altering its settings).
• Contact your service provider or IT support if the issue persists for an unusually prolonged period of time and trust that your tech team can identify and resolve complex DNSSEC or other equally complex technical issues.

In a world where trust is becoming increasingly more important than just the technology that supports your personal and commercial digital brand, not every failure means that something is broken. Sometimes, it is just a simple indication that the Internet/domain name systems need more time to recalibrate and understanding this can be the difference between panic and patience; and between confusion and clarity.