- Two type of DNS network activities:
- lookup: DNS client queries a DNS server for information
- zone transfers: DNS server (the secondary server) requests from another DNS server (the primary server)
- DNS lookups are usualy executed usin UDP. (If some of data is lost in transit by UDP, the lookup will be redone using TCP)
- DNS sever uses well-known port 53 (UDP/TCP)
- Proxying characteristics of DNS:
- DNS is structured so that servers always act as proxies for clients
- It's also possible to use a DNS feature called forwarding so that a DNS server is effectively a proxy for another server
- The forwarders directive tells the server that, if it doesn't know the information itself already, it should forward the query to a specific server and let this other server figure out the answer, rather than try to contact servers all over the Internet in an attempt to determine the answer itself.
+---------------------+
| Header |
+---------------------+
| Question | the question for the name server
+---------------------+
| Answer | RRs answering the question
+---------------------+
| Authority | RRs pointing toward an authority
+---------------------+
| Additional | RRs holding additional information
+---------------------+
- Answer: The answer section contains RRs that answer the question
- Authority: The authority section contains RRs that point toward an authoritative name server
- Additional: The additional records section contains RRs which relate to the query, but are not strictly answers for the question
Using dig to trace DNS query flow
$ dig +trace google.com @8.8.8.8
DNS server use the field:
- Authority
- Additional
to hint the DNS server to query the another DNS server
$ dig +trace google.com
$ dig www.github.com
Using dig to trace DNS query flow inside the internal network
$ internal_dns="192.168.53.53"
$ dig +trace google.com @${internal_dns}
dig +trace -x 192.30.253.113 # github.com
The reason is that sometimes we have to deal with the query which send to us directly. The following figure shows this scenario:
If we don't have any NS and A record to point ourselves, the client cannot find the authroizative nameserver
# query A record
$ dig google.com
# query A record with short message
$ dig +short google.com
# query A record and specify the dns server
$ dig +short google.com @"${dns_server}"
# query specific record
$ rtype=txt
$ dig -t ${rtype} google.com
$ dig -t soa google.com
# query records with trace
$ dig +trace google.com
# reverse look-up
$ dig +short 172.217.24.14