DNS Resolution - Order of Operations

While running a network capture when performing an nslookup for bgsu.edu, I noticed that my DNS server was not querying for the SOA record for bgsu.edu. Here's the order of operations that I see in my capture:

1. My DNS server issues an A record query to one of the root hint servers for bgsu.edu.

2. The root hint server returns a list of NS records for the gTLD servers.

3. My DNS server issues an A record query to one of the gTLD servers for bgsu.edu.

4. The gTLD servers returns a list of NS records for bgsu.edu.

5. My DNS server issues an A record query to one of the name servers returned in step 4 for bgsu.edu.

6. The name server for the domain in question returns the A record information for bgsu.edu.

So my question is: Does my DNS server not need to query for the SOA record for the domain in question first? If not, then how exactly are SOA records used? Which name servers query for the SOA record? Do the gTLD servers query for the SOA record, and therefore, I don't see this in my capture? My understanding is that the SOA holds a list of the NS records, so shouldn't the SOA be the first record queried?

Solution 1:

NS Servers are not part of the SOA record. The SOA record and I quote from RFC 1035 (3.3.13):

Most of these fields are pertinent only for name server maintenance operations.

The fields in the SOA record are:

MNAME The of the name server that was the original or primary source of data for this zone.

RNAME A which specifies the mailbox of the person responsible for this zone.

SERIAL The unsigned 32 bit version number of the original copy of the zone. Zone transfers preserve this value. This value wraps and should be compared using sequence space arithmetic.

REFRESH A 32 bit time interval before the zone should be refreshed.

RETRY A 32 bit time interval that should elapse before a failed refresh should be retried.

EXPIRE A 32 bit time value that specifies the upper limit on the time interval that can elapse before the zone is no longer authoritative.

MINIMUM The unsigned 32 bit minimum TTL field that should be exported with any RR from this zone.

So with that out of the way, what is happening is this:

1. You dns server does not have the entry for bgsu.edu cached and is not authoritative, so it needs to ask the root hint servers where to go looking for the proper dns servers
2. The gTLD have GLUE records which are just the Name Servers for domains, this is the server you are going to actually query for the host you are trying to connect to.
3. You get bgsu.edu's Name servers
4. You do a DNS query for the host you are interested in
5. You get the DNS record you were originally looking for.

Solution 2:

SOA records are used during transfers (Master to Slave/Stub). The Master has the SOA record pointing to it.
The Master will also have a NS record, indicating that it has an authortative copy of the zone.
Slave servers will also have an authoritative copy (and usually have NS records, as those are returned by a higher level server in a recursive query, but not necessarily).

Solution 3:

The SOA record is only used for:

1. secondary servers checking the serial number, to see if they need to transfer a new copy (AXFR) or incremental changes (IXFR)
2. secondary servers deciding when to stop serving the zone, if the primary disappears
3. telling recursive servers how long to cache negative answers for (the MINIMUM field, which doesn't mean "minumum TTL anymore@.
4. dynamic update clients, to find the primary server

A normal recursive resolver will never explicitly ask for the SOA record, but more often it comes along for the ride in the AUTHORITY section of the response from an authoritative server. Even then, that's mostly only used for #3 above.

A normal DNS client has no need for the SOA at all.