Skip to content
πŸ’» 🧠 Code 1001 > πŸ“‘ Cheat Sheets > πŸ–§ The Complete, Exhaustive Guide to DNS Records: From Basics to DNSSEC and Automation.

πŸ–§ The Complete, Exhaustive Guide to DNS Records: From Basics to DNSSEC and Automation.

DNS (Domain Name System) is the fundamental system upon which the entire modern internet rests. It is not merely a “phone book,” but a complex, distributed database that translates human-readable names (e.g., google.com) into technical identifiers such as IP addresses, mail servers, security policies, and even geographical coordinates. Incorrect DNS configuration is one of the most common causes of website downtime, email delivery issues, and security vulnerabilities.

This guide combines all aspects of DNS: from basic records used daily to complex mechanisms like DNSSEC and DANE. We will examine each record type, its purpose, syntax, practical examples, common mistakes, diagnostic commands, and ready-made templates for deployment. The information is structured so you can use this material as a textbook, an administrator’s reference, and a checklist for production environments.

In This Article
  1. 1. Terminology
  2. 2. Detailed Breakdown of All Record Types
  3. 3. Practical Recommendations and Configuration Nuances
  4. 4. Complete Zone File Templates (BIND style)
  5. 5. Step-by-Step Email Domain Setup (PTR, SPF, DKIM, DMARC)
  6. 6. Commands for DNS Checking and Debugging
  7. 7. Security and Best Practices
  8. 8. Common Mistakes and How to Avoid Them
  9. 9. Checklist Before Production Release or Migration
  10. 10. Additional Examples and Field Explanations
  11. 11. Useful Scenarios
  12. 12. Ready-to-Use JSON for Import into Provider Panel

1. Terminology

Before diving into record types, it’s crucial to understand the key terms used in DNS. This establishes a common language base and helps avoid confusion.

  • DNS (Domain Name System): The Domain Name System. A global distributed database that translates domain names into IP addresses and other related information.
  • Domain Name: A human-readable address on the internet, e.g., example.com. Consists of labels separated by dots.
  • FQDN (Fully Qualified Domain Name): A complete domain name that uniquely identifies a node in the DNS hierarchy. Always ends with a dot denoting the DNS root (e.g., www.example.com.).
  • Zone: An administrative unit in DNS. A portion of the namespace managed by one authoritative server (or a group of servers). Usually corresponds to a domain or subdomain.
  • Zone File: A text file stored on a DNS server that contains all records for a specific zone. Uses syntax defined by the BIND standard.
  • Record (Resource Record, RR): The basic unit of data in DNS. Each record has a type, name, value, and TTL.
  • Record Type: Defines what information the record contains (e.g., A, MX, TXT). Each type corresponds to a unique numeric code (e.g., 1 for A, 15 for MX).
  • TTL (Time To Live): The record’s lifetime, specified in seconds. Determines how long resolvers and other DNS servers can cache the record before requesting it again from the authoritative server.
  • Resolver: A DNS client or server that receives a request from an application (e.g., a browser) and performs the necessary queries to obtain an answer. Can be recursive (performs the full query chain) or non-recursive.
  • Authoritative Server: A DNS server that stores the original records for a specific zone and is responsible for them. Answers queries using data from the zone file.
  • Recursive Server: A server that receives a request from a client and, if it doesn’t have the answer in its cache, performs a chain of queries, starting from the root servers, to find the authoritative server and get the answer.
  • Root Server: One of the 13 groups of servers (denoted by letters from a.root-servers.net. to m.root-servers.net.) that are the starting point for resolving any domain name. They know where the servers for top-level domains (TLDs) are located.
  • TLD (Top-Level Domain): A top-level domain. The last part of a domain name (e.g., .com, .org, .ru, .io).
  • Registrar: The company through which domain names are registered. Manages delegation information (which NS servers serve the domain) in the parent zone (e.g., in the .com zone for the example.com domain).
  • Registrant: The owner of the domain name.
  • Delegation: The process of transferring control of a subdomain (or domain) from the parent zone to the child. Achieved using NS records in the parent zone.
  • Glue Record: An A or AAAA record published by the registrar for a name server whose domain name is within the delegated zone. Necessary to break a circular dependency.
  • SOA (Start of Authority): A record containing administrative information about the zone, including the primary server, administrator contact, and parameters controlling zone transfer to secondary servers.
  • Serial Number: A field in the SOA record that indicates the zone’s version. Secondary servers use it to determine if an update is needed.
  • Forward Resolution: The process of converting a domain name to an IP address (e.g., example.com β†’ 192.0.2.1).
  • Reverse Resolution: The process of converting an IP address to a domain name (e.g., 192.0.2.1 β†’ example.com). Managed through in-addr.arpa (for IPv4) and ip6.arpa (for IPv6) zones.
  • Cache: A temporary storage for DNS records on a resolver or DNS server to speed up subsequent requests.
  • Caching: The process of saving DNS records in a cache.
  • Negative Caching: Caching information that the requested record does not exist.
  • RFC (Request for Comments): An official document describing standards, protocols, and procedures on the internet. All major aspects of DNS are described in a series of RFCs.
  • BIND (Berkeley Internet Name Domain): The most common implementation of a DNS server. The syntax of its zone files has become the de facto standard.
  • MTA (Mail Transfer Agent): A mail server responsible for transferring email (e.g., Postfix, Exim, Sendmail).
  • FCrDNS (Forward-Confirmed Reverse DNS): A verification mechanism where an IP address has a PTR record that resolves to a domain name, and that domain name, in turn, has an A record pointing back to the original IP address. Critical for mail server reputation.
  • DNSSEC (Domain Name System Security Extensions): A set of extensions adding cryptographic signatures to DNS records to ensure their authenticity and integrity.
  • DANE (DNS-based Authentication of Named Entities): A standard allowing TLS certificates to be bound to DNS names using TLSA records. Requires DNSSEC to be enabled.
  • CAA (Certification Authority Authorization): A mechanism allowing a domain owner to specify which certificate authorities (CAs) are authorized to issue certificates for it.
  • SPF (Sender Policy Framework): A mechanism allowing a domain owner to specify which servers are authorized to send mail on its behalf.
  • DKIM (DomainKeys Identified Mail): A mechanism allowing outgoing emails to be signed with a digital signature that the recipient can verify using a public key published in DNS.
  • DMARC (Domain-based Message Authentication, Reporting & Conformance): A policy defining how mail servers should handle emails that fail SPF or DKIM checks and configuring the sending of reports to the domain owner.
  • ALIAS / ANAME: Non-standard record types offered by some DNS providers. Allow creating aliases for the root domain (apex), which is impossible with a standard CNAME.
  • CNAME Flattening: A technology used by some DNS providers. When a CNAME is queried for an apex domain, the server automatically resolves the CNAME chain and returns the final A/AAAA records to the client, avoiding RFC violation.

2. Detailed Breakdown of All Record Types

All examples are provided in BIND-style zone-file format. Names ending with a dot (e.g., example.com.) are FQDNs. TTL (Time To Live) is specified in seconds and determines how long the record can be cached by resolvers.

A β€” Address Record (IPv4)

  • Purpose: Binds a domain name to a 32-bit IPv4 address. The most basic and frequently used record.
  • Format: name TTL IN A IPv4-address
  • Example:
    example.com. 3600 IN A 192.0.2.1 www.example.com. 3600 IN A 192.0.2.1
  • When used: To specify the IP address of a web server, API, game server, or any other service accessible via IPv4.
  • Check: dig +short example.com A
  • Best Practices:
    • Using an A record for the root domain (apex, @) is standard and correct practice.
    • Choose TTL based on IP address stability. For stable addresses β€” 3600 (1 hour) or 86400 (1 day). Before migration β€” reduce to 300 (5 minutes).

AAAA β€” IPv6 Address Record

  • Purpose: Analog of the A record, but for 128-bit IPv6 addresses. Critically important for the future of the internet.
  • Format: name TTL IN AAAA IPv6-address
  • Example:
    example.com. 3600 IN AAAA 2001:db8::1
  • When used: To ensure service availability via the IPv6 protocol.
  • Check: dig +short example.com AAAA

CNAME β€” Canonical Name Record

  • Purpose: Creates an alias for a domain name. Any request to a CNAME is automatically converted into a request to its target (canonical) name.
  • Format: name TTL IN CNAME target.
  • Example:
    www.example.com. 3600 IN CNAME example.com. blog.example.com. 3600 IN CNAME blog-hosting.example.net.
  • Important Restrictions:
    • Record Conflict: You cannot have a CNAME and any other record (A, MX, TXT, etc.) for the same name. This is an RFC violation.
    • Apex Domain: The RFC standard prohibits using CNAME for the root domain (e.g., example.com.) because it already contains NS and SOA records. To solve this, DNS providers (Cloudflare, AWS Route 53) offer non-standard extensions: ALIAS or ANAME, which resolve the alias to A/AAAA records on the fly.
  • Practical Application: Connecting a CDN (make www a CNAME to the CDN address), using SaaS platforms (blog, store).
  • Check: dig +short www.example.com CNAME

MX β€” Mail Exchange Record

  • Purpose: Specifies the servers that accept incoming mail for the domain. The record contains a priority: the smaller the number, the higher the priority.
  • Format: name TTL IN MX priority mail_server.
  • Example:example.com. 3600 IN MX 10 mail1.example.com. example.com. 3600 IN MX 20 mail2.example.com.
    • Mail will first be sent to mail1.example.com.. If it is unavailable, the MTA (Mail Transfer Agent) will try mail2.example.com..
  • Key Requirements:
    • The mail server (mail1.example.com.) must have its own A or AAAA record.
    • A PTR record must be configured for the mail server’s IP address, and it must match the server name specified in the MX. This is critical for server reputation and mail delivery.
  • Check: dig +short example.com MX

TXT β€” Text Record

  • Purpose: Stores arbitrary text data. Widely used for email security policies (SPF, DKIM, DMARC), domain ownership verification (Google, Microsoft, Yandex), and other purposes.
  • Format: name TTL IN TXT "text"
  • Examples:
    • SPF (Sender Policy Framework): Defines which servers are authorized to send mail on behalf of the domain. example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all"
      • ip4:192.0.2.0/24 β€” allows the entire subnet.
      • include:_spf.google.com β€” includes rules from Google’s zone (for Gmail).
      • ~all β€” “soft” failure for all others (softfail). -all β€” strict failure (fail).
    • DKIM (DomainKeys Identified Mail): Publishes the public key for verifying the digital signature added to outgoing emails. Usually created for a subdomain like selector._domainkey.domain. default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
      • v=DKIM1 β€” version.
      • k=rsa β€” key type.
      • p=... β€” the public key itself in base64 format.
    • DMARC (Domain-based Message Authentication, Reporting & Conformance): Sets the policy for handling emails that fail SPF or DKIM checks and configures report sending. _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
      • p=reject β€” reject emails that fail verification.
      • rua=mailto:... β€” address for aggregate reports.
      • ruf=mailto:... β€” address for forensic reports (specific failures).
      • pct=100 β€” apply policy to 100% of emails.
    • Verification: example.com. 3600 IN TXT "google-site-verification=abc123..."
  • Notes:
    • If a text string is longer than 255 bytes, it can be split into multiple parts in the zone file, with each part enclosed in quotes. The DNS server will automatically concatenate them.
      example.com. IN TXT ("v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; " "pct=100; fo=1")
  • Check: dig +short example.com TXT

NS β€” Name Server Record

  • Purpose: Specifies the DNS servers that are authoritative for the zone. These records are the basis for delegating domain management.
  • Format: name TTL IN NS server_name.
  • Example:
    example.com. 3600 IN NS ns1.example.net. example.com. 3600 IN NS ns2.example.net.
  • Important Points:
    • NS records in the zone must exactly match the name servers specified with the domain registrar.
    • Glue Records: If the name server (e.g., ns1.example.com.) is located within the same zone it serves (example.com.), a circular dependency arises. To break it, add “glue” records β€” A or AAAA records for these name servers β€” with the registrar.
  • Check: dig +short example.com NS

SOA β€” Start of Authority Record

  • Purpose: The main administrative record of a DNS zone. Contains information about the primary server, administrator, and parameters controlling synchronization between the primary and secondary servers.
  • Format:
    name TTL IN SOA primary_server. admin_email. ( serial_number ; Serial refresh_interval ; Refresh retry_interval ; Retry expiry_time ; Expire min_TTL ) ; Minimum TTL
  • Example:
    example.com. 3600 IN SOA ns1.example.net. admin.example.com. ( 2025092201 ; Serial (YYYYMMDDNN) 7200 ; Refresh (2 hours) 3600 ; Retry (1 hour) 1209600 ; Expire (14 days) 86400 ) ; Minimum TTL (1 day)
  • Field Explanations:
    • Serial: Zone version. Crucially important to increment this number with every change to the zone. Secondary servers compare their Serial with the Serial on the primary server and, if it’s smaller, request an update. Recommended format: YYYYMMDDNN (year, month, day, revision number for the day).
    • Refresh: Interval (in seconds) after which secondary servers should check the primary server for updates.
    • Retry: Interval after which a secondary server should retry if the first update attempt fails.
    • Expire: Time (in seconds) after which a secondary server will stop responding to queries if it cannot contact the primary server. The zone is considered “expired”.
    • Minimum TTL: Originally set the minimum TTL for all records in the zone. Now often used as the TTL for negative caching (how long to cache a “record not found” response).
  • Check: dig +short example.com SOA

PTR β€” Pointer Record (Reverse DNS)

  • Purpose: Provides reverse resolution β€” converts an IP address to a domain name. Managed by the IP address owner (ISP, hosting provider), not the domain owner.
  • Format for IPv4: The IP address is written in reverse order, and the suffix .in-addr.arpa. is added.
    • IP 192.0.2.5 β†’ 5.2.0.192.in-addr.arpa.
  • Format for IPv6: Each 4-bit part (nibble) of the address is written in reverse order, and the suffix .ip6.arpa. is added.
    • IPv6 2001:db8::1 β†’ 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
  • Example (IPv4):
    5.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.
  • Practical Significance: Critically important for mail servers. Most mail systems check that the PTR record for the sender’s IP address matches the name the server presents in the HELO/EHLO command. A mismatch is a common reason for emails being marked as spam.
  • Check: dig -x 192.0.2.5 +short or host 192.0.2.5

SRV β€” Service Record

  • Purpose: Specifies the location of servers for specific services, including protocol and port. Allows clients to automatically find the required server.
  • Name Format:_service._protocol.domain.
    • Service: sip, xmpp-server, _minecraft, etc.
    • Protocol: tcp, udp.
  • Record Format: name TTL IN SRV priority weight port target.
  • Example:
    _sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com. _minecraft._tcp.example.com. 3600 IN SRV 5 0 25565 mc1.example.com.
  • Field Explanations:
    • Priority: The smaller the number, the higher the priority. The client will first try to connect to the server with the lowest priority.
    • Weight: Used for load balancing between servers with the same priority. The probability of selecting a server is proportional to its weight. If all weights are equal, selection is random.
    • Port: The port on which the service runs.
    • Target: The FQDN of the server to which the request should be directed. This server must have an A or AAAA record.
  • Application: VoIP (SIP), instant messaging (XMPP), games (Minecraft), directories (LDAP).
  • Check: dig +short _sip._tcp.example.com SRV

CAA β€” Certification Authority Authorization

  • Purpose: Allows the domain owner to specify which certificate authorities (CAs) are authorized to issue SSL/TLS certificates for this domain. This is an important security mechanism to prevent unauthorized certificate issuance.
  • Format: name TTL IN CAA flags tag value
  • Example:
    example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
  • Explanations:
    • Flags: Usually 0. Flag 128 (critical) means that a CA that does not understand this tag must refuse to issue the certificate.
    • Tags:
      • issue: Allows the specified CA to issue certificates. An empty value (;) prohibits issuance by anyone.
      • issuewild: Allows issuance of wildcard certificates (*.example.com).
      • iodef: URL (usually mailto: or http(s):) for sending reports about attempts to violate the CAA policy.
  • Check: dig +short example.com CAA

NAPTR β€” Naming Authority Pointer Record

  • Purpose: Used for complex name and URI rewriting rules. Most often applied in telecommunications systems (ENUM for converting phone numbers to SIP URIs) and for dynamic service discovery.
  • Format: name TTL IN NAPTR order preference flags service regular_expression replacement.
  • Example (simplified for ENUM):
    4.3.2.1.5.5.5.1.e164.arpa. IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:info@example.com!" .
  • Explanations:
    • Order: Processed from smallest to largest.
    • Preference: Analogous to weight in SRV for records with the same order.
    • Flags: U means the result is a URI (e.g., sip:).
    • Service: Service type (e.g., E2U+sip β€” conversion to SIP URI).
    • Regexp: Regular expression for transforming the input string.
    • Replacement: Alternative to the regular expression (usually empty if regexp is used).
  • Application: Complex routing scenarios in VoIP, ENUM.

TLSA β€” TLSA Certificate Association Record (DANE)

  • Purpose: Binds a TLS certificate (or part of it) to a DNS name using a DNS record. This is part of the DANE (DNS-based Authentication of Named Entities) standard. Requires DNSSEC to be enabled to ensure trust; otherwise, the record can be forged.
  • Name Format: _port._protocol.name.
  • Record Format: name TTL IN TLSA usage selector matching_type data
  • Example:
    _443._tcp.www.example.com. 3600 IN TLSA 3 1 1 d2abde...f21
  • Field Explanations:
    • Usage:
      • 3 (DANE-EE): End-entity certificate. Most common.
      • 1 (PKIX-EE): End-entity certificate, must be signed by a trusted CA.
      • 2 (DANE-TA): Trusted certificate authority certificate.
      • 0 (PKIX-TA): CA certificate, must be in the trust chain.
    • Selector:
      • 0: Full certificate.
      • 1: Only the certificate’s public key.
    • Matching Type:
      • 0: Exact data (not used).
      • 1: SHA-256 hash.
      • 2: SHA-512 hash.
    • Data: Hash of the certificate or its public key in hex format.
  • Application: Enhancing TLS security, especially in environments where public CAs cannot be trusted.
  • Check: dig +short _443._tcp.www.example.com. TLSA

DNSSEC Records (DNSKEY, DS, RRSIG, NSEC, NSEC3)

DNSSEC (DNS Security Extensions) is a set of extensions that add cryptographic signatures to DNS records to protect against forgery (spoofing) and cache poisoning attacks.

  • General Principle: The zone is signed with a private key. The public key is published in a DNSKEY record. To create a chain of trust, the hash of this key (DS record) is published in the parent zone (e.g., for example.com β€” in the .com zone). Clients supporting DNSSEC can verify the signature (RRSIG) of each record using the public key and ensure its authenticity.
  • DNSKEY: The zone’s public key.
    • Example:example.com. 3600 IN DNSKEY 257 3 13 AwEAAa3d...9QAB
      • 257 β€” flags (257 = KSK, 256 = ZSK).
      • 3 β€” protocol (always 3).
      • 13 β€” algorithm (13 = ECDSA/SHA256).
      • Last field β€” key in base64.
  • DS (Delegation Signer): Hash of the public key (DNSKEY) of the child zone, published in the parent zone to create a chain of trust.
    • Example:example.com. 3600 IN DS 54517 13 2 84C8...D34F
      • 54517 β€” Key Tag (key identifier).
      • 13 β€” Algorithm.
      • 2 β€” Digest type (SHA-256).
      • Last field β€” hash in hex.
  • RRSIG (Resource Record Signature): Digital signature for a set of DNS records.
    • Example (signature for A record):example.com. 3600 IN RRSIG A 13 2 3600 20251001000000 20250901000000 54517 example.com. oNvL...7Q==
      • A β€” type of records signed.
      • 13 β€” algorithm.
      • 2 β€” number of labels in the name.
      • 3600 β€” original TTL.
      • 20251001000000 β€” signature expiration time.
      • 20250901000000 β€” signature inception time.
      • 54517 β€” Key Tag of the signing key.
      • example.com. β€” signer’s name.
      • Last field β€” signature in base64.
  • NSEC / NSEC3: Used to authenticate negative responses (proof that a record with such a name or type does not exist). NSEC3 additionally hashes names to protect against “zone walking”.
  • Enabling DNSSEC: This is a separate, complex process:
    1. Generate key pairs (KSK and ZSK) on the DNS server.
    2. Publish DNSKEY records in the zone.
    3. Generate a DS record from the KSK.
    4. Publish the DS record with the domain registrar (in the parent zone).
    5. Enable zone signing on the DNS server (automatic generation of RRSIG, NSEC/NSEC3).
    6. Test using dig +dnssec and online tools (e.g., Verisign DNSSEC Debugger).
  • Check:
    • dig +dnssec example.com A (will show RRSIG for A record if DNSSEC is enabled and working).
    • dig +short example.com DNSKEY
    • dig +short example.com DS

SSHFP β€” SSH Public Key Fingerprint

  • Purpose: Publishes the hash (fingerprint) of the host’s SSH key in DNS. SSH clients can use this record to automatically verify the server’s authenticity on first connection, preventing “man-in-the-middle” (MITM) attacks. Recommended to use with DNSSEC to guarantee record authenticity.
  • Format: name TTL IN SSHFP algorithm digest_type fingerprint
  • Example:
    example.com. 3600 IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
  • Explanations:
    • Algorithm:
      • 1 β€” RSA
      • 2 β€” DSA
      • 3 β€” ECDSA
      • 4 β€” ED25519
    • Digest Type:
      • 1 β€” SHA-1
      • 2 β€” SHA-256
    • Fingerprint: Hash of the public key in hex format.
  • Generation: On the server, you can generate the record with the command: ssh-keygen -r example.com
  • Check: dig +short example.com SSHFP

Rare and Service Records

  • HINFO (Host Information): Stores information about the host’s CPU type and operating system. Not recommended for use as it discloses potentially sensitive system information.
    • Example: server1.example.com. 3600 IN HINFO "Intel Xeon" "Ubuntu 22.04"
  • LOC (Location): Stores the geographical coordinates (latitude, longitude, altitude) of the host.
    • Example: example.com. 3600 IN LOC 55 45 21.000 N 37 37 03.000 E 15m
  • RP (Responsible Person): Specifies the contact person responsible for the zone. Email is specified in hostname format (dot instead of @).
    • Example: example.com. 3600 IN RP admin.example.com. txt-record.example.com.
  • SPF (deprecated): Previously existed as a separate record type but is now fully replaced by TXT. Should not be used.
    • Example (do not use): example.com. IN SPF "v=spf1 ..."

3. Practical Recommendations and Configuration Nuances

  • TTL Management:
    • Standard Value: 3600 seconds (1 hour) β€” a good balance between performance (caching) and flexibility.
    • Before Migration: Reduce the TTL for relevant records (e.g., A/AAAA for your website) to 300 seconds (5 minutes) 24-72 hours before the planned change. This reduces the time for changes to propagate.
    • After Migration: Once changes have stabilized, increase the TTL back to an optimal value (e.g., 3600 or 86400) to reduce load on DNS servers.
  • SOA Serial:
    • Always increment the serial number after every change to the zone. If you don’t, secondary servers won’t learn about updates.
    • Recommended Format: YYYYMMDDNN (e.g., 2024051701). This is clear and allows easy tracking of when the last change was made.
  • CNAME at Apex (Root Domain):
    • Problem: The RFC standard prohibits CNAME at the apex domain (e.g., example.com.) because it conflicts with other mandatory records (NS, SOA).
    • Solution: Use features provided by your DNS provider:
      • ALIAS/ANAME: Non-standard record types that behave like CNAME but are resolved by the provider’s DNS server into A/AAAA records for the client’s response. This allows using aliases at the apex.
      • CNAME Flattening: A technology (e.g., in Cloudflare) where a CNAME at the apex is automatically “flattened” β€” the DNS server returns the A/AAAA records of the target host instead of the CNAME.
  • Glue Records:
    • When Needed: If your name servers (e.g., ns1.example.com.) are located within the same zone they serve (example.com.).
    • What to Do: Find the glue record configuration section with your domain registrar and add A (and/or AAAA) records for your name servers. This breaks the circular dependency.
  • PTR Setup for Mail:
    • Requirement: Your mail server’s IP address must have a PTR record that resolves to its fully qualified domain name (FQDN, e.g., mail.example.com.).
    • Consistency: The name that the mail server sends in the HELO/EHLO command must match the name from the PTR record, and that name, in turn, must have an A record pointing back to the same IP address. This is called “Forward-Confirmed Reverse DNS” (FCrDNS) and is critical for reputation.
    • Where to Configure: With your hosting provider or IP address owner, not in your domain’s DNS zone.
  • Splitting Long TXT Records:
    • If a string in a TXT record exceeds 255 bytes, it must be split into multiple parts in the zone file. Each part is enclosed in quotes, and the DNS server automatically concatenates them.
    • Example:
      example.com. IN TXT ( "v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:dmarc@thirdparty.com; " "ruf=mailto:forensics@example.com; fo=1; adkim=s; aspf=s; pct=100" )

4. Complete Zone File Templates (BIND style)

Below are ready-made templates for three common scenarios. Replace example.com, example.net, IP addresses, and keys with your own values.

a) Simple Website (Static, No Email)

$TTL 3600
@   IN SOA ns1.hosting.net. hostmaster.example.com. (
        2025092201 ; serial (YYYYMMDDNN)
        7200       ; refresh (2 hours)
        3600       ; retry (1 hour)
        1209600    ; expire (14 days)
        86400 )    ; minimum TTL (1 day)

; Authoritative Name Servers
@       IN NS   ns1.hosting.net.
@       IN NS   ns2.hosting.net.

; Web Server (IPv4 and IPv6)
@       IN A    192.0.2.10
@       IN AAAA 2001:db8::10

; WWW subdomain (alias to apex)
www     IN CNAME @

; Security: Restrict Certificate Authorities
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

b) Website + Own Mail Server

$TTL 3600
@   IN SOA ns1.example.net. admin.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        86400 )    ; minimum

; Name Servers
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Web Section ---
@       IN A    192.0.2.10
www     IN CNAME @

; --- Mail Section ---
; A record for the mail server
mail    IN A    192.0.2.20

; MX record pointing to the mail server
@       IN MX   10 mail.example.com.

; --- Email Authentication ---
; SPF: Allow mail server IP and Google Workspace
@       IN TXT  "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all"

; DKIM: Public key for 'default' selector
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

; DMARC: Policy to quarantine failures and send reports
_dmarc  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

; --- Security ---
@       IN CAA  0 issue "letsencrypt.org"

c) Website + CDN + Email + DNSSEC (Complex Example)

$TTL 300 ; Lower TTL for flexibility with CDN
@   IN SOA ns1.example.net. hostmaster.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        3600 )     ; minimum (also used for negative caching)

; Name Servers
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Web Section (with CDN) ---
; Apex domain: Use ALIAS/ANAME (provider-specific) to point to origin or CDN edge
; If your provider supports ALIAS:
; @     IN ALIAS origin.examplehost.net.
; If using CNAME flattening for apex (e.g., Cloudflare):
@       IN A    192.0.2.10 ; Temporary or fallback IP, often managed by provider

; WWW subdomain: CNAME to CDN provider
www     IN CNAME cdn-provider.example.net.

; --- Mail Section ---
mail    IN A    192.0.2.20
@       IN MX   10 mail.example.com.

; --- Email Authentication ---
@       IN TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
_dmarc  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:abuse@example.com; pct=100"

; --- Security ---
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 issuewild "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

; --- DNSSEC (Example keys - REPLACE WITH YOURS) ---
; DNSKEY records (usually auto-generated by DNS server when signing is enabled)
@       IN DNSKEY 257 3 13 ( ; KSK
        AwEAAbOv...QAB )
@       IN DNSKEY 256 3 13 ( ; ZSK
        AwEAAa3d...9QAB )

; RRSIG records are automatically generated by the DNS server during signing and are not manually added to the zone file.
; NSEC/NSEC3 records are also automatically generated.

; --- Additional Services (Example) ---
; SRV record for SIP service
_sip._tcp IN SRV 10 50 5060 sip1.example.com.

5. Step-by-Step Email Domain Setup (PTR, SPF, DKIM, DMARC)

Email setup is a complex task. Follow these steps to ensure maximum deliverability and spam protection.

Step 1: Configure A/AAAA for the Mail Server
Ensure your mail server has an A (and preferably AAAA) record.

mail.example.com. 3600 IN A 192.0.2.20

Step 2: Configure MX Records
Specify that mail for example.com should be delivered to mail.example.com..

example.com. 3600 IN MX 10 mail.example.com.

Step 3: Configure PTR (Reverse DNS)
This is the most important and often overlooked step. Contact your hosting provider or IP address owner (192.0.2.20) and request a PTR record pointing to mail.example.com..

  • Check: dig -x 192.0.2.20 +short should return mail.example.com..

Step 4: Configure SPF (via TXT)
Define which servers are allowed to send mail on behalf of example.com. Include your server and any third-party services (Gmail, SendGrid, etc.).

example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.20 include:_spf.google.com -all"
  • Start with ~all (softfail) for testing, then move to -all (hard fail).

Step 5: Configure DKIM

  1. Generate a key pair (private and public) on your mail server (MTA). Choose a “selector” (e.g., default, 202405).
  2. Configure the MTA to sign outgoing emails using the private key and the chosen selector.
  3. Publish the public key in DNS as a TXT record for the subdomain selector._domainkey.example.com..
    default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

Step 6: Configure DMARC
Define the policy for handling emails that fail SPF/DKIM checks and configure report sending.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
  • Deployment Strategy:
    1. Start with p=none β€” emails are not blocked, you only receive reports.
    2. Analyze reports, fix errors in SPF/DKIM.
    3. Move to p=quarantine β€” suspicious emails go to spam.
    4. Move to p=reject β€” suspicious emails are rejected.

Additional Tips:

  • Ensure the name your mail server sends in the HELO/EHLO command matches the name from the PTR record (mail.example.com.).
  • Use online tools to check your configuration: mail-tester.com, mxtoolbox.com, dmarcian.com.

6. Commands for DNS Checking and Debugging

Command-line tools are indispensable for administrators.

  • dig (Domain Information Groper) β€” the most powerful and recommended tool.
    • Basic Queries:
      • dig +short example.com A β€” get only the IPv4 address.
      • dig +short example.com AAAA β€” get only the IPv6 address.
      • dig +short example.com MX β€” get MX records.
      • dig +short example.com TXT β€” get TXT records (SPF, DKIM, DMARC).
      • dig +short www.example.com CNAME β€” get CNAME.
      • dig +short _sip._tcp.example.com SRV β€” get SRV record.
    • Reverse DNS:
      • dig -x 192.0.2.1 +short β€” get PTR for IP.
    • Delegation Tracing:
      • dig +trace example.com β€” shows the entire path from root servers to your zone’s authoritative servers. Great for diagnosing delegation issues.
    • Query to Specific Server:
      • dig @ns1.example.net example.com SOA β€” request SOA record from a specific name server.
    • DNSSEC Check:
      • dig +dnssec example.com A β€” perform a query with the DO (DNSSEC OK) flag and show RRSIG records if they exist.
      • dig +short example.com DNSKEY β€” get DNSKEY records.
      • dig +short example.com DS β€” get DS record (from parent zone).
    • TLSA (DANE) Check:
      • dig +short _443._tcp.www.example.com. TLSA
    • SSHFP Check:
      • dig +short example.com SSHFP
  • nslookup β€” old but still encountered tool.
    • nslookup -type=MX example.com
    • nslookup -type=TXT example.com
    • nslookup 192.0.2.1 (for PTR)
  • host β€” simple and convenient for basic queries.
    • host -t A example.com
    • host -t MX example.com
    • host -t TXT example.com
    • host 192.0.2.1 (for PTR)
    • host -t sshfp example.com

7. Security and Best Practices

  • DNSSEC: Enable DNSSEC for critical domains. This protects your users from fake DNS responses. Start with a test domain to master the procedure (key generation, publishing DS with the registrar). Use online validators for checking.
  • CAA: Always configure CAA records. This is a simple and effective way to prevent unauthorized certificate issuance for your domain. Specify only the CAs you use (e.g., letsencrypt.org).
  • DKIM Key Management: Regularly (e.g., annually) generate new DKIM key pairs. Publish the new public key in DNS, configure the MTA to use the new selector, and after a few weeks (ensuring all old emails signed with the old key are processed), delete the old TXT record.
  • Privacy: Do not publish HINFO records as they disclose hardware and software information that could be useful to attackers.
  • ANY Queries: Many public DNS resolvers (e.g., Google Public DNS, Cloudflare) no longer process ANY queries due to their use in DDoS attacks. Do not rely on them.

8. Common Mistakes and How to Avoid Them

  1. CNAME conflicts with other records: You cannot have a CNAME and, for example, an A or MX for the same name. Solution: Review your zone structure. Use A records or ALIAS/ANAME for apex.
  2. Missing PTR for mail server: This is the main reason mail ends up in spam. Solution: Always configure PTR with your hosting provider.
  3. Unchanged SOA Serial: If you don’t increment the serial number, secondary servers won’t learn about updates. Solution: Always increment Serial after any change to the zone. Automate this process if possible.
  4. Incorrect formatting of long TXT records: If a string is longer than 255 bytes and not split into parts, it may be truncated or cause an error. Solution: Always split long strings in TXT records, enclosing each part in quotes.
  5. Incorrect DS when enabling DNSSEC: If the DS record published with the registrar does not match your DNSKEY, the zone will become “untrusted,” and clients with DNSSEC enabled will not be able to get records from it. Solution: Carefully follow the instructions of your DNS server and registrar. Double-check hashes.
  6. High TTL before migration: If TTL is high (e.g., 86400), after changing the IP address, users will hit the old address for a day. Solution: Always reduce TTL a day or two before a planned migration.
  7. CNAME at apex domain: Direct use of CNAME for example.com. violates RFC and can cause unpredictable behavior. Solution: Use ALIAS/ANAME or CNAME flattening provided by your DNS provider.

9. Checklist Before Production Release or Migration

Use this list for final checks before launching or moving a site/service.

  • [ ] Basic Records: A/AAAA for all key hosts (web, mail) are configured and point to the correct IP addresses.
  • [ ] Mail: MX records are configured and point to hosts with A/AAAA records.
  • [ ] Reverse DNS: PTR records for all mail server IP addresses are configured and correct (verified via dig -x).
  • [ ] SPF: TXT SPF record is configured, includes all allowed sources, and has the correct termination mechanism (-all or ~all).
  • [ ] DKIM: Public key is published in DNS, MTA is configured to sign emails. Signature is verified on a test email.
  • [ ] DMARC: TXT DMARC record is published. For new deployments, it is recommended to start with p=none.
  • [ ] Name Servers: NS records in the zone match the servers specified with the registrar. glue records are configured if necessary.
  • [ ] SOA Serial: The serial number has been incremented after all recent changes.
  • [ ] CAA: CAA records are configured to restrict certificate issuance.
  • [ ] TTL: TTL was reduced in advance (if a migration was planned).
  • [ ] Check: Checks performed using dig +trace, dig MX, dig TXT, and online tools (e.g., MXToolbox).
  • [ ] DNSSEC (if enabled): DS record is correctly added with the registrar, DNSSEC checks pass successfully.
  • [ ] Backup: Current zone export is saved.
  • [ ] Rollback Plan: Steps for rolling back changes in case of failure are clearly written.
  • [ ] Monitoring: Monitoring systems are configured to track DNS server availability and zone changes.

10. Additional Examples and Field Explanations

  • SRV β€” Deep Dive:_xmpp-client._tcp.example.com. 3600 IN SRV 5 20 5222 xmpp1.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 5 30 5222 xmpp2.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 10 100 5222 backup.example.com.
    • The client will first contact servers with priority 5 (xmpp1 and xmpp2).
    • Between xmpp1 and xmpp2, selection will be proportional to their weight: xmpp1 has a 40% chance (20/(20+30)), xmpp2 β€” 60% (30/(20+30)).
    • The backup.example.com. server (priority 10) will only be used if both servers with priority 5 are unavailable.
  • TLSA β€” Example Decoding:_443._tcp.www.example.com. IN TLSA 3 1 1 d2abde...f21
    • 3 (DANE-EE): The client must use this exact certificate (or its public key), regardless of the CA trust chain.
    • 1 (Selector): The record stores the hash of not the entire certificate, but only its public key. This is more convenient because when reissuing a certificate with the same key, you don’t need to change the TLSA record.
    • 1 (Matching Type): SHA-256 hash is used.
  • SSHFP β€” Example Decoding:
    example.com. IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
    • 4: Algorithm β€” ED25519 (modern and secure).
    • 2: Digest type β€” SHA-256.
    • 356a19...28ab: SHA-256 hash of the ED25519 public key.

11. Useful Scenarios

  • Connecting a Website to a CDN:
    1. Usually, the CDN provider asks you to make a CNAME for a subdomain (e.g., www) to their address (e.g., example.cdnprovider.com).
    2. If you want to use the CDN for the root domain (example.com), use the ALIAS/ANAME or CNAME flattening feature of your DNS provider.
    3. Ensure the CDN is correctly configured to work with your SSL certificate (often the CDN takes over SSL termination). Accounting for CAA records is important in this case.
  • Moving a Host (Migration):
    1. 48-72 hours before migration: Reduce the TTL for your site’s A/AAAA records to 300 seconds.
    2. Wait: Wait for the old TTL to “propagate” (wait for a period equal to the old TTL, e.g., 3600 seconds).
    3. On migration day: Change the A/AAAA records to point to the new IP addresses.
    4. Check: Use dig +short example.com A with different public DNS (Google 8.8.8.8, Cloudflare 1.1.1.1) to check for change propagation.
    5. After stabilization (after 24-48 hours): Increase the TTL back to an optimal value (e.g., 3600).

12. Ready-to-Use JSON for Import into Provider Panel


Cloudflare:

{
  "zone_name": "example.com",
  "zone_type": "full",
  "records": [
    {
      "type": "A",
      "name": "@",
      "content": "192.0.2.10",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "AAAA",
      "name": "@",
      "content": "2001:db8::10",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "CNAME",
      "name": "www",
      "content": "example.com",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "MX",
      "name": "@",
      "content": "mail.example.com",
      "priority": 10,
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "@",
      "content": "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "_dmarc",
      "content": "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "content": "ns1.example.net",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "content": "ns2.example.net",
      "ttl": 3600
    },
    {
      "type": "SRV",
      "name": "_sip._tcp",
      "data": {
        "target": "sipserver.example.com",
        "port": 5060,
        "priority": 10,
        "weight": 60
      },
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "data": {
        "flags": 0,
        "tag": "issue",
        "value": "letsencrypt.org"
      },
      "ttl": 3600
    },
    {
      "type": "TLSA",
      "name": "_443._tcp",
      "data": {
        "usage": 3,
        "selector": 1,
        "matching_type": 1,
        "certificate": "<hex-of-cert-hash>"
      },
      "ttl": 3600
    },
    {
      "type": "SSHFP",
      "name": "@",
      "data": {
        "algorithm": 4,
        "digest_type": 2,
        "fingerprint": "d6f8..."
      },
      "ttl": 3600
    },
    {
      "type": "HINFO",
      "name": "@",
      "data": {
        "cpu": "INTEL",
        "os": "Linux"
      },
      "ttl": 3600
    },
    {
      "type": "LOC",
      "name": "@",
      "data": {
        "latitude": "37.7749N",
        "longitude": "122.4194W",
        "altitude": 30
      },
      "ttl": 3600
    },
    {
      "type": "RP",
      "name": "admin",
      "data": {
        "mbox": "admin.example.com",
        "txt": "Responsible person for the domain"
      },
      "ttl": 3600
    },
    {
      "type": "NAPTR",
      "name": "_sip._tcp",
      "data": {
        "order": 100,
        "preference": 10,
        "flags": "U",
        "service": "SIP+D2U",
        "regexp": "",
        "replacement": "_sip._udp.example.com"
      },
      "ttl": 3600
    },
    {
      "type": "DS",
      "name": "@",
      "data": {
        "key_tag": 12345,
        "algorithm": 8,
        "digest_type": 2,
        "digest": "<hex-digest>"
      },
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "data": {
        "flags": 256,
        "protocol": 3,
        "algorithm": 8,
        "public_key": "<base64-key>"
      },
      "ttl": 3600
    },
    {
      "type": "RRSIG",
      "name": "@",
      "data": {
        "type_covered": "A",
        "algorithm": 8,
        "labels": 1,
        "original_ttl": 3600,
        "signature_expiration": 1700000000,
        "signature_inception": 1690000000,
        "key_tag": 12345,
        "signer_name": "example.com",
        "signature": "<base64-signature>"
      },
      "ttl": 3600
    },
    {
      "type": "NSEC",
      "name": "@",
      "data": {
        "next_domain": "example.net",
        "types": ["A","AAAA","MX","TXT","NS"]
      },
      "ttl": 3600
    }
  ]
}
</base64-signature></base64-key></hex-digest></hex-of-cert-hash>

Route 53:

{
  "Comment": "Full DNS cheat sheet import",
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "A",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "192.0.2.10"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "AAAA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "2001:db8::10"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com.",
        "Type": "CNAME",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "MX",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "10 mail.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_dmarc.example.com.",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "NS",
        "TTL": 3600,
        "ResourceRecords": [
          {"Value": "ns1.example.net"},
          {"Value": "ns2.example.net"}
        ]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com.",
        "Type": "SRV",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "10 60 5060 sipserver.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "CAA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "0 issue \"letsencrypt.org\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_443._tcp.example.com.",
        "Type": "TLSA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "3 1 1 <hex-of-cert-hash>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "SSHFP",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "4 2 d6f8..."}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "HINFO",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"INTEL\" \"Linux\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "LOC",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "37.7749N 122.4194W 30m"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "admin.example.com.",
        "Type": "RP",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "admin.example.com Responsible person for the domain"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com.",
        "Type": "NAPTR",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "100 10 U SIP+D2U "" _sip._udp.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "DS",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "12345 8 2 <hex-digest>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "DNSKEY",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "256 3 8 <base64-key>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "RRSIG",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "A 8 1 3600 1700000000 1690000000 12345 example.com <base64-signature>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "NSEC",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "example.net A AAAA MX TXT NS"}]
      }
    }
  ]
}
</base64-signature></base64-key></hex-digest></hex-of-cert-hash>

Full support for all record types: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, TLSA, SSHFP, HINFO, LOC, RP, NAPTR, DS, DNSKEY, RRSIG, NSEC. TTL and priorities are already set and can be adapted as needed. Uses ResourceRecords for each record, as required by AWS.
Direct import via AWS CLI with the command:

aws route53 change-resource-record-sets --hosted-zone-id ZONE_ID --change-batch file://dns_records.json

Key takeaways:

  • Plan changes: Always reduce TTL before migration.
  • Test: Use dig, nslookup, and online tools to check every setting.
  • Security first: Configure SPF, DKIM, DMARC for email. Enable CAA to control certificates. Consider using DNSSEC for critical domains.
  • Document: Keep checklists and save zone backups.

This material is designed to be your universal reference. Save it, and it will help you solve any task related to DNS.

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *