DNS Record Types Reference

This page provides a comprehensive reference for every DNS record type you can manage in the YWT DNS manager. For instructions on adding and editing records, see Manage DNS records.

Record types at a glance

---

A record

Purpose: Maps a hostname to an IPv4 address. This is the most fundamental DNS record type and is how domain names resolve to web servers.

Fields:

Common use cases:

• Pointing your root domain (example.ch) to a web server.
• Pointing subdomains (app.example.ch) to specific servers.
• Pointing to a load balancer IP address.

Notes:

• You can have multiple A records on the same name for round-robin load distribution.
• A records cannot coexist with CNAME records on the same name.

---

AAAA record

Purpose: Maps a hostname to an IPv6 address. Functionally identical to an A record but for the IPv6 protocol.

Fields:

Common use cases:

• Providing IPv6 connectivity alongside A records for dual-stack hosting.
• Required by some hosting providers (e.g. GitHub Pages) for full connectivity.

Notes:

• AAAA records are optional but recommended if your server supports IPv6.
• Like A records, they cannot coexist with CNAME records on the same name.

---

CNAME record

Purpose: Creates an alias from one hostname to another. Instead of returning an IP address directly, the resolver follows the CNAME to the target hostname and resolves that instead.

Fields:

Common use cases:

• Pointing www.example.ch to a hosting provider's hostname.
• Setting up subdomains for external services (e.g. shop.example.ch to a Shopify domain).
• Domain verification for third-party services.

Notes:

• A CNAME record cannot coexist with any other record type on the same name. This is a fundamental DNS restriction. You cannot have a CNAME and an MX record on the same subdomain.
• CNAME records should not be used on the root domain (@). The root domain typically needs MX, TXT, and other records that conflict with CNAME.
• If you enter a CNAME at @, YWT converts it to an ALIAS-style record internally so it can be resolved at the zone apex.

---

HTTPS record

Purpose: Publishes HTTPS service binding information for a hostname. HTTPS records can advertise protocol support and alternate endpoints to compatible clients.

Fields:

Common use cases:

• Advertising HTTP/2 or HTTP/3 support.
• Service binding for modern hosting providers that request HTTPS records.

Notes:

• HTTPS records are advanced DNS records. Use the exact value provided by the service you are configuring.

---

MX record

Purpose: Specifies which mail servers should receive email for your domain. MX records include a priority value that determines the order in which servers are tried.

Fields:

Common use cases:

• Routing email to Google Workspace, Microsoft 365, ProtonMail, or any other email provider.
• Setting up primary and backup mail servers with different priorities.

Notes:

• The priority field determines failover order. If the server with priority 10 is unreachable, the sending server tries priority 20, and so on.
• MX record values must be hostnames, not IP addresses.
• You typically need multiple MX records for redundancy. See Email setup for provider-specific configurations.

---

TXT record

Purpose: Stores arbitrary text data associated with a hostname. TXT records are used extensively for domain verification, email authentication, and security policies.

Fields:

Common use cases:

Notes:

• You can have multiple TXT records on the same name for different purposes.
• You must only have one SPF record per domain. If you need to authorize multiple senders, merge them into a single v=spf1 ... ~all record with multiple include: directives.
• Long TXT values may need to be split into multiple 255-character strings. The YWT DNS manager handles this automatically.

---

NS record

Purpose: Delegates authority for a domain or subdomain to specific nameservers. NS records tell DNS resolvers which servers are authoritative for a given zone.

Fields:

Common use cases:

• Delegating a subdomain (app.example.ch) to a different DNS provider or hosting platform.
• Splitting DNS management across multiple providers.

Notes:

• NS records for the root domain (@) are managed by the registrar (YWT) and the registry. You cannot edit them in the DNS manager — use the domain settings to change nameservers.
• When delegating a subdomain, you typically add two NS records for redundancy.

---

SRV record

Purpose: Specifies the host and port for a particular service. SRV records enable service discovery by telling clients where to connect for protocols like SIP, XMPP, or LDAP.

Fields:

Common use cases:

• VoIP / SIP service discovery.
• XMPP (Jabber) chat server configuration.
• Microsoft Teams / Skype for Business federation.
• CalDAV and CardDAV autodiscovery.

Notes:

• SRV records follow a specific naming convention: _service._protocol.name. For example, _sip._tcp.example.ch.
• The weight field is used to distribute load between servers with the same priority. Higher weight means a larger share of traffic.

---

CAA record

Purpose: Specifies which Certificate Authorities (CAs) are permitted to issue SSL/TLS certificates for your domain. CAA records help prevent unauthorized certificate issuance.

Fields:

Common use cases:

Notes:

• If no CAA records exist, any CA can issue a certificate for your domain.
• If you use YWT hosting with automatic SSL, make sure your CAA records include letsencrypt.org (the CA that YWT uses).
• You can have multiple CAA records to authorize multiple CAs.

---

SOA record

Purpose: Defines the start of authority for a DNS zone. The SOA record contains administrative information about the zone, including the primary nameserver, the responsible email address, and timing parameters for zone transfers and caching.

Fields:

Notes:

• SOA records are managed automatically by YWT. You cannot create, edit, or delete them in the DNS manager.
• Every DNS zone has exactly one SOA record.
• The serial number is updated automatically whenever you make changes to your DNS records.

---

Quick reference: which record do I need?

For practical examples of common configurations, see Common DNS setups and the Guides section.