Most of the internet’s rules are published as RFCs, short for Requests for Comments: open documents anyone can read, written and reviewed by the people who build the network. Other rules are not written anywhere. They are about how operators treat each other, and they matter just as much. Below are both kinds, grouped by what they protect. Each item links to the document it comes from, where there is one.
Integrity and ethics
Everything else on this page rests on a simple idea: rules mean something only when the people who publish them keep them. We do not ask anyone to behave in a way we would not behave ourselves.
In everything the administrators run, we stay within the law and common ethical norms. We do not send mail nobody asked for, do not deceive, do not collect what we do not need and do not cut corners at someone else’s expense. We stand against violations wherever we meet them, on our network and beyond it.
What we cannot do is take responsibility for third parties. Projects on our network are run by their owners, and each owner answers for what they publish and do. Our responsibility is to react: to check credible reports, to ask owners to fix problems, and to restrict access when that is needed.
- We keep the rules we ask others to keep
- Violations are not tolerated on our network, whoever commits them
- Owners answer for their own projects; we act on reports about them, as described on the Abuse and Legal pages
- This site describes only what we actually do, see What we do not claim
Good conduct on a shared network
Nobody owns the internet as a whole. Tens of thousands of independent networks carry each other’s traffic, and the whole thing holds together because their operators can find each other and act on what they are told. The abuse mailbox is where that happens.
A network that ignores its mail becomes a safe place for spammers and attackers. Others notice, and they start blocking it, often including the innocent projects that share its addresses. Being reachable and responsive protects the people we host as much as it protects everyone else.
- The role addresses that internet standards expect for a domain exist, and a person reads themRFC 2142RFC 5321
- A security contact is published at the standard locationRFC 9116
- Reports are acted on, whoever the project belongs to, as described on the Abuse page
- Vulnerabilities are fixed before they are made public, together with whoever found them
- Automated abuse reports are accepted in the standard formatRFC 5965
Privacy
Privacy is usually discussed as a matter of rules and consent. For the people who run the systems it is first of all a matter of design: data that is never collected cannot leak, cannot be sold and cannot be demanded by anyone.
It also matters for trust. People write to abuse@ about things that harm them, and they should not have to worry about what happens to their message.
- Nothing about anyone is collected without asking; the one exception is the standard web server logPrivacy
- No cookies, no tracking scripts and no advertising on our sites, and so no cookie banners
- Fonts, images and scripts are served from our own servers, so no third party learns about a visit
- Reporters can ask for their name to stay out of what we pass on
- Every connection is encrypted, see Encryption
- Data about people is never sold or traded
Protection from spam and forgery
Email was designed in a friendlier era: the original protocol lets anyone claim to be anyone. Most of the mail sent in the world today is spam, and phishing works because a forged sender still looks real to most people.
The fix is a set of standards that let a receiving server check where a message really came from. They only help when senders publish them and keep them correct, which is why we treat them as a duty rather than an option. The other half of the duty is simple: nothing we run should send mail that nobody asked for.
- SPF publishes which servers may send mail for our domainsRFC 7208
- DKIM signs outgoing mail, so a message altered on the way fails the checkRFC 6376
- DMARC tells receivers what to do when both checks fail, and sends us reports we readRFC 7489
- Domains that never send mail say so explicitly, so nobody can send in their nameRFC 7505
- Servers that send mail have reverse DNS that matches their forward DNS
- No open relays: our mail servers carry mail only for those they serveRFC 5321
- No newsletters, no marketing mail, no bought address lists
Encryption
A message on the internet passes through many hands: the local network, the provider, exchange points, other providers. Without encryption, any of them can read it or change it, and it takes no special skill. With encryption, they can see that a connection exists and little else.
Encryption also answers a question people rarely ask out loud: is this site really the one I meant to visit? A valid certificate says yes. That is why we do not limit HTTPS to login pages: every page and every file is served encrypted.
- HTTPS only; plain HTTP requests are redirectedRFC 9110
- TLS 1.2 and 1.3 only; the older versions are retiredRFC 8446RFC 8996
- HSTS tells browsers never to fall back to plain HTTPRFC 6797
- Certificates are issued and renewed automatically, and every renewal is watchedRFC 8555
- CAA records name the only certificate authorities allowed to issue for our domainsRFC 8659
- HTTP/2 over TLS for the webRFC 9113
- Mail between servers is encrypted whenever the other side supports itRFC 3207
IPv6 everywhere
IPv4 has about four billion addresses, and they ran out years ago. Networks that still grow on IPv4 do it by hiding many users behind one address, which makes connections slower, harder to trace when something goes wrong and harder to make direct. IPv6 has enough addresses for every device, and a large share of traffic, above all on mobile networks, already uses it.
A service that speaks only IPv4 forces those users through translation layers. We would rather meet them directly. For us, IPv6 is part of every new service from the first day, not a feature added later.
- New services are planned for IPv6 from day one, alongside IPv4RFC 8200
- Reverse DNS is set up for IPv6 addresses too
- Mail authentication lists IPv6 addresses next to IPv4 onesRFC 7208
- IPv6 gets the same attention as IPv4; it is not a fallback
Names and DNS
Names are the part of the internet people actually see. A wrong record sends visitors to the wrong place; a forgotten one can be taken over by someone else and used against the people who trust the name. DNS is where ethdns started, and it still gets our particular attention.
- Records that are no longer needed are removed, not left pointing at addresses that may change hands
- A reverse name under ethdns.com is used only on hosts that are really ours
- CAA records limit who may issue certificates for our namesRFC 8659
What we do not claim
We follow these standards because they make the network better, not to collect badges. ethdns holds no certifications and does not claim formal compliance with any regulation. This page describes how we work; it is not a legal promise. If you notice that we fall short of anything written here, tell us at noc@ethdns.com.
Check this site yourself, as it is served right now: its TLS setup at Qualys SSL Labs, its security headers at Mozilla HTTP Observatory and its HTML at the W3C validator.
Last updated 1 October 2026.