DNS and domain foundations

The part many people forgot

DNS is one of the oldest foundations of the internet and still one of the most important. When DNS is wrong, everything above it becomes fragile. When DNS is right, mail, web and identity services have firm ground to stand on.

A name points to a machine. Mail records direct delivery. Certificates prove service identity. Reverse records give addresses names. Policy records define trust and reporting.

Hardware, operating systems, routing, mail, DNS, certificates, logs and firewalls are not separate mysteries. They are parts of the same machine.

[image placeholder: simple DNS tree / domain roots]

ZeroDNS, PowerDNS and the way out

ZeroDNS exists because domains need clean foundations for DNS, mail, routing and practical control. PowerDNS provides open authoritative DNS without forcing customers to live forever inside rented control panels.

dns.he.net and Hurricane Electric Tunnelbroker are useful stepping stones for DNS hosting, IPv6 learning and migration work.

The aim is portability and clarity: know who controls the domain, where DNS lives, how mail is proved, and how certificates renew.

[image placeholder: open gate / exportable zone file]

Forward names and reverse names

Forward DNS says a name points to an address. Reverse DNS says an address belongs to a name. With both planned properly, logs are readable, monitoring is clearer, and support work becomes faster.

With IPv6, routed endpoints can have proper names and reverse records, protected by firewall policy rather than hidden behind translation layers.

[image placeholder: forward/reverse arrow diagram]

Mail records are trust records

Good mail starts in DNS: MX, SPF, DKIM and DMARC first, then stronger controls such as MTA-STS, TLS reporting, correct hostnames and clean reverse DNS.

SPF lists senders. DKIM signs content. DMARC sets failure policy. MTA-STS enforces encrypted transport policy. TLS reports show delivery security faults.

[image placeholder: signed mail envelope + shield]

Certificates and quiet trust

Certificate work should feel simple for customers but involves careful DNS/web challenges, renewal timing, service reloads and failure monitoring.

Names must match real use, renewals must happen before expiry, and failures must be seen before users see them.

[image placeholder: certificate stamp / lock / calendar]

BreathGSLB and keeping services reachable

Some services should not rely on one road. Global server load balancing lets DNS direct users to healthy paths and failover routes when needed.

For small systems this can stay simple. For larger estates it can include multi-site and dual-stack health-aware routing.

[image placeholder: two roads / health check lights]

No rented maze required

Hosted tooling can be useful, but the product must not be the trap. Customers should not lose control of domains, records or certificates just to keep services working.

Better pattern: own the domain, understand records, document setup, protect keys, and keep a path out.

[image placeholder: key + records + open door]

Knowledge is priceless when shared

DNS and infrastructure work is not only about making systems run. It is about making ownership explainable. Customers do not need every low-level detail, but they should understand the shape of what they own.

The value comes from practical years: books before search, machines before cloud dashboards, and lessons learned from routes, logs, cables and failures.

What Internet City does

DNS zone planning, PowerDNS deployment, dns.he.net support, Hurricane Electric Tunnelbroker support, forward and reverse DNS, MX/SPF/DKIM/DMARC, MTA-STS, TLS reporting, certificate automation, service naming, mail-domain health checks, BreathGSLB, migration planning, documentation and handover.

A domain that makes sense. Mail that can be trusted. Records that can be exported. Certificates that renew. Names that tell the truth. A foundation the customer owns.

Mail first. Web next. Networks always.