Let's make DNS friendlier!

Development
1

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.

4 Likes
3

Going to start thinking about DNS record explanations here:

Basics

  • 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.

Service-specific

  • 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.

Advanced/rare

  • 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.
3 Likes
4

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

A
AAAA
ALIAS
CAA
CNAME
HINFO
MX
NAPTR
NS
PTR
SRV
SPF
SSHFP
TXT
URL
4 Likes
5

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

3 Likes
6

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

5 Likes