First, there are two kinds of DNS records: those for client look, and those for a server.
Client Lookup - DNS Resolvers
I don't trust Google DNS, though for a while it was the go to DNS, and easy to remember at
220.127.116.11 18.104.22.168 and 22.214.171.124.
For privacy, for me, there are two options, with the first being just better:
- dns.watch 126.96.36.199 / 188.8.131.52 and 2001:1608:10:25::1c04:b12f / 2001:1608:10:25::9249:d69b
- Cloudflare's 184.108.40.206 / 220.127.116.11, if you like or trust cloudflare (I don't)
If one wants some security (as a service), then Quad9 is worth a look.
It is possible to run one's own resolver, though it takes a bit of configuring and resolvers are seen as an attack vector for various bad actors.
There are several DNS services to choose from. Dyn and related companies is the worst. Free DNS services such as afraid.org and he.net are unreliable, or simply not reliably fast. It makes the most sense to go with a top-rated DNS service (highly available and fast resolve times), and pay for this service (though less is more when it comes to expenses).
- DNSmadeEasy.com - Silly name, $30/year for 10 domains, fast and reliable. Generally in the top 10 of private resolvers. I've not found better/faster for cheaper.
As with resolvers, basic DNS services can be run on one's own server, not including the Registrar functionality of placing the nameservers in the root domain servers of the Internet. Again, it takes a bit of configuring so that one has functionality, privacy, security, and is not seen as a target.
There are several records to worry about. The first are nameservers, which are put into the registrar database. This can be as few as two or as many as six (possibly more).
Depending on the DNS Server, these can have wildcards or not. Generally there are at least three A records to have:
For certain services, it is required to have a
www. and also people mistype this, so it is best to have it as a domain, to have it on the SSL certificate, and to have a reroute from
www. to the root domain.
Usually only Bing Webmaster Tools requires a CNAME record. Otherwise these are generally worthless.
These are for the mailserver. Usually a few are needed, one plus two backups. Gsuite has five records, but that is overkill. The top three make the most sense. Also, there are priority numbers, e.g, 1, 5, 10 to govern the round robbin-style resolving.
- 1, aspmx.l.google.com.
- 5, alt1.aspmx.l.google.com.
- 5, alt2.aspmx.l.google.com.
TXT records are the go to place for every third party to put their info. Several examples of TXT Records include:
- Yandex Webmaster Tools validation
- Google Webmaster Tools/Analytics/GSuite/etc. validation
- _acme-challenge records for DNS-based authentication for LetsEncrypt
PTR records are essentially a reverse so that an IP address is associated with a host.domain.tld. This is key for sending email.
DKIM, SPF, DMARC
These are all records for email security, at various levels. DKIM and DMARC are TXT records, and SPF can be TXT or specific SPF records, depending on the DNS service provider.
- Setting up Gsuite DKIM, SPF, DMARC
- Google on DMARC records
- Test SPF and DKIM
- Google on SPF
- DKIM on Gsuite
- Google: About DKIM
SPF looks like:
host.domain.com / "v=spf1 include:_spf.google.com ~all"
SPF are one of the earliest and easiest email records to set up for security, and specifically states which hosts can send email for the domain.
These records help tell SSL Cert providers which of those providers can generate a cert for the domain records. Each host needs two records:
- Name (host), Type: iodef, Value: "mailto:firstname.lastname@example.org"
- Name (host), Type: issue, Value: "letsencrypt.org"