Category: DNS Tutorials

For example, at the registrar level, I delegate to use the following nameservers for my domain, ‘massivedns.com’:

ns1.massivedns.com
ns2.massivedns.com

However, when a user queries the nameservers, they inform the user that the zone has been delegated elsewhere under the following nameservers:

ns1.fastdot.com
ns2.fastdot.com

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.

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

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.