DNS Query Types and Using DNS in Troubleshooting
DNS queries and responses are what hold the Internet together. If you want to understand the DNS system then you must understand the DNS query types, and how responses should look, as well as how to understand DNS responses.
DNS stands for Domain Name System, and it is the system that connects a domain, such as www.microsoft.com to an IP address, such as 22.214.171.124.
DNS makes life easier for humans because it saves them from having to remember those IP addresses. The DNS system involves a query/response protocol. The client will send a query to the server, for example asking for the IP address that matches the domain name. It uses a UDP request to do this. The server will respond with a UDP reply, via port 53. For certain types of response, rather than using UDP the server will use TCP. This is because TCP can handle replies that are longer than 512 bytes.
The Main Types of Query Are:
– Type A: to look up IPv4 addresses
– Type AAAA: to look up IPv6 addresses
– Type CNAME: specifying the domain name that needs to be queried to resolve the original query
– Type PTR: a pointer specifies a reverse query, corresponding to the IP address you provided
– Type NS: to request information about an authoritative name server
– Type SOA: Meaning Start of Zone Authority, and used when a zone transfer is being performed
– Type MX: For requesting information about the main server for a given domain
There will only ever be one response in a packet.
If you find that you cannot connect to a given site, or cannot resolve the address for a site, there could be one of several issues. Remember that there are only 13 DNS Master Root Servers, and those servers hold the information about every single internet connected server in the world.
If you are a user who cannot connect to a site, it could be that the DNS information about that site has changed and the information has not propagated (spread) from the master servers to your own ISP’s servers. Many people are now using OpenDNS, Cloudflare’s DNS, or Google’s DNS instead of using their own ISP because those services are generally more reliable.
When something goes wrong with DNS, it can be quite hard to solve, because DNS is an old and opaque system that can be quite confusing. A user puts a DNS request into a DNS recursive server, which could be running BIND or something similar, or could be a third party service. The recursive server will look to see if it already knows the IP address in question and if that record is still valid according to its ‘Time-to-Live’. The TTL is the length of time that the record can be cached before it needs to be refreshed. The Internet is in a constant state of evolution, and because of this even relatively stable services such as email have short TTLs; between one hour, and one day.
In a lot of cases, the recursive DNS server is the only service that needs to be checked. If it has the right information then it will connect the user to the server. If it does not have up to date information, it will forward the request to the next level of DNS name server. If the DNS root name server doesn’t have the answer, then it will pass on a request to the top-level domain server. If that doesn’t know the answer, then the DNS master root server will be sent a request. The master root server has the final say and knows everything about every server.
That’s how things are supposed to work when they’re working well. Unfortunately, that’s not how things always work. DNS cache poisoning is a common problem. In this variety of attack, the DNS server falls into the control of the attacker, and the attacker will insert bad information into the cache of the server. When you attempt to visit the site that has had its record ‘poisoned’, the DNS response will direct you to the fake site, and you may find that your computer or device becomes infected with malware.
DNS poisoning can spread quite easily. If your ISP’s DNS has been infected, then the DNS entries that are faked will spread to your recursive DNS server. If you have any other DNS servers that rely on that server for their records, then you will find that the fake information reaches them as well.
You can reduce the risk of DNS cache poisoning by using DNS Security Extensions can query whether the upstream DNS information is valid, and it will digitally sign the DNS data to ensure that it remains valid. For the DNS process to be valid, there must be NDSSEC deployed at every step in the lookup process.
Not All DNS Problems Really Are DNS
A lot of the problems that web browsers blame on DNS issues are not actually DNS issues. Often, the issue is “you aren’t connected to the Internet” or “you are connected to free WiFi and haven’t logged in yet, so can’t reach external sites”.
DNS problems can occur with a new domain that hasn’t propagated yet, or with a domain that you are moving to a new server. You can use NSLookup to see if DNS is working on your machine. It will show you the DNS server that your computer uses, and you’ll be able to see if it is working. You can use BIND Dig to get information about a site’s records and view the route that the DNS server is using to get information from one of the master servers. That command should flag up a lot of common problems.
Many Windows systems administrators forget about DNS until things go wrong. Often, the problem on a Windows server is as simple as the date and time is wrong, or the DNS server is outdated. Check those obvious things before delving deeper into the log files.