Stealth NS records are sent when the authoritative zone file has been delegated to a different nameserver.
For example, at the registrar level, I delegate to use the following nameservers for my domain, ‘massivedns.com’:
However, when a user queries the nameservers, they inform the user that the zone has been delegated elsewhere under the following nameservers:
The user then queries the delegated nameservers for the appropriate records and the lookup is completed.
Stealth NS records can also indicate a misconfiguration or discrepancy.
For example, Stealth NS records can be sent if only 2/3 of your ‘hypothetical’ nameservers are configured at the registry, and all 3/3 nameservers are assigned as authoritative within your zone file; this will cause 1/3 of your nameservers to be sent as a Stealth NS record.
Stealth NS records are achievable by using the NS Resource Record in your zone-file.
The root zone holds information on the various gTLDs (Generic Top Level Domains) and sTLD’s (Sponsored Top Level Domains).
A fantastic explanation by ICANN, illustrates:
The DNS translates domain names that humans can remember into the numbers used by computers to look up its destination (a little like a phone book is used to look-up a phone number). It does this in stages. The first place it ‘looks’ is the top level of the directory service – or “root zone”. So to use www.google.com as an example, your computer ‘asks’ the root zone directory (or top level) where to find information on “.com”. After it gets a response it then asks the “.com” directory service identified by the root where to find information on .google.com (the second level), and finally asking the google.com directory service identified by “.com” what the address for www.google.com is (the third level). After that process – which is almost instantaneous – the full address is provided to your computer. Different entitiesi manage each one of these directory services: google.com by Google, “.com” by VeriSign Corporation (other top level domains are managed by other organizations), and the root zone by ICANN. – ICANN
Lame Nameservers are nameservers that are specified as authoritative within your DNS zone, however, when queried, they do not prove to be authoritative.
This can happen when a nameserver is assigned as authoritative, however, no records for the queried domain have been configured for that particular nameserver, thus it will not provide any records when queried, rendering it ‘lame’.
Reverse DNS records (commonly created via PTR / Pointer records) are records that map an IP address into a human-readable name (i.e. 188.8.131.52 -> massivedns.com).
Nameserver delegation is the process of updating your domain nameservers at the registry level.
This process will off-hand or ‘delegate’ the responsibility of the domain name zone file to different nameserver(s).
A SOA (Start of Authority) record is a mandatory record used to define the information for the authoritative nameserver serving your zone.
The SOA information consists of the primary name server, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone.
The SOA record typically resembles the following format:
example.com. IN SOA ns.example.com. hostmaster.example.com. (
2003080800 ; sn = serial number
172800 ; ref = refresh = 2d
900 ; ret = update retry = 15m
1209600 ; ex = expiry = 2w
3600 ; nx = nxdomain ttl = 1h
NS records are responsible for identifying the nameservers that are authoritative for your domain name, i.e. ns1.massivedns.com and ns2.massivedns.com
Additionally, NS Records can be used to delegate a zone to a different nameserver if you wish to off-load the responsibility.
Public IP addresses are addresses that are accessible from the Internet.
There are certain ranges of IP addresses that are reserved for private network use, such as:
10.0.0.0 through 10.255.255.255
169.254.0.0 through 169.254.255.255 (APIPA only)
172.16.0.0 through 172.31.255.255
192.168.0.0 through 192.168.255.255
A TXT record is an arbitrary string housed in your domain nameserver.
TXT records are commonly used to facilitate SPF records.
Sender Policy Framework (SPF) is used to validate the senders IP address against an accepted IP address, defined in the record itself (typically a TXT record)
SPF is an attempt to stop forged (or spoofed) email, for example, if an unscrupulous individual sent an email pretending to be from your domain name, the receiver would first check the IP address of the sender, and validate it against the SPF record. If the IP address of the sender is not listed in the SPF record, the mail will be rejected.
As an example, an SPF record may resemble the following:
TXT "v=spf1 ip4:192.168.0.2 -all"
This will allow the sender at IP address, 192.168.0.2 to send emails from that particular domain name.