--- id: "dns-record" kind: "glossary-term" title: "DNS record" language: "en" category: "DNS and technical foundations" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/glossary/dns-record/" translations: es: "https://tldlog.com/es/glosario/registro-dns/" de: "https://tldlog.com/de/glossar/dns-record/" fr: "https://tldlog.com/fr/glossaire/enregistrement-dns/" it: "https://tldlog.com/it/glossario/record-dns/" pt-BR: "https://tldlog.com/pt/glossario/registro-dns/" ru: "https://tldlog.com/ru/glossariy/zapis-dns/" zh-Hans: "https://tldlog.com/zh/cihui/dns-jilu/" --- # DNS record A single entry in a DNS zone. It has a name, a type such as A, MX or TXT, a TTL and the data itself, for example an IP address. All records with the same name and type form a set that is always answered and signed together. A DNS record is one entry in a domain's DNS zone. Each record answers one question about a name, such as which server hosts the website or where email should go. Domain owners usually edit a few records through their DNS provider, and one wrong record can stop a website or email from working. ## What a DNS record is: name, type, TTL and data Every record has the same parts: the name it belongs to (such as `www.example.com`), a type (A, MX, TXT and so on), a TTL and the data itself, such as an IP address. The TTL is the number of seconds a resolver may keep the answer before asking again. It is a maximum, not a promise. After a change, some users keep seeing the old value until the old TTL runs out, which is what people informally call DNS propagation. Records with the same name and type form a resource record set (RRset). A query always returns the whole set, all its records must have the same TTL, and DNSSEC signs the set as a unit. ## The records most owners need: A, AAAA, CNAME, MX and TXT - **A** points a name to an address in Internet Protocol version 4 (IPv4). Several addresses mean several A records. - **AAAA** does the same for the newer, longer version 6 (IPv6). - **CNAME** makes a name an alias of exactly one other name, and the lookup restarts there. No other data may sit at an alias, except DNSSEC records. - **MX** names a domain's mail servers, each with a preference number; lower numbers are tried first. The target must be a real host name, never an alias. With no MX at all, sending servers fall back to the domain's A or AAAA records. A domain that takes no mail can publish a "null MX": preference 0 and a single dot as target. - **TXT** holds text whose meaning depends on where it is published. Services often ask for a TXT value to prove control of a domain. SPF must be published as TXT, with only one SPF record per name. A DMARC policy is a TXT record at `_dmarc.example.com`. ## Records that run the zone: NS and SOA NS records list a zone's authoritative name servers. They sit at the top of the zone and also in the parent zone, such as the TLD zone, where they mark the delegation and tell resolvers where to ask next. They must point to real host names, not aliases. Each zone has exactly one SOA (start of authority) record, at the top. It holds the primary server, the responsible person's mailbox, a serial number and timers in seconds. Secondary servers fetch new data only when the serial increases. Its MINIMUM field, with the SOA's own TTL, now sets how long "does not exist" answers are cached. DNS providers usually manage the SOA for their customers. ## Specialized records: SRV, PTR, CAA, HTTPS and wildcards - **SRV** gives the server and port for a service, under a name such as `_service._protocol.example.com`. Clients try the lowest priority first and share load by weight. The target must not be an alias. - **PTR** maps an address back to a name. Reverse records live under in-addr.arpa (IPv4) and ip6.arpa (IPv6), zones that follow the structure of IP addresses, not domain names, so they are not set in a domain's own zone. Operational advice says PTR and A records should match. - **CAA** (Certification Authority Authorization) lists the certification authorities that may issue certificates for a name. Authorities that follow the standard must check it before issuing, climbing to parent names if needed, so a CAA set at example.com also covers `www.example.com` if www has none. Browsers must not use it to validate certificates. - **SVCB and HTTPS** tell clients, before they connect, which servers, protocols and ports to use. HTTPS is the web version; the name refers to the record type, not the protocol. - **Wildcards** start with the label `*`, as in `*.example.com`. They answer only for names that do not exist at all, only with the types they hold, and not for names below themselves. As of October 2026, ICANN's base Registry Agreement, approved on 21 January 2024, forbids gTLD registries to use wildcards or any other method to answer for unregistered names: such queries must return NXDOMAIN. ## Why a CNAME cannot sit at the bare domain, and ALIAS workarounds The bare domain (the zone apex) must hold the SOA and NS records, and a CNAME cannot share its name with other data. A CNAME there conflicts with them: some servers then ignore the NS records, and the domain stops working. The standard answer is A and AAAA records at the bare domain. An HTTPS record in "AliasMode" can also point the bare domain to another name, but clients that do not support it ignore it, so the A and AAAA records must stay. Many DNS providers offer their own feature, called ALIAS, ANAME or CNAME flattening: the provider looks up the target and answers with its addresses. As of October 2026 these features are proprietary. The draft to standardize ANAME expired, and IANA's registry of record types has no ALIAS or ANAME type. Behavior differs, which makes changing provider or using several harder. ## Common mistakes when editing records and how to check them - Leaving out the final dot of a full name in a zone file, so the zone name is added: `mail.example.com.example.com`. - A CNAME next to other records, or at the bare domain. - An MX, NS or SRV record pointing to a CNAME. - Two SPF records at the same name. - Not raising the SOA serial when editing a zone file by hand. - CNAMEs left pointing to a removed host, or CNAMEs pointing to CNAMEs. - Lowering a TTL only after a change: caches can keep the old answer for up to the old TTL. After every change, query the record with a lookup tool such as `dig`. Asking the authoritative server directly shows the new value regardless of caches. When unsure which records a service needs, check with the DNS provider. ## Sources - [Domain names - implementation and specification (RFC 1035)](https://www.rfc-editor.org/rfc/rfc1035.txt) - [Clarifications to the DNS Specification (RFC 2181)](https://www.rfc-editor.org/rfc/rfc2181.txt) - [Common DNS Operational and Configuration Errors (RFC 1912)](https://www.rfc-editor.org/rfc/rfc1912.txt) - [Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) (RFC 9460)](https://www.rfc-editor.org/rfc/rfc9460.txt) - [Address-specific DNS aliases (ANAME), draft-ietf-dnsop-aname-04](https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/) ## related terms - [zone file](https://tldlog.com/glossary/zone-file/) - [TTL](https://tldlog.com/glossary/ttl/) - [A record](https://tldlog.com/glossary/a-record/) - [SOA record](https://tldlog.com/glossary/soa-record/) - [RRSIG](https://tldlog.com/glossary/rrsig/)