Skip to main content

Authoritative DNS server

Authoritative Name Server also referred to as NS, is a DNS server that is responsible for a particular DNS zone (domain). This is where the domain administrator configures DNS records in the zone.  

Authoritative Name Servers are defined using NS (Name Server) resource record type. NS record type is described in RFC1035 - https://datatracker.ietf.org/doc/html/rfc1035#page-12

As depicted in the figure below, in a normal DNS resolution flow, a DNS client doesn't directly receive authoritative responses. It is a recursive resolver that iteratively queries the authoritative server on behalf of the client. For testing purposes we can query it directly.

DNA resolution flow authoritative answer

How to find Authoritative Name Servers?

As with everything DNS related, dig to the rescue! Let’s query a recursive DNS resolver and ask it what the NS for securesenses.net. is:

dig NS securesenses.net @8.8.8.8
; <<>> DiG 9.10.6 <<>> NS securesenses.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31323
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;securesenses.net.        IN    NS
;; ANSWER SECTION:
securesenses.net.    21600    IN    NS    ns-cloud-e1.googledomains.com.
securesenses.net.    21600    IN    NS    ns-cloud-e4.googledomains.com.
securesenses.net.    21600    IN    NS    ns-cloud-e3.googledomains.com.
securesenses.net.    21600    IN    NS    ns-cloud-e2.googledomains.com.


We can see that securesenses.net. has 4 authoritative servers.

Non-authoritative vs Authoritative DNS response

If we query a recursive DNS resolver we always receive a non-authoritative response.

dig www.securesenses.net @8.8.8.8
; <<>> DiG 9.10.6 <<>> www.securesenses.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34177
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.securesenses.net.        IN    A
;; ANSWER SECTION:
www.securesenses.net.    1800    IN    CNAME    ghs.google.com.
ghs.google.com.        300    IN    A    216.58.209.19
;; Query time: 74 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Aug 20 10:59:55 CEST 2022
;; MSG SIZE  rcvd: 93

non authoritative DNS response 

To get an authoritative answer we need to query the authoritative server directly:

dig www.securesenses.net @ns-cloud-e1.googledomains.com.
; <<>> DiG 9.10.6 <<>> www.securesenses.net @ns-cloud-e1.googledomains.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16954
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.securesenses.net.        IN    A
;; ANSWER SECTION:
www.securesenses.net.    1800    IN    CNAME    ghs.google.com.

We can see that the answer is authoritative in the “flags” section of dig output - the “aa” flag in dig signifies authoritative answer (aa).
 
authoritative DNS response

Checking authoritative servers in whois data

Alternative way of identifying the name servers is to query the WHOIS data. This is registration data. The registrar also maintains the information about the authoritative servers.

As a side note, you may run into resolution problems if the NS record data at the registrar is different than in the DNS zone. They need to be kept in sync. If you manage your own DNS servers you need to keep that in mind. If you rely on domain resellers such as Godaddy or Google Domains it is done for you automatically.
 
whois securesenses.net

# whois.verisign-grs.com

   Domain Name: SECURESENSES.NET
   Registry Domain ID: 1710731915_DOMAIN_NET-VRSN
   Registrar WHOIS Server: whois.google.com
   Registrar URL: http://domains.google.com
   Updated Date: 2022-04-26T06:31:13Z
   Creation Date: 2012-04-02T13:49:11Z
   Registry Expiry Date: 2024-04-02T13:49:11Z
   Registrar: Google LLC
   Registrar IANA ID: 895
   Registrar Abuse Contact Email: registrar-abuse@google.com
   Registrar Abuse Contact Phone: +1.8772376466
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Name Server: NS-CLOUD-E1.GOOGLEDOMAINS.COM
   Name Server: NS-CLOUD-E2.GOOGLEDOMAINS.COM
   Name Server: NS-CLOUD-E3.GOOGLEDOMAINS.COM
   Name Server: NS-CLOUD-E4.GOOGLEDOMAINS.COM
   DNSSEC: signedDelegation
   DNSSEC DS Data: 61931 8 2 6964839492CD6B924457CD431D07DB84BBA721E791FDB345E8F8E0E53C2EE5EE
   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2022-08-20T09:15:19Z <<<

Comments

Popular posts from this blog

x.509 Certificates - Critical vs non-critical extensions

Extensions are used to associate additional information with the user or the key.  Each certificate extension has three attributes - extnID, critical, extnValue extnID - Extension ID - an OID that specifies the format and definitions of the extension critical - Critical flag - Boolean value extnValue - Extension value  Criticality flag specifies whether the information in an extension is important. If an application doesn't recognize the extension marked as critical, the certificate cannot be accepted. If an extension is not marked as critical (critical value False) it can be ignored by an application. In Windows, critical extensions are marked with a yellow exclamation mark,  View certificate extensions using OpenSSL: # openssl x509 -inform pem -in cert.pem -text -noout (output abbreviated)         X509v3 extensions:             X509v3 Key Usage: critical                 Digital Signature, Key Encipherment             X509v3 Subject Key Identifier

Cisco ASA Certificate Revocation Checking

ASA supports status verification using CRLs and OCSP. CRL can be retrieved using HTTP, LDAP or SCEP. Revocation checking using CRL: Over HTTP: ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2 ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-crl)# protocol http By default ASA will use address listed in CDP extension of the certificate that is being validated.  To override default behaviour we need to add the following in the CRL configuration context. ciscoasa(config-ca-crl)# policy static ciscoasa(config-ca-crl)# url 1 http://cdpurl.kp.local/crl.crl Over LDAP: Certificate I'm using for this lab, doesn't have LDAP address in its CDP extension. Therefore I'm using "policy static"  to specify LDAP URL where CRL can be retrieved.  ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2 ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-trustpoint)# crl configure ciscoasa

Count number of lines - 'findstr'

How do I count number of lines in a command output? findstr /r/n "^" | find /c ":" Above commands will display number of lines output by whatever command (well, nearly whatever) you specify in the front.  For example:  C:\>ping localhost | findstr /r/n "^" | find /c ":" FINDSTR: // ignored 12 This comes handy if you want to find out how many OUs you have in Active Directory: dsquery ou  -limit 0 | findstr /r/n "^" | find /c ":" How many user accounts there are: dsquery user -limit 0 | findstr /r/n "^" | find /c ":" Computers: dsquery computer -limit | findstr /r/n "^" | find /c ":"