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.

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

For more information about A records, see 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

For more information about AAAA records, see RFC-3596.

CAACAA

CAA (Certification Authority Authorization) specifies which certification authorities are 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 two values:

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

• TAG: String that consists of Latin characters and numbers and identifies the purpose of a record:

  • issue: Determines which certification authority is authorized to issue certificates for a zone or subzone.
  • issuewild: Determines which certification authority is authorized to issue certificates for a zone and all of its subzones (wildcard, *.example.com).
  • Contact information that the certification authority should use to notify zone owners about receiving a request to issue 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 handled 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 decides whether to 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

For more information about CAA records, see RFC-8659.

CNAMECNAME

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

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. For more information about CNAME records and their limitations, see 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 ANAME records with MX records in a second-level domain.

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 that defines host priority. The lower the value, the higher the host preference.
• 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.

For more information about MX records, see 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.

For more information about NS records, see 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.

For more information about PTR records, see RFC-1035.

SOASOA

SOA is a 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 larger 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. The default value is 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

For more information about SOA records, see RFC-1035.

SRVSRV

SRV is a record that specifies the hostname and port number of the server for a particular service. An SRV record must point to an A or AAAA record.

It consists of the following parts:

• Priority: 16-bit unsigned integer that defines host priority. The lower the value, the higher the host preference.
• Weight: 16-bit unsigned integer that specifies the weight for hosts with the same priority. The closer the field value is to 0, the less likely it is that this host will be selected. If the service is only running on a single host, set the field value to 0.
• Port: 16-bit unsigned integer that specifies the port used by the service.
• Target: FQDN of the host for the service.

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.

For more information about SRV records, see RFC-2782.

SVCB and HTTPSSVCB and HTTPS

SVCB is a record specifying the host name and port number of the server for a particular service. 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 that defines 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 name for the 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 higher the host preference.

• Target: FQDN of the host for the service.

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

• alpn (Application-Layer Protocol Negotiation): Specifies IDs and their 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 mandatory 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

For more information about SVCB records, see RFC-9460, 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 specifications, a ; indicates the beginning of a comment, meaning that any content following 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.

• A TXT record may not exceed 1,024 characters in length.

• 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 need to save the spaces, enclose the entire 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"

For more information about TXT records, see RFC-1035 and RFC-1464.

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 in which they were created:

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

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.