Internet’s fundamental building blocks. It is the global, hierarchical, and distributed host information database that’s responsible for translating names into addresses and vice versa, routing mail to its proper destination, and many other services.” bind9.net
find the results for zones it’s not authoritative for, as a service to its clients. Usually ISP provides raw IP address of recursive DNS servers they maintain, for their customers. People unhappy with their ISP’s DNS behavior/performance use third-party recursive name servers(open DNS resolvers).
of the DNS hierarchy. They are authoritative for identifying the name servers responsible for the Top Level Domain (TLD). They are a network of hundreds of servers in many countries around the world. Shares 13 x 2 IP addresses (13 IPv4, 13 IPv6) using Anycast routing. https://www.iana.org/domains/root/servers
provides descriptive data about domain. SPF Identifies which mail servers are permitted to send email on behalf of a given domain CAA Specifies which certificate authorities (CAs) are allowed to issue certificates for a domain.
the IP address (IPv4) of the computer hosting the domain. dig A insecuredns.com dig A @8.8.8.8 example.com # Specify the nameserver with @ dig +short A iana.org # Display only the IP addresses
IP address (IPv6) of the computer hosting the domain. dig AAAA insecuredns.com dig AAAA @8.8.8.8 example.com # Specify the nameserver with @ dig +short AAAA iana.org # Display only the IP addresses
interface (IP) to a host name. These are primarily used for reverse DNS. Names can reveal information about the host. $ dig +short PTR 4.4.8.8.in-addr.arpa google-public-dns-b.google.com. $ dig +short -x 8.8.8.8 google-public-dns-a.google.com.
email delivery agents where they should deliver your email. You can have many MX records for a domain.(For redundancy) MX records will reveal any third-party email service being used. dig +short MX insecuredns.com
type. Special type of TXT records act as SPF, DK, DKIM and DMARC records. A lot of third-party service providers use TXT records to verify domain ownership and to ensure email security.
used by the domain. "loaderio=6d3df817ccc37b96c16c78e44b62f75e" "atlassian-domain-verification=+Mx+ ... snipped..." "citrix-verification-code=3d0b3642-... snipped..." "smartsheet-site-validation.example.com TXT wfJ... snipped..."
are expected to send e-mail of the domain. There is a dedicated SPF record type, however, it is deprecated in favor of using a TXT record. 300 IN TXT "v=spf1 a include:spf.mtasv.net ~all"
domain, prohibit all others. The domain owner thinks that SPF is useless and/or doesn't care. The domain sends no mail at all. "v=spf1 mx -all" "v=spf1 +all" "v=spf1 -all"
the domain may rely on. SPF sometimes reveals IP addresses (and net blocks) of the organization that you may not have been aware of. "v=spf1" "include:_spf.google.com" "include:mail.zendesk.com" "-all" "v=spf1 ip4:208.118.237.0/24 ip4:208.118.227.0/25 ip4:64.125.235.5 ip4:64.125.235.6 ip4:205.2 goo.gl/vQPCtB
to specify which certificate authorities (CAs) are allowed to issue certificates for a domain. The idea is to allow domain owners to declare which certificate authorities are allowed to issue a certificate for a domain. example.com. CAA 0 issue "letsencrypt.org"
issue certificate issuewild tag identifies CA that is authorized to issue wildcard certificates. iodef contains an email address to notify in case a violation is detected. example.com. 1200 IN CAA 0 issue "comodoca.com" example.com. 1200 IN CAA 0 issuewild "comodoca.com" example.com. 1200 IN CAA 0 iodef "mailto:[email protected]"
which CAs will have to publish all SSL/TLS certificates they issue in a public log. Using CT and CAA records, it's easy to identify rogue/fraudelent SSL/TLS certificates in the wild.
where a DNS server passes a copy of part of it's database(zone file) to another DNS server. DNS zone transfer is always initiated by client/slave by inducing DNS query type AXFR.
SOA ns1.iitk.ac.in. root.ns1.iitk. iitk.ac.in. 43200 IN NS ns2.iitk.ac.in. iitk.ac.in. 43200 IN NS proxy.iitk.ac.in. home.iitk.ac.in. 43200 IN A 202.3.77.174 m3cloud.iitk.ac.in. 43200 IN A 103.246.106.161 mail.iitk.ac.in. 43200 IN A 202.3.77.162 [... snipped ...] mail4.iitk.ac.in. 43200 IN A 202.3.77.189 webmail.iitk.ac.in. 43200 IN A 202.3.77.185 www.webmap.iitk.ac.in. 43200 IN A 202.3.77.74 wiki.iitk.ac.in. 43200 IN A 103.246.106.116 www.iitk.ac.in. 43200 IN A 202.3.77.184
cryptographic signatures. It prevents DNS Spoofing. DNSSEC provides a layer of security by adding cryptographic signatures to existing DNS records. These signatures are stored alongside common record types like A, AAAA, MX etc. By checking associated signature, you can verify that a requested DNS records comes from authoritative nameserver and not spoofed.
the non-existence of records in a zone to prevent attackers spoofing NXDOMAIN responses in an attempt at denial-of-service. Your zone is sorted alphabetically, and the NextSECure(NSEC) records point to the record after the one you looked up. Using NSEC is relatively simple, but it has a nasty side-effect: it allows anyone to list the zone content by following the linked list of NSEC records. Detailed explaination - Take your DNSSEC with a grain of salt
solves this by creating the linked list using hashed domain-names, instead of clear-text domain names. It is possible to collect all the hashes and crack them offline using rainbow tables. Tools like will collect hashes and crack them offline. nsec3map i8enajodqvfjd9t90he4svha3kgntc12.icann.org. 3600 IN NSEC3 djg1irkar2s8d0cka16kio1ribpcmuqp.icann.org. 3600 IN NSEC3 vrt34mkpiesf3fc6kdoovv7irv67odem.icann.org. 3600 IN NSEC3 3eu2lrfspij2g37gvr2b75sop5rfev92.icann.org. 3600 IN NSEC3 qn21dpjn6etm2udq8k4t8v828ou4ege1.icann.org. 3600 IN NSEC3 gp8mhqp858u55rd62v7inl54m5lmf046.icann.org. 3600 IN NSEC3
data and make it available to researchers and the security community. This data includes port scans and a dump of all the DNS records that they can find. Find your needle in the haystack. scans.io Project Sonar