Let's make DNS friendlier!

This is a tracking topic I’m setting up for the goal of making DNS more friendlier. There are two major things I want to do here:

Client-side validation of DNS records

Admin should check if a record you’re adding or deleting would cause an invalid state, and ideally validate in real-time. Right now, we just send the configs to the backend provider as-is, and the server sends a 500 if that returns an error. Ideally, we check to see if the records would cause an invalid state before they even get sent to the server with something client-side.

Live help within DNS settings

As you pull down the menu to choose a record, you should see an explanation and an example of what each type of record does. We should also change the field’s placeholder depending on the chosen record type.


Going to start thinking about DNS record explanations here:


  • A: The most basic record. Points your domain at an IPv4 address.
  • AAAA: The A record’s younger sibling: it points at an IPv6 address. Adding one is strongly encouraged if your hosting provider supports IPv6. (And if they don’t, ask them to!)
  • CNAME: Short for “canonical name”, it tells whatever’s looking up your domain “look at this domain instead”. You’ll frequently see hosting providers tell you to use it.
  • ALIAS (Unique to our current nameserver provider): Similar to a CNAME, but it’s never sent to your client. The nameservers resolve it in the backend and return an A and/or AAAA record.
  • MX: Short for “mail exchange”, it tells servers sending you email where your email servers are.
  • URL (Unique to our current nameserver provider): Sends an HTTP redirect to the URL you specify. Behind the scenes, it publishes A records pointing to a redirector server.
  • TXT: Contains human-readable data about your domain. Typically, you’ll see this used when other services want to verify you control a domain, or for implementing email authentication standards such as DMARC and SPF.


  • SRV: Defines the location of a server of a given protocol, like a more general MX record. Usage depends on the protocol in question.
  • SSHFP: Contains the SSH key fingerprint for the server on the corresponding domain.


  • CAA: Specifies who can issue TLS (i.e. HTTPS) certificates for the domain.
  • PTR: Pointer to a common name. Unlike a CNAME record, resolvers don’t continue to search when they see a PTR record.
  • NS: Delegates a domain to a different nameserver.
  • SPF: Deprecated form of storing data for the SPF email security standard.
  • HINFO: Structured form of showing data about the server behind a site.
  • NAPTR: Maps from a resource name to a unique identifier. Often used as part of the SIP telephony protocol.

FWIW the record types that will be supported in v2 (as of now) are:


DNSimple also has excellent documentation & explanations: Common DNS Records - DNSimple Help


Overall, these look solid! Just have a few points:

AAAA: The A record’s younger sibling: it points at an IPv6 address.

Emphasize that adding an AAAA record is strongly encouraged.

CNAME: Short for “common name”

CNAME is actually “canonical name”

The nameservers resolve it in the backend.

Mention that it resolves to an IP and returns an A record

SOA: System-managed record that defines who is the authority on records for the domain. (TODO: DNSimple says they don’t let you manage this. Will Obl.ong let you? How?)

No SOA records allowed - too confusing, it would be like if you started a new zone inside of your existing one

A more general point, but I think this would be good to put up on https://docs.obl.ong