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 <<<

Labels:

Comments

Post a Comment

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
Post a Comment
Read more

DNS response and error types

In this post we explore common DNS response codes. We will cover the following responses: NOERROR SERVFAIL NXDOMAIN NODATA REFUSED Throughout article we’ll refer to the following RFCs: RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES RFC 2308 - Negative Caching of DNS Queries (DNS NCACHE) RFC 2136 - Dynamic Updates in the Domain Name System (DNS UPDATE) RFC 8914 - Extended DNS Errors Response Codes - RCODEs The DNS RCODES are best defined in RFC2316 .  They signify what type of response was sent by the server. “RCODE   Response code - this four bit field is undefined in requests and set in responses.”   The table below shows the summary of the currently defined RCODEs. Mnemonic Val Description NOERROR 0 No error condition.
Post a Comment
Read more

DNS blocking in Indonesia

DNS based censorship and domain blocking in Indonesia is very inconsistent among ISPs. There’s a government mandated black list which the ISPs operating in the country should enforce. However, Indonesia lacks centralised internet infrastructure and has many separate ISPs. In addition, the Indonesian government granted ISPs the authority to block content at their own discretion. All of this leads to a very inconsistent DNS blocking in Indonesia. Official DNS domain blacklist in Indonesia The Government mandated DNS blacklist is published in a redacted form and can be downloaded here: https://trustpositif.kominfo.go.id/ . This is where the blocked domains get redirected to. We can search the database and check if a domain is blocked. In the screenshot below we can see that a popular cryptocurrency exchange is blocked (Ada) and that wikipedia.org is not (Tidak Ada) - thanks to Google Translate. Examples of blocked DNS queries dig binance.com @182.253.45.122 ;; global options: +cmd ;; Got
Post a Comment
Read more