Detailed Guide to Configuring TTL for DNS Records

TTL of IP packets

In IPv4, TTL is an eight-bit IP header field. The TTL parameter is considered the upper bound on the lifetime of an IP datagram on the network. The TTL field is set by the sender of the packet and is reduced throughout the entire data transmission process, in accordance with the time spent in a given device, according to the processing protocol.

The main purpose is to prevent long delays when, for example, the router switches off during data transfer or the connection between two nodes is lost.

At each intermediate point (router), the TTL field value is decreased by 1 (this parameter changes) until the data packet reaches its destination.

Provided that the value on any of the involved nodes reaches 1, the data packet is destroyed, and a message is sent to the source server to retransmit the packet. In this case, an ICMP packet with code 11 - “Time interval exceeded” is sent to the sender. If the value is too small, the packet may simply not arrive; if it is too large, in case of a delay, the wait may take a long time (with a TTL value of 255 it reaches 4 minutes and 10 seconds).

The router does not allow packets with a TTL value of zero. This is done so that in the event of erroneous routing, the packet does not “walk” endlessly across the network, but is destroyed after some time.

How does the technology work?

When a packet of information is created and sent over the Internet, there is a risk that it will continue to move from router to router indefinitely. To reduce this possibility, packages are created with an expiration date called a time-to-live limit. The TTL packet can also be useful in determining how long it has been in circulation and allows the sender to obtain information about the packet's path over the Internet. Each packet has a place where it stores a numeric value that determines how long it should continue to travel through the network. Every time a router receives a packet, it subtracts one value from the TTL count and then forwards it to the next location on the network. If at any time the TTL counter is zero after subtraction, the router will discard the packet and send the ICMP message back to the originating host.

DNS TTL

DNS in TTL is a parameter responsible for using DNS zone records in server memory without additional changes. Upon reaching the set time, the caching server queries the DNS server containing the domain zone and information about it.

When using standard TTL settings, the update will occur on the server every other day. Before scheduled procedures, the first line of the entry should be changed to a value of 550 or less, then enter the serial number and reload the zones by updating the DNS server. After updating the data, you can begin to carry out the necessary procedures for migrating servers. Check using the dig command. After this, the IP addresses will be updated within the specified time.

After all data transfer procedures have been completed, the TTL value can be increased to reduce the load on the DNS server and avoid using a lot of traffic to update zones.

TTL - what is it and how does it work?

In HTTP, time to live represents the number of seconds that cached web content can be returned before a server request. The default value is determined by settings on the web server, but can be overridden by cache control tags that control which types of servers can cache data.

A packet is a fundamental unit of information transport in all modern computer networks and other communication networks. A router is an electronic device or network layer software that connects local or wide area networks and forwards packets between them.

Types of DNS records

A and AAAA

The A record associates a domain or subdomain with an IP address, allowing traffic to reach the site. This is the main function of DNS. A typical A entry looks like this:

example.com A 12.34.56.78 hello.example.com A 12.34.56.78

You can specify different subdomains on different IP addresses. If you need to point each example.com subdomain to an IP, you can use an asterisk (*) for the subdomain:

*.example.com A 12.34.56.78

Checking a domain for availability - how to do it?

The AAAA record is similar to the A record, but it is used for IPv6 IP addresses. A typical AAAA record looks like this:

The AAAA record is similar to the A record, but it is used for IPv6 IP addresses. A typical AAAA record looks like this:

AXFR

The AXFR record is used for DNS replication. Although there are more modern methods.

AXFR records are not used in regular zone files. They are most often used on a slave DNS server to replicate the zone file from the master DNS server.

CAA

DNS Certification Authority Authorization (CAA) uses DNS to allow the owner of a domain to specify which certificate authorities are allowed to issue certificates for that domain.

CNAME

A CNAME record (canonical name record) corresponds to a domain or subdomain. The CNAME record uses the DNS permissions of the target domain as the alias resolution. For example:

alias.com CNAME example.com. example.com A 12.34.56.78

When querying alias.com, the initial DNS lookup will find a CNAME record with the target example.com. A new DNS lookup of example.com will be launched, which will find the IP address 12.34.56.78. Visitors to alias.com will be directed to the IP address 12.34.56.78.

CNAME records are used to allow domains to have aliases. Some mail servers handle mail for domains with CNAME records in strange ways. Therefore, you should not use a CNAME record for a domain that accepts email.

MX records cannot reference hostnames defined by CNAME. The target domain for the CNAME record must also have normal A-record resolution.

Note

A CNAME record can be an effective way to redirect traffic from one domain to another while maintaining the same URL. But it doesn't work the same way as URL redirection. A CNAME record directs traffic for a specific domain to the IP address of the target domain. Once the user reaches this IP address, the server configuration will determine how the domain is handled. If this domain is not configured, the server will display the default web page. This may be the target domain's web page in the CNAME record, depending on how the server is configured.

DKIM

The DKIM record, also known as the DomainKeys Identified Mail record, displays the public key for authenticating messages that are signed using the DKIM protocol. This enhances email authentication capabilities. A typical DKIM entry looks like this:

selector1._domainkey.example.com TXT k=rsa;p=J8eTBu224i086iK

How to create gmail mail for your domain?

DKIM records are represented as text records. The entry must be created for a subdomain that has a unique selector for that key, followed by a dot (.) and _domainkey.example.com. Type -TXT, the value includes the key type followed by the actual key.

MX

An MX record sets the mail delivery destination for a domain or subdomain. A typical MX record looks like this:

example.com MX 10 mail.example.com. mail.example.com A 12.34.56.78

The above entries route mail for example.com to the mail.example.com server. Ideally, the MX record should point to a domain that is also the hostname of its server. If you are using a third party email service such as Google Apps, then you should use the MX records they provide.

Precedence is another component of MX records. This is the number written between the post type and the target server. In the example above, priority 10 is used.

Priority allows you to designate a backup mail server (or servers) for a specific domain. Smaller numbers have higher priority. An example of a domain that has two backup mail servers:

example.com MX 10 mail_1.example.com example.com MX 20 mail_2.example.com example.com MX 30 mail_3.example.com

If mail_1.example.com is down, the email will be delivered to mail_2.example.com. If mail_2.example.com is also down, mail will be delivered to mail_3.example.com.

N.S.

NS records establish nameservers for a domain. They are set for the domain at the registrar and in the zone file. Typical name server entries look like this:

example.com NS ns1.linode.com. example.com NS ns2.linode.com. example.com NS ns3.linode.com. example.com NS ns4.linode.com. example.com NS ns5.linode.com.

The name servers you assign to your registrar contain the zone file for the domain.

You can also set up different nameservers for any of the subdomains. These are set in your main domain's zone file:

mail.example.com NS ns1.nameserver.com mail.example.com NS ns2.nameserver.com

Primary name servers are configured at the registrar, and secondary name servers are configured in the main domain's zone file. The order of the NS records does not matter. DNS queries are sent randomly to different servers. If one host does not respond, another will be requested.

PTR

Whois domain history - 4 online services for searching archived information

A PTR record, or pointer record, maps an IP address to a domain or subdomain, allowing reverse DNS lookups to function. It works the opposite of the A record, in that it allows you to search for the domain associated with a specific IP address, rather than the other way around.

PTR records are usually installed on the hosting service. They are not part of the domain zone file.

To add a PTR record, you must create a valid A or AAAA record that specifies the IP address for the desired domain.

Note

You can use different IP addresses (including IPv4 and IPv6 addresses) that have the same domain set for reverse DNS. To do this, you must configure multiple A or AAAA records for this domain that point to different IP addresses.

SOA

An SOA record identifies a zone file with the name of the host on which it was created. Next, it indicates the contact email address of the domain administrator. A typical SOA entry:

@ IN SOA ns1.linode.com. admin.example.com. 2013062147 14400 14400 1209600 86400

Note

The administrator's email address is written with a period (.) instead of the @ symbol.

Here's what these numbers mean:

• Serial Number: The revision number of this domain's zone file. It changes when the file is updated.
• Update Time: The amount of time (in seconds) the secondary DNS server will store the zone file before checking for changes.
• Retry Time: The amount of time the secondary DNS server will wait before retrying the zone file transfer.
• Expiration Time: The amount of time the secondary DNS server will wait before expiring the current copy of the zone file if it fails to update itself.
• Minimum TTL: The minimum period of time that other servers must cache data from a zone file.

The name server mentioned in the SOA record is considered the primary name server for dynamic DNS. This is where changes to the zone file are made before they are propagated to other name servers.

SPF

The Sender Policy Framework (SPF) record contains a list of mail servers assigned to a domain or subdomain. This helps confirm the legitimacy of the mail server and reduces the likelihood of email headers being spoofed. Spammers often try to do this to bypass filters.

The domain's SPF record tells other mail servers which originating servers are valid sources of email. Therefore, they can reject fake mail from your domain sent from unauthorized servers. A simple SPF entry looks like this:

example.com TXT "v=spf1 a ~all"

In your SPF record, you need to list the mail servers from which you send mail, and then exclude the rest. Your SPF record will contain a domain or subdomain, a type (TXT or SPF if your nameserver supports it), and text (which starts with "v=spf1" and contains the SPF record settings).

Using this SPF record, the receiving server will check both the sending server's IP address and example.com's IP address.

Note

Make sure SPF entries are not too strict. If you accidentally exclude a legitimate mail server, emails received from it may be marked as spam.

We recommend visiting openspf.org to learn how SPF records work and how to create a record that suits your setup.

SRV

An SRV record maps a specific service running on a domain or subdomain to a target domain. This allows traffic destined for specific services to be directed to another server. Typical SRV entry:

_service._protocol.example.com SRV 10 0 5060 service.example.com

Description of the elements that are used in the SRV record:

• Service: The service name must be preceded by an underscore ( _ ) and a period ( . ). The service could be something like _xmpp.
• Protocol: The protocol name must begin with an underscore ( _ ) and end with a period ( . ). The protocol could be something like _tcp.
• Domain: The name of the domain that will receive source traffic for the service.
• Priority: The first number (10 in the example above) allows you to set the priority for the target server. You can set targets with different priorities, allowing you to have a backup server (or servers) for this service. Smaller numbers have higher priority.
• Weight: If two entries have the same priority, the weight is taken into account instead.
• Port: The TCP or UDP port on which the service is running.
• Target: Target domain or subdomain. It must have an A or AAAA record that resolves to the IP address.

An example of using SRV records is setting up federated VoIP.

TXT

A TXT record (text record) provides information about a domain to other Internet resources. One common use of a TXT record is to create an SPF record on nameservers that do not natively support SPF. Another use case is to create a DKIM record for mail.

Let me know what you think about this article topic in the comments. Thank you so much for your comments, responses, dislikes, likes, and subscriptions!

Please leave your opinions on the current topic of the material. For comments, dislikes, likes, subscriptions, responses, I bow to you!

Vadim Dvornikov is the author and translator of the article “DNS Records: An Introduction”

Bypassing blockages

The blocking is quite simple - you need to set the TTL on the connected devices, which will be exactly 1 more than that of the distributing phone. For example, you distribute the Internet to a laptop, then you need to set this device’s TTL to a value 1 greater than that of the distribution device (that is, 65). As a result, the packet from the computer reaching the phone will take the value 64. The operator will see that all packets are the same and will not block anyone.

NOTE! You can, of course, not reduce the TTL on the receiving device, but reduce it on the distributing device, but for this you will need ROOT rights and the TTL Master program. Therefore, it is easiest to change the value on secondary devices - more on this below.

But there is one more catch, which for some reason is not written about anywhere. The fact is that operators also began to calculate the distribution differently. The provider has a list of servers that can only be accessed from a computer.

For example, if a Windows update starts on a connected computer, the operator will immediately understand this. Because no one in their right mind would access Microsoft update servers from their phone. The list of such servers is constantly growing. But this problem is quite easily solved. On this occasion, we have detailed instructions for all operators on our portal:

• MTS
• Beeline
• YOTA

All the steps are described there with pictures and explanations. You can also determine and check your TTL, but in fact they have the same values ​​for all types of devices that I wrote about at the very beginning.

DNS server responses

DNS responses are of the following types:

1. An authoritative response comes from the servers that are responsible for the zone.
2. A non-authoritative response comes from servers that are not responsible for the zone (from caching servers).

The DNS response typically contains the following information:

• Header record - service information about the request.
• Request record - repeats the sent request.
• The response record is actually the response itself.
• Authoritative server records - information about the authoritative servers that store information for the current request.
• Additional information —additional records, such as NS server addresses.

The above is clearly confirmed by the dig utility:

[email protected] :~# dig ya.ru ; <<>> DiG 9.7.3 <<>> ya.ru (header section) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53499 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: (request section) ;ya.ru. IN A ;; ANSWER SECTION: (answer section) ya.ru. 4813 IN A 87.250.250.203 ya.ru. 4813 IN A 87.250.251.3 ya.ru. 4813 IN A 93.158.134.3 ya.ru. 4813 IN A 93.158.134.203 ya.ru. 4813 IN A 213.180.204.3 ya.ru. 4813 IN A 77.88.21.3 ya.ru. 4813 IN A 87.250.250.3 ;; AUTHORITY SECTION: (authoritative servers) ya.ru. 4813 IN NS ns1.yandex.ru. ya.ru. 4813 IN NS ns5.yandex.ru. ;; ADDITIONAL SECTION: (additional information - addresses of authoritative name servers) ns5.yandex.ru. 345565 IN A 213.180.204.1 ns1.yandex.ru. primary DNS name (Primary Name Server) 345565 IN A 213.180.193.1 ns1.yandex.ru. 3565 IN AAAA 2a0ua.em2:6emb8::1 ;; Query time: 7 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Jul 2 23:02:45 2011 ;; MSG SIZE rcvd: 238