Hosting Details

Expert Tools

About This Project

Hosting Details started as a shortcut for one person's working day, and it still shows in what the tools do and what they leave out.

It started with phone calls

I have spent more than a decade working in domain names, hosting, e-mail, and the security around all three. A large part of that job is the same conversation, over and over: somebody gets in touch with a question about a domain, and before anything useful can be said, the situation has to be worked out first.

Is the domain registered with us or somewhere else? Does it belong to the person calling, to another customer, or to a reseller sitting in between? And separately from all of that: where is the hosting, and where does the mail actually go? Those are four different answers that live in four different places, and none of them is guaranteed to match the others.

Looking that up in a customer portal works, but it takes time, and it only ever covers the domains that are ours to begin with. For everything else, the answer lived on the open internet, scattered across a handful of separate lookup sites.

Six tabs and a lot of waiting

Getting the picture that the homepage now shows in one view used to take six to eight different websites. One for WHOIS, another for RDAP, one for DNS records, one for the certificate, one for the IP and its network, another for DNSSEC. Each with its own layout, its own idea of what mattered, and its own loading time, some of them noticeably slow.

None of that was hard. It was just repetitive, and repetitive with a customer waiting on the other end of the line. So the first version of this site was one page that asked all those questions at once and put the answers next to each other, as quick as possible. That is still the whole idea behind the homepage.

Growing past the original itch

Once the basics were in place, the tools that came after were built for the same reason, and mostly still for my own use. The DNS Lookup Tool exists because a summary is not always enough and sometimes you want to see the raw records the way dig would show them, against a resolver of your choosing. The Security Scanner exists because "is the mail set up properly" turns out to be five separate questions.

The Expert Tools subdomain went further in the same direction. Each protocol check there digs deeper than a pass or fail: DANE, MTA-STS, CAA and the rest come with an explanation of what the records mean and why the answer is what it is, because the check is only half the value if you still cannot act on it.

So the honest summary is that this site does more than the alternatives in the places where I needed more, and deliberately does nothing at all in the places where I did not. It is not trying to be a complete replacement for every lookup service out there.

For expert.hostingdetails.eu, though, that story is slightly different. I wanted tools that actually help when you use them, not tools that require you to dive into your own DNS, find the record, and then watch the tool echo back what you just read. So I added the logic from my years on the job, turned things over, and reversed the way of thinking in a few places, and found solutions that actually work.

From that, the decision to make every check and wizard on that subdomain fully RFC-compliant followed naturally. If you're trying to help people with things that are genuinely hard, and trying to do it better than the alternatives, you might as well make sure your answers are as good as they can be.

What "RFC-compliant" actually turned into

Saying a check is RFC-compliant is easy. Making it true is a different amount of work, and it only really started once every check was already explaining what it found and why - because at that point, a quieter question followed: was the explanation itself correct? Not "close enough for a quick look", but actually correct, against whichever specification defines that protocol.

That gap shows up in specific, findable ways once you go looking for it. A check that reports "SPF looks fine" without ever counting DNS lookups against RFC 7208's own ten-lookup limit isn't wrong exactly, it's just not testing the thing that actually breaks mail delivery in practice. Once that kind of gap was visible in one place, it was visible everywhere, and the only honest response was to go back through every check, one specification at a time, and make sure it tested what the RFC actually requires, not what seemed reasonable at a glance.

Every page on expert.hostingdetails.eu now names, at the bottom of its own explanation, exactly which specification it follows:

Mail authentication

Mail transport security

DNS and certificates

Website security

A handful of other headers - Content-Security-Policy and Permissions-Policy among them - come from W3C and WHATWG specifications rather than an RFC; the headers page itself names each one against its actual source.

Not every one of the above is an RFC in the strict sense, either. BIMI has never been published as one - it follows an ongoing IETF Internet-Draft instead, revised roughly every six months, and its own page names that plainly rather than borrowing an RFC label it hasn't earned. Naming the actual source seemed more honest than forcing everything into one tidy word.

What that means for how it is built

This is a solo project, built and maintained alongside a full-time job, which shapes almost every technical decision on it. There are no third-party PHP libraries, no tracking or analytics, no advertising, and no account to create. The fonts are served from this server rather than someone else's, and the DNS resolver was written from scratch instead of wrapped around an external service. Every feature has to earn its place, because every feature also has to be maintained.

Next to nothing you look up is stored, and nothing is sold. That is set out properly in the Privacy Policy, and what each tool actually does is covered in How It Works.

If the site is useful to you the way it is useful to me, that is the best outcome it can have.