DNS

References

• Microsoft Technet — Resource records reference

A DNS database consists of one or more zone files used by the DNS server. Each zone holds a collection of structured resource records, the following of which are supported by the DNS Server service.

• Microsoft Technet — Understanding DNS

How DNS works.

• DNS-HOWTO

Detailed explanations on how DNS work, applied to Linux.

• zytrax open — Chapter 8. DNS Resource Records (RRs)

• Wildcard DNS record (like *.example.com. 3600 IN MX 10 host1.example.com.)

How-to

Reverse DNS lookup

See dig, host and nslookup.

Transfer a domain

See OVH guide.

Prerequisite:

• Domain status record in Whois database must be ok.

whois noekeon.org|grep -i "domain status"
# Domain Status: ok https://icann.org/epp#ok

If not ok, then maybe the domain is locked. In that case, it must be unlocked first at current registrar.

• Domain must not expire soon (soon seems variable, but is between 14 days and 60 days).
• Domain must exist for at least 60 days.
• Must have the domain transfer authorisation code (AUTHINFO).

Test domain configuration

Here some links to wizards that test the DNS configuration automatically:

• http://www.intodns.com/
• http://dkimvalidator.com/

More information:

• https://www.rackaid.com/blog/email-dns-records/ (PTR, SPF and DKIM records)

These are for Reverse DNS (PTR), SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail)

Test SPF record

The simplest is to send an email from domain to GMail account, and view the mail source (Select Show original) to check for the fields Received-SPF:

Received: from ober.noekeon.org (ober.noekeon.org. [91.134.133.203])
        by mx.google.com with ESMTP id g19si15969822wmc.137.2016.09.04.23.56.46
        for <night.moore.nm@gmail.com>;
        Sun, 04 Sep 2016 23:56:47 -0700 (PDT)
Received-SPF: pass (google.com: domain of michael.peeters@noekeon.org designates 91.134.133.203 as permitted sender) client-ip=91.134.133.203;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of michael.peeters@noekeon.org designates 91.134.133.203 as permitted sender) smtp.mailfrom=michael.peeters@noekeon.org

Troubleshooting

SERVFAIL

dig (and dig +notrace) fails with a SERVFAIL error code but dig +trace works:

dig +notrace miki.immie.org

# ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> +notrace miki.immie.org
# ;; global options: +cmd
# ;; Got answer:
# ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29570
# ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Using a different DNS server works too:

dig @8.8.8.8 miki.immie.org

Other subdomains in that zone work though:

dig +notrace kiwi.immie.org
dig +notrace mip.immie.org

Solution

Turns out that we had duplicate CNAME entries in the zone file. We delete one.

miki       10800 IN CNAME prime
miki       10800 IN CNAME prime

Using nslookup

From tecmint.com:

nslookup yahoo.com                # Find out "A" record (IP address) of domain
nslookup 209.191.122.70           # Find out reverse domain lookup
nsloopyp ir1.fp.vip.mud.yahoo.com # Find out specific Domain lookup
nslookup -query=mx www.yahoo.com  # To Query MX (Mail Exchange) record.
nslookup -query=ns www.yahoo.com  # To query NS(Name Server) record.
nslookup -type=soa www.yahoo.com  # . To query SOA (Start of Authority) record.
nslookup -query=any yahoo.com     # To query all Available DNS records.
nslookup -debug yahoo.com         # Enable Debug mode

Get DNS info from NetworkManager

Get DNS info received from DHCP using NetworkManager:

nmcli device show|grep -i dns
# IP4.DNS[1]:                             127.0.0.1
# IP4.DNS[2]:                             164.129.147.251
# IP4.DNS[3]:                             10.129.252.253

Troubleshooting dnsmasq

DNS is down:

nslookup google.be
# Server:       127.0.0.1
# Address:  127.0.0.1#53
# 
# ** server can't find google.be: NXDOMAIN

127.0.0.1:53 is served by dnsmasq:

sudo netstat -lpn | grep 127.0.0.1:53
# tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      30718/dnsmasq       
# udp        0      0 127.0.0.1:53            0.0.0.0:*                           30718/dnsmasq

On Debian, this is configured in /etc/resolv.conf:

# Generated by NetworkManager
nameserver 127.0.0.1

Let's bypass dnsmasq to see if issue is there. For this, we use Google DNS 8.8.8.8:

cat /etc/resolv.conf
# # Generated by NetworkManager
# nameserver 8.8.8.8

nslookup google.be
# Server:       8.8.8.8
# Address:  8.8.8.8#53
# 
# Non-authoritative answer:
# Name: google.be
# Address: 216.58.213.163
# Name: google.be
# Address: 2a00:1450:4007:811::2003

DNS is back when bypassing dnsmasq.

Apparently killing dnsmasq is enough to restore the service (this will restore /etc/resolv.conf)

sudo pkill dnsmasq