Resource records

A resource record is the main unit of information in a DNS. Using resource records, you determine where to route queries that come to specific domain names. Resource records have the following parameters:

• Domain name.
• Type of writes.
• Record time to live (TTL) in seconds before updating the record value.
• Record value.
• Record set description.

Cloud DNS uses record sets. A set may contain a single record or a collection of resource records with the same name and type but different values.

Sample record set:

Name	Type	TTL	Value
example.com.	A	600	192.0.2.1 192.0.2.2 192.0.2.3

You can update record sets by adding or deleting records.

Cloud DNS supports the following types of resource records.

AA

A resolves a domain name to an IPv4 address. For example, requesting the www.example.com A record should return an IPv4 address in xxx.xxx.xxx.xxx format.

Name	Type	TTL	Value
example.com.	A	600	192.0.2.1

Learn more about A records in RFC-1035.

AAAAAAAA

AAAA resolves a domain name to an IPv6 address. It works in a similar way to an A record.

Name	Type	TTL	Value
example.com.	AAAA	600	2001:db8::1

Learn more about AAAA records in RFC-3596.

CAACAA

CAA: Certification Authority Authorization, specifies certification authorities authorized to issue certificates for a particular zone and its subzones.

A record consists of the following parts:

• FLAG: Single-byte unsigned integer that may take these two values:

  • 0: Noncritical record. The certification authority may issue a certificate at its discretion.
  • 128: Critical record. The certification authority must not issue a certificate for an FQDN if the appropriate CAA record contains a critical property for an unknown or unsupported tag.

• TAG: String consisting of Latin characters and numbers representing the purpose of the record:

  • issue: Specifies the certification authority authorized to issue certificates for a zone or subzone.
  • issuewild: Specifies the certification authority authorized to issue certificates for a zone and all its subzones (wildcard, *.example.com).
  • Contact information the certification authority must use to notify the zone owner about receiving a request for a certificate in violation of the rules defined in CAA records:
    • iodef: Phone number, website, or email address in any format.
    • contactemail: Email address.
    • contactphone: Phone number.

  If the server fails to process an unknown tag, the flag value is parsed:

  • 0: The tag is ignored.
  • 128: Regardless of the value in the VALUE field, the record prohibits the issuance of certificates for the specified zone.

• VALUE: Record enclosed in double quotes, "". This field value is processed based on the tag value.

Name	Type	TTL	Value	Description
example.com.	CAA	600	128 issue "ca.example.net"	Only the ca.example.net certification authority is authorized to issue a certificate for the example.com zone
example.com.	CAA	600	0 issuewild "ca.example.net"	The ca.example.net certification authority may, at its discretion, issue certificates for the example.com zone and its subzones
example.com.	CAA	600	0 issue ";"	Certification authorities are not authorized to issue certificates for the example.com zone
example.com.	CAA	600	0 iodef "mailto:security@example.com"	If any of the conditions described in CAA records is violated, contact the owner of the example.com zone at security@example.com
example.com.	CAA	600	0 iodef "https://security.example.com/"	If any of the conditions described in CAA records is violated, contact the owner of the example.com zone at https://security.example.com

Learn more about CAA records in RFC-8659.

CNAMECNAME

CNAME: Alias for an FQDN. You can use CNAME records to access different services running on the same IP address. For example, CNAME records first.example.com and second.example.com may point to the same A record, host.example.com.

Name	Type	TTL	Value
first.example.com.	CNAME	600	host.example.com.
second.example.com.	CNAME	600	host.example.com.
host.example.com.	A	600	192.0.2.100

Note that CNAME records cannot be combined with other records in the same domain. Learn more about CNAME records and their limitations in RFC-1035.

ANAMEANAME

An ANAME record is similar to a CNAME record, but can be used in the same domain with other records. For example, you can use an ANAME record in a second-level domain along with MX records.

Name	Type	TTL	Value
example.com.	ANAME	600	example.com.website.yandexcloud.net
example.com.	MX	600	10 mx.example.com
example.com.	TXT	600	v=spf1 redirect=_spf.example.com
example.com.	TXT	600	v=DKIM1; k=rsa; t=s; p=

MXMX

MX is the name of an email processing server, e.g., mx.example.com.

A record consists of two parts:

• PREFERENCE: 16-bit integer setting the host priority. A lower value means higher priority.
• EXCHANGE: FQDN of the email processing host in the specified zone. This field value must point to an A or AAAA record.

Name	Type	TTL	Value
example.com.	MX	600	10 mx-primary.example.com.
example.com.	MX	600	50 mx-reserve.example.com.

Learn more about MX records in RFC-1035.

NSNS

NS is a record that stores the address of the name server in charge of the specified zone.

Name	Type	TTL	Value
example.com.	NS	600	ns1.example.com.
example.com.	NS	600	ns2.example.com.

Learn more about NS records in RFC-1035.

PTRPTR

PTR resolves an IP address to a domain name.

IP address	Type	TTL	Value
192.0.2.1	PTR	600	host1.example.com.
192.0.2.2	PTR	600	host2.example.com.

Learn more about PTR records in RFC-1035.

SOASOA

SOA: Record with basic information about a zone. It is created automatically.

It consists of the following parts:

• MNAME: Domain name of the server in charge of the zone. The default value is

  • ns.internal. for private zones.
  • ns1.yandexcloud.net. for public zones.

• RNAME: Domain name of the mail server in charge of the zone. The default value is mx.cloud.yandex.net..

• SERIAL: Unsigned 32-bit integer pointing to a zone copy number. When synchronizing data between DNS servers, the value in the SERIAL field is checked. The higher the value, the more recent the data. The default value is 1.

  Warning

  The Cloud DNS service does not change the SERIAL field value in SOA records when editing zone resource records. If you want to force updating the cache of the DNS servers storing your resource records data, increase the value in this field manually.

• REFRESH: Time, in seconds, between updates of information about zone resource records. The default value is 10800 (3 hours).

• RETRY: Time, in seconds, before retrying to update information about zone resource records if the previous attempt failed. Default value: 900 (15 minutes).

• EXPIRE: Time, in seconds, after which the zone will no longer be authoritative. The default value is 604800 (7 days).

• MINIMUM: Minimum TTL value, in seconds, for any resource record exported from the zone. The default value is 86400 (24 hours).

Name	Type	TTL	Value
example.com.	SOA	3600	ns1.yandexcloud.net. mx.cloud.yandex.net. 1 10800 900 604800 86400
example.com.	SOA	3600	ns.internal. mx.cloud.yandex.net. 1 10800 900 604800 86400

Learn more about SOA records in RFC-1035.

SRVSRV

SRV is a record specifying the host name and port of the server a particular service operates on. An SRV record must point to an A or AAAA record.

It consists of the following parts:

• Priority: 16-bit unsigned integer representing the host priority. A lower value means higher priority.
• Weight: 16-bit unsigned integer representing the weight of hosts of the same priority. The closer the value is to 0, the less likely it is that this host will be selected. If the service operates on one host only, set the field to 0.
• Port: 16-bit unsigned integer for the port the service is using.
• Target: FQDN of the host the service is on.

The client accesses the server with the lowest priority. If multiple servers have the same priority, the load is distributed according to the weight. Specify the server priority and the weight of records to distribute the load both between and within groups of servers.

Name	Type	TTL	Value
_sip._tcp.example.com.	SRV	600	10 70 8080 host.example.com.
_postgresql._tcp.example.com.	SRV	600	10 60 6432 pg-master.example.com.
_postgresql._tcp.example.com.	SRV	600	10 30 6432 pg-repl1.example.com.
_postgresql._tcp.example.com.	SRV	600	10 10 6432 pg-repl2.example.com.

Learn more about SRV records in RFC-2782.

SVCB and HTTPSSVCB and HTTPS

SVCB is a record specifying the host name and port of the server a particular service operates on. It provides the client with additional information on how to connect to the server.

HTTPS is a record that provides information about HTTPS connections. The HTTPS record is a variation of the SVCB record type.

It consists of the following parts:

• priority: 16-bit unsigned integer representing the host priority. When priority equals 0, the SVCB record is in AliasMode; otherwise, it is in ServiceMode.

  • AliasMode: SVCB record mode that creates an alias for target. It allows creating aliases in the zone's domain.
  • ServiceMode: SVCB record mode that specifies an alternative host name. The lower the priority value, the more preferred the host is.

• target: FQDN of the host the service is on.

• port: 16-bit unsigned integer for the port the service is using.

• alpn (Application-Layer Protocol Negotiation): Specifies IDs and associated transport protocols supported by the host.

  • no-default-alpn: Indicates that, by default, no additional protocols should be used for a secure connection to the specified host.

• ipv4hint and ipv6hint: Describe the IPs clients can use to access the service.

• echconfig: Indicates that the host supports Encrypted Client Hello.

• mandatory: Specifies the required keys for the record in addition to the existing ones.

Name	Type	TTL	Value
_1234._bar.example.com.	SVCB	300	1 svc1.example.net. ipv6hint=2001:db8::1 port=1234
_1234._bar.example.com.	SVCB	300	2 svc2.example.net. ipv6hint=2001:db8::2 port=1234
_8443._foo.api.example.com.	SVCB	7200	0 svc4.example.net.
svc4.example.net.	SVCB	7200	3 svc4.example.net. alpn=bar port=8004
svc2.example.net.	HTTPS	7200	1 . port=8002
example.net.	HTTPS	1800	1 . alpn=h3,h3-29,h2 ipv4hint=10.0.0.1 ipv6hint=::1

Learn more about SVCB records in RFC-9460 and RFC-9461.

TXTTXT

TXT is a free-form record that can store human-readable text or structured machine-readable data.

It is mostly used to verify:

• Domain ownership.

• Authenticity of email messages.

  • DMARC, RFC-7489
  • DKIM, RFC-6376
  • SPF, RFC-7208

TXT record implementation in Yandex Cloud DNS has the following special features and limitations:

• The service uses MASTER FILES format. According to the format specification, ; outside double quotes marks the beginning of a comment, i.e., all content that comes after it is ignored. If you want to use the ; character in a TXT record, enclose the string containing it in double quotes ("").

• The service supports a single TXT record.

• TXT records have a maximum length of 1024 characters.

• A TXT record can store multiple values. Enclose each one in double quotes ("") as needed.

• The space character serves as a separator. If an input string has spaces, it will be perceived as multiple strings.

  For example, we have the following string:

  Long string "string with spaces in quotes" #1 and_without_spaces
  

  When saving, this string will not change but will be processed as five strings:

  "Long"
  "string"
  "string with spaces in quotes"
  "#1"
  "and_without_spaces"
  

  If you have to keep the spaces, enclose the whole string in double quotes ("").

Name	Type	TTL	Value
example.com.	TXT	600	"v=DMARC1; p=none; sp=quarantine; pct=100; rua=mailto: dmarcreports@example.com;"
big-email._domainkey.example.com	TXT	6000	"v=DKIM1; p=76E629F05F70 9EF665853333 EEC3F5ADE69A 2362BECE4065 8267AB2FC3CB 6CBE"
example.com.	TXT	6000	"v=spf1 ip4=192.0.2.0 ip4=192.0.2.1 include:examplesender.email -all"

Learn more about TXT records in RFC-1035 and RFC-1464.

Automatic splitting of long TXT recordsAutomatic splitting of long TXT records

When creating a TXT record, the Cloud DNS API automatically splits long values into text chunks based on the existing split settings. A continuous sequence of characters without spaces or double quotes is treated as a separate chunk. Text enclosed in double quotes is also treated as a single chunk, even if it contains spaces.

Each chunk is processed separately:

• If a chunk is no longer than 255 characters, it is kept as is.
• If a chunk is longer than 255 characters, it is split into 255-character chunks from left to right. The last chunk contains the remaining characters and may be shorter.
• If the length of the original chunk is a multiple of 255, no additional empty chunk is created.

The data order is preserved, and the resulting chunks remain part of the same TXT record. No separate TXT records are created for these chunks. For example, a chunk of 300 characters is split into a 255-character chunk and a 45-character chunk, while a chunk of 510 characters, into two 255-character chunks.

The outer double quotes are part of the record format and are not counted toward the record length. If the original chunk was enclosed in double quotes, each resulting chunk is also enclosed in its own pair of double quotes. Spaces between chunks are used as delimiters and are not part of their content, while spaces inside quotation marks are considered part of the value.

If each existing chunk is no longer than 255 characters, the value remains unchanged, even if the total TXT record length exceeds 255 characters. The total length of the TXT record value is still limited to 1,024 characters.

Automatic splitting applies only to data before ; outside double quotes. Any comment after this character is not part the DNS record data and is not returned by the DNS resolver. ; inside double quotes is treated as a regular part of the value.

The chunk length limit is determined by the DNS format. According to RFC-1035, Section 3.3, the length of each chunk (character-string) is encoded in one octet, so a chunk can contain no more than 255 octets of data. For ASCII characters supported by the service, the limit is equivalent to 255 characters. However, Section 3.3.14 of RFC-1035 allows a single TXT record to contain multiple 255-character chunks. For comment processing rules, see RFC-1035, Section 5.1.

Service recordsService records

Some Yandex Cloud services use Cloud DNS resource records and allow you to create them. In the list of Cloud DNS resource records, such records are marked with icons of the services they were created in:

• Yandex API Gateway: ANAME record required to bind the domain to the API gateway and marked with the sign.
• Yandex Certificate Manager: CNAME record required to pass domain ownership verification and marked with the sign.
• Yandex Object Storage: ANAME record required to bind the domain to the bucket and marked with the sign.

You cannot modify service records and you can only delete one at a time. After you delete the resource for which the service resource record was created, you have to delete this resource record manually.

Use casesUse cases

• Transfer records
• Create a type A resource record
• Publishing game updates using Yandex Cloud CDN
• Configure the website DNS