DNS Info Zone

Domain Name System (DNS) explainedDomain Name System (DNS) explained

April 5, 2021| Daniel| 0 Comment | 8:09 am

Are you interested in the Domain Name System (DNS)? To get into this topic is like getting into another world—a tech one with its own rules and processes. If you are ready, just fasten your belt, and let’s go into DNS!

What is DNS?

DNS is a system, a naming database, for locating and translating Internet domain names into IP addresses. Think about it, like a directory or, more modernly, like your mobile’s contacts list where names and their corresponding numbers are correctly matched.

DNS directory is distributed worldwide, and it works daily, helping to search and reach the millions of existing domain names every day.

Domain Name System explained in details

What is DNS hierarchy?

(more…)

DNS Glue Records Explained: How They Prevent Delegation LoopsDNS Glue Records Explained: How They Prevent Delegation Loops

September 29, 2026| Daniel| 0 Comment | 5:10 am

DNS delegation tells recursive resolvers which authoritative name servers hold the answers for a domain. Usually, a resolver can look up the address of a delegated name server through ordinary DNS. A problem appears when the name server’s hostname is inside the very domain it serves: the resolver needs the domain’s authoritative server to find the server’s address, but it needs that address to reach the authoritative server.

DNS glue records break this circular dependency. The parent zone supplies the address information needed to contact the child name server along with the delegation. Glue is small, but incorrect or missing glue can make a correctly configured zone unreachable from parts of the Internet.

What is a DNS glue record?

A glue record is an A or AAAA address record placed in the parent-side delegation context for a child name server. It is not a separate DNS record type named “GLUE.” The term describes how the parent supplies address data that helps a resolver follow the referral to the child zone.

Consider a domain delegated to these servers:

example.com.  IN NS  ns1.example.com.
example.com.  IN NS  ns2.example.com.

Both name-server hostnames are inside example.com. Without their addresses, a resolver would have to ask the example.com authoritative servers where ns1.example.com is—but it cannot contact those servers until it knows the addresses. The parent zone avoids the loop by returning the NS referral plus A and, when configured, AAAA data for the child name servers.

This behavior belongs to the wider delegation process. The site’s DNS delegation guide explains how authority moves from a parent zone to a child. The ClouDNS article on DNS delegation provides another practical overview and appears here in the first half of this article.

When glue is required

In-bailiwick name servers

A name server is in-bailiwick when its hostname falls within the delegated namespace. For the delegation of example.com, ns1.example.com is in-bailiwick. The parent needs to provide its address as glue so a resolver can reach it without already resolving data from the child.

Out-of-bailiwick name servers

If example.com uses ns1.dns-provider.net, that server is outside the child domain. A resolver can follow the DNS hierarchy for dns-provider.net independently to find its address. The .com parent of example.com is not authoritative for that external hostname and generally does not need to supply glue for it.

This distinction is important because extra address data in a referral is not automatically authoritative. Resolvers apply bailiwick rules to decide which additional data can be accepted and cached safely.

Glue at the registrar and host records in the child zone

Operators commonly configure glue through a registrar feature named “child name server,” “host object,” “personal nameserver,” or “register nameserver.” This creates or updates the parent-side address association through the registry. It is different from merely adding an A or AAAA record in the domain’s own authoritative zone.

For an in-bailiwick server, both locations matter:

Parent-side glue: Lets a resolver reach the child authoritative server during delegation.
Child-zone A or AAAA record: Provides the authoritative address answer after the child server is reachable.

The values should be consistent. If the registry glue points to an old address while the child zone publishes a new one, resolvers may reach different servers depending on cached state and lookup path. Update both deliberately during a migration.

The article A record vs AAAA record explains the IPv4 and IPv6 address types used for name-server hostnames.

IPv4 and IPv6 glue

IPv4 glue uses A records, while IPv6 glue uses AAAA records. Publishing both can allow resolvers to reach authoritative service over either protocol, provided the DNS server and network actually work on both addresses.

Do not publish an IPv6 glue address merely because the server has an IPv6 interface. Test authoritative DNS over UDP and TCP on port 53 from outside the hosting network. A broken IPv6 path can introduce delays or intermittent resolution even when IPv4 works correctly.

Common glue-record failures

Glue is missing

The parent delegates to an in-bailiwick hostname but does not include its address. A resolver may be unable to escape the circular dependency, causing timeouts or SERVFAIL responses.

The address is stale

The authoritative server moved, but only the A or AAAA record in the child zone was changed. The parent continues directing resolvers to the old server through cached or live glue.

Parent and child NS sets disagree

The registry delegation lists servers that differ from the NS records served by the child zone. This does not always cause immediate failure, but it creates inconsistent authority and complicates caching and troubleshooting.

The server is reachable but not authoritative

Correct glue only provides an address. If the server at that address does not load the child zone or refuses public queries, the delegation is lame. Test that every listed server answers authoritatively for the domain.

Only one server or network works

Multiple NS names do not provide real redundancy when they resolve to one machine, one network path, or one unavailable location. Glue should describe an authoritative design that is actually reachable and resilient.

How to check DNS glue records

Start with a trace from the root toward the domain:

dig +trace example.com NS

At the parent referral, look for the delegated NS names and the associated A or AAAA records in the additional section. You can also query a parent server directly after identifying it:

dig example.com NS @a.gtld-servers.net
dig ns1.example.com A @a.gtld-servers.net
dig ns1.example.com AAAA @a.gtld-servers.net

The exact parent server depends on the top-level domain. Then query every delegated server directly:

dig example.com SOA @ns1.example.com
dig example.com NS @ns1.example.com
dig +tcp example.com SOA @ns1.example.com

Confirm that each server is reachable over UDP and TCP, returns an authoritative answer, serves the expected SOA serial, and publishes a child-side NS set consistent with the parent delegation.

Safely changing a glued name-server address

Prepare the new server. Load the complete zone and verify authoritative answers before changing delegation data.
Keep the old address active. Parent and resolver caches may retain the old glue until its TTL expires.
Update the child host object. Use the registrar or registry workflow to change the parent-side glue.
Update the child-zone address record. Make the A or AAAA record for the name server consistent with the new address.
Query the parent and child separately. Do not rely on a single recursive resolver or control-panel display.
Monitor during the cache window. Check availability, authoritative responses, and error rates from multiple networks.
Retire the old server only after verification. Allow enough time for cached referrals to expire.

If the servers use primary-to-secondary replication, also verify that zone synchronization continues after the address change. The article DNS Zone Transfers Explained covers AXFR, IXFR, and secure peer configuration.

Glue records and DNS security

Glue is necessary routing information, but it is not a substitute for DNSSEC, secure registrar access, monitoring, or server hardening. Protect the registrar account because unauthorized changes to host objects or delegation can redirect resolution. Use multi-factor authentication and change controls where available.

The parent-child delegation model and the reason address records may be required in referrals are described in RFC 1034, Section 4.2.1.

Conclusion

DNS glue records solve a specific circular dependency: they give resolvers the address of an in-bailiwick authoritative name server before the child zone can be reached. Reliable operation depends on consistent parent glue and child-zone address records, reachable authoritative servers, correct NS sets, and careful migration timing. A trace and direct queries to both parent and child servers are the fastest way to verify the complete delegation path.

DNS Zone Transfers Explained: AXFR, IXFR, and Secure ConfigurationDNS Zone Transfers Explained: AXFR, IXFR, and Secure Configuration

September 24, 2026| Daniel| 0 Comment | 5:09 am

Authoritative DNS must remain available even when one server is offline. A common design uses one primary server where administrators update the zone and one or more secondary servers that answer queries from synchronized copies. DNS zone transfers are the mechanism that keeps those copies current.

Two transfer types do most of the work: AXFR sends a complete zone, while IXFR sends incremental changes when both servers support it and suitable history is available. Used correctly, they improve resilience and reduce administrative duplication. Configured carelessly, however, they may expose a domain’s namespace or allow unauthorized systems to request sensitive zone data.

What is a DNS zone transfer?

A DNS zone is the administrative portion of the namespace served by a particular authority. It contains resource records and an SOA record with operational values, including a serial number. The primary server holds the editable source, while secondary servers maintain read-only copies received through zone transfer.

The distinction is covered in more detail in this guide to a Master DNS zone. The terminology “primary” and “secondary” describes where zone data is edited and replicated; it does not mean that clients must always prefer one authoritative server over another. Properly delegated authoritative servers can all answer public queries for the zone.

The role of the SOA serial number

The SOA serial number indicates which version of the zone a server holds. A secondary periodically checks the primary’s SOA record according to the refresh timer. If the primary has a newer serial, the secondary requests an update. Operators must increase the serial whenever zone content changes, otherwise a secondary may have no reason to retrieve the new version.

DNS NOTIFY speeds up synchronization

Waiting for the next refresh interval can delay propagation to secondary servers. DNS NOTIFY lets the primary signal that the zone has changed. The secondary then checks the SOA serial and initiates a transfer if necessary. NOTIFY accelerates the normal process; it does not replace serial comparison or authenticate the transfer by itself.

For a concise overview of zone files, primary and secondary zones, and both transfer modes, see the ClouDNS guide to DNS zone transfers.

AXFR: a complete zone transfer

AXFR transfers the full contents of a zone over a TCP connection. The response begins and ends with the zone’s SOA record, with the remaining records sent between them. A new secondary commonly uses AXFR for its initial copy because it does not yet have a local version from which to calculate changes.

A complete transfer is also useful when an incremental update cannot be produced, when the secondary’s copy is too old, or when administrators need to restore a known-good full version. The trade-off is efficiency: large zones consume more bandwidth and processing time when every record is sent after a small change.

IXFR: an incremental zone transfer

IXFR aims to send only the differences between serial versions. For a zone that changes frequently but has many stable records, that can substantially reduce transfer size. The primary needs access to the required change history, usually through a journal or equivalent mechanism, and the secondary must identify the version it currently holds.

IXFR is not guaranteed for every request. If the primary cannot build an incremental response from the requested serial, it may fall back to AXFR. Administrators should therefore permit and plan for full transfers even when IXFR is the routine path. Monitoring should measure both successful incremental updates and unexpected full-transfer frequency.

Why unrestricted transfers are risky

A public DNS server must answer ordinary queries, but it usually should not give an arbitrary requester a complete inventory of the zone. An unrestricted AXFR can reveal hostnames and records that make reconnaissance easier. Public records are not automatically secret, yet a convenient bulk listing may expose naming patterns, forgotten systems, infrastructure roles, or records that were published unintentionally.

The greater operational risk is accepting transfers or updates from an unauthorized peer. A secure design identifies exactly which servers may exchange data and verifies that the messages came from a trusted party. Network restrictions help, but cryptographic authentication is stronger than relying only on a source IP address.

How to secure DNS zone transfers

Allow only approved secondary servers

Configure the primary with an explicit allow-list for the IP addresses of authorized secondary servers. Do not use a broad network range unless every host in that range is trusted for zone access. On the secondary, specify the intended primary addresses rather than accepting data from arbitrary systems.

Authenticate transfers with TSIG

Transaction Signatures, or TSIG, use a shared secret and a keyed message authentication code to authenticate DNS messages. When both peers are configured with the same protected key, TSIG helps verify message origin and integrity. Use a modern supported algorithm, unique keys where practical, strict file permissions, secure key distribution, and a documented rotation process.

Protect the transport path when confidentiality matters

TSIG authenticates messages but does not encrypt the zone contents. If the network path is not trusted and confidentiality is required, place the transfer inside an appropriately secured private network, VPN, or other protected channel supported by the architecture. Firewall rules should restrict DNS transfer connections as an additional layer, not as the only control.

Separate public and private namespaces

Do not publish internal-only records in a public zone merely because transfers are restricted. Split-horizon designs and separate internal zones can limit exposure, but they require careful operational ownership. Confirm that every authoritative server serves the intended view and that transfer policies match each view.

Reliable primary and secondary operation

Secondary DNS provides more than a backup file. Multiple authoritative servers can improve availability, distribute query traffic, and reduce dependence on a single network or location. This overview of Secondary DNS explains the broader role of replicated authoritative service.

Operational resilience depends on timers as well as transfers. The SOA refresh value controls how often secondaries check for changes, retry determines when to try again after failure, and expire specifies how long a secondary may continue serving the zone without contacting its source. Values should fit the change rate and recovery objectives rather than being copied blindly from another domain.

Monitoring and troubleshooting checklist

Compare SOA serials. Query each authoritative server directly and confirm that the serials converge after a change.
Review transfer logs. Look for refused requests, authentication failures, unexpected AXFR fallbacks, timeouts, and transfers from unapproved addresses.
Test from the secondary. Confirm network reachability to the primary over TCP and verify that firewalls, access lists, and TSIG names match.
Check NOTIFY handling. Make sure notifications reach the intended servers and trigger a serial check rather than being silently discarded.
Alert on stale data. Detect secondaries that lag behind the expected serial before the SOA expire timer becomes critical.
Audit access regularly. Remove retired secondary addresses and unused keys, then test that unauthorized AXFR requests are refused.

External checks should also verify that every delegated nameserver answers consistently. The existing guide to DNS monitoring outlines useful availability and consistency signals beyond the transfer logs themselves.

The protocol behavior and interoperability requirements for full transfers are specified in RFC 5936: DNS Zone Transfer Protocol (AXFR).

Conclusion

AXFR and IXFR keep authoritative DNS servers synchronized: AXFR supplies a complete copy, while IXFR can deliver smaller incremental changes. A dependable deployment combines correct SOA serial management, NOTIFY, explicit peer restrictions, TSIG authentication, protected key handling, and monitoring for stale or unexpected transfers. These controls preserve the availability benefit of secondary DNS without offering the full zone to unauthorized systems.

DNS TTL Explained: How to Choose the Right Cache TimeDNS TTL Explained: How to Choose the Right Cache Time

September 19, 2026| Daniel| 0 Comment | 5:02 am

Every DNS record includes a setting that influences how long other systems remember its answer. That setting is the Time to Live, or TTL. It is measured in seconds and tells recursive resolvers how long they may keep a cached DNS response before asking an authoritative DNS server for fresh data.

TTL affects much more than perceived “DNS propagation.” It shapes query volume, response speed, change management, failover behavior, and the load placed on authoritative infrastructure. The best value is therefore a balance: long enough to benefit from caching, but short enough to support the domain’s operational needs.

What happens during the DNS TTL lifecycle?

When a recursive resolver receives a record from an authoritative server, it stores the result together with its TTL. The remaining lifetime counts down while the answer sits in cache. If another user asks for the same record before the timer expires, the resolver can answer from cache without repeating the full lookup.

After the cached value expires, the resolver must obtain an updated answer. This normal caching process is part of the broader resolution flow described in Domain Name System (DNS) explained.

TTL does not instruct every resolver to update at the same instant, and it does not push a new record across the Internet. Different caches learn about a record at different times, so they also expire at different times. Some clients may already have the new answer while others still legitimately use the previous cached value.

Why a longer TTL can be useful

A longer TTL allows recursive resolvers to reuse answers for more time. This provides several practical advantages:

Fewer authoritative queries. More requests are answered from recursive caches, reducing traffic to authoritative DNS servers.
Efficient lookups. A cached response avoids repeating the full resolution path and is usually returned quickly.
Resilience during brief problems. Previously cached records may remain available to users while an authoritative server experiences a short interruption, provided the cached TTL has not expired.
Predictable operation for stable records. Records that rarely change do not need to be refreshed every few minutes.

The tradeoff is slower adoption of planned changes. If an A or AAAA record has several hours remaining in cache when its authoritative value changes, clients behind that resolver may continue using the old address until the timer reaches zero.

Why a shorter TTL is not always better

A short TTL can make changes visible sooner after cached answers expire, which is useful during a migration or for some automated failover designs. It also causes resolvers to query authoritative servers more frequently. At scale, that can increase DNS traffic and make the quality and geographic reach of the authoritative service more important.

Short values do not guarantee instant switching. Applications, operating systems, local forwarders, browsers, and recursive resolvers can each participate in caching. A low TTL also cannot help clients that already received a longer value before it was reduced. Operational planning matters as much as the final number.

Practical TTL ranges for common situations

There is no universal value that fits every record and every domain. The following ranges are useful starting points, not strict rules:

Stable website records: 3,600 to 14,400 seconds can provide a reasonable balance when the destination changes infrequently.
Planned migration: 300 to 900 seconds can reduce the cache window during the change. Lower the TTL early enough for the previous, longer value to expire before migration begins.
DNS-based failover: 60 to 300 seconds may support faster refreshes, but only when monitoring, authoritative capacity, and recovery procedures are designed for the higher query rate.
Stable infrastructure records: Values from several hours to a day may be appropriate when the records are carefully managed and rarely changed.

For example, changing a TTL from 86,400 seconds to 300 seconds five minutes before a migration is too late for resolvers that already cached the one-day value. Reduce it at least one full old-TTL period before the planned change. After the migration is confirmed, restore an efficient steady-state value rather than leaving an unnecessarily short TTL forever.

TTL planning for failover and monitoring

TTL is only one part of a failover design. A system must detect the problem, decide whether a change is safe, update the authoritative record, and allow cached answers to expire. A very short TTL cannot compensate for slow detection or an unreliable update process.

This is why DNS monitoring should test both availability and correctness from multiple locations. Teams should also measure authoritative query volume before adopting very short values.

Redundant authoritative infrastructure addresses another part of the problem. A secondary server can continue answering for a zone if the primary becomes unavailable. The architecture and terminology are covered in Get familiar with Secondary DNS. Record TTLs and secondary DNS serve different purposes, but both belong in a complete resilience plan.

Common DNS TTL mistakes

Reducing the TTL too late

The previous TTL remains relevant until every cache holding that response has had time to expire. Schedule the reduction before the maintenance window, not at the moment of the record change.

Using one value for every record

Records have different change patterns and risks. A frequently updated service endpoint may need a shorter value than stable nameserver or verification records. Choose TTLs according to how each record is operated.

Leaving emergency values in place

Teams often reduce TTLs for a migration and forget to raise them afterward. This creates continuous extra query traffic without an ongoing operational benefit.

Treating TTL as a security control

TTL controls cache duration; it does not authenticate an answer or encrypt a query. DNSSEC, protected account access, change auditing, resilient authoritative service, and encrypted transports address separate security concerns.

A simple decision process

Identify how frequently the record changes during normal operation.
Define how quickly users must receive a new answer during a planned change or failure.
Estimate whether the authoritative service can handle the resulting query rate.
Lower the TTL in advance of maintenance and wait for the old cache window to pass.
Monitor the change from multiple networks and restore the steady-state TTL afterward.

For a broader operational checklist, see DNS best practices. The original DNS protocol specification defines the TTL field and caching behavior in RFC 1035: Domain Names—Implementation and Specification.

Conclusion

A well-chosen DNS TTL supports both efficiency and controlled change. Longer values reduce repeated authoritative lookups, while shorter values narrow the cache window when records must change quickly. The right approach is to use stable defaults, lower values deliberately before planned work, monitor the results, and return to an efficient setting when the event is complete.

DNS monitoring – Everything you need to knowDNS monitoring – Everything you need to know

July 26, 2022| Daniel| 0 Comments | 11:36 am

The meaning of DNS monitoring

Your network monitoring system’s DNS monitoring is an essential component. Its goal is to ensure users can access the website or service they are using securely and dependably. In order to ensure optimal performance, DNS monitoring entails monitoring all Domain Name System activity.

DNS monitoring is beneficial for quickly discovering problems, spotting potential security breaches, and stopping malicious assaults. It necessitates locating DNS outages and regularly checking DNS records for unexpected changes. If an issue is discovered that could harm your website or business, it can be rectified immediately.

(more…)

Reverse DNS: Meaning & ImportanceReverse DNS: Meaning & Importance

April 11, 2022| Daniel| 0 Comment | 8:30 am

Reverse DNS is our topic today. So, in this article we will take a detailed look at what its main purpose is and how to check it. So let’s start.

Reverse DNS – meaning

Here it is – Reverse DNS or rDNS for short. Its goal is to connect an IP address to the domain name with which it is linked. It works in the opposite direction as Forward DNS, with the domain name pointing to the related IP address. DNS hosting firms often offer rDNS as an add-on option. If you do decide to use it, you must also set up a Master Reverse zone and PTR records. Because of them, you will be able to produce proof that the precise IP address and your domain name match.

(more…)

Get familiar with Secondary DNSGet familiar with Secondary DNS

January 31, 2022| Daniel| 0 Comment | 6:57 am

Using the Secondary DNS to preserve a trustworthy copy of your data is an excellent idea. You’ve probably come to this post because you’ve heard about it and want to increase the reliability of your DNS. Yes, secondary DNS is really beneficial for providing peace of mind, especially in the current world where DDoS attacks and other DNS issues are so common. Let’s clarify things a bit more and go through the details.

DNS zone – the definition

To handle the DNS namespace more accurately, the DNS server can hold a large number of zones. The DNS zone is a part of that namespace. It’s an area where you can find more organized and controllable DNS components. It would be best to direct your domain to various servers, such as mail servers, web servers, and so on, to function effectively and precisely. You can create additional DNS records in the DNS zone to perform this task. The DNS zone is where you’ll save all of your DNS records.

(more…)

DNS PTR record explainedDNS PTR record explained

October 19, 2021| Daniel| 0 Comment | 6:46 am

DNS PTR record – What is it?

DNS PTR record is a type of DNS record, which is oftentimes called pointer record. This is because it helps to associate an IP address to a domain name. The goal is to show that the specific IP address is actually related to the domain name. If somebody is checking it, this record proves that there is no scam. With the DNS PTR record it is easy to validate the different elements or additional services, such as a mail server.

Looking for more information? Take a look at this fantastic about the DNS PTR record!

(more…)

Nslookup command – five easy examplesNslookup command – five easy examples

September 29, 2021| Daniel| 0 Comments | 5:42 am

Nslookup command explained

The Nslookup command is a commonly used tool with a command-line interface. Usually, it is applied for DNS probing. Nslookup command is perfect if you want to check a domain name, its IP address, and various DNS records. The great benefit is that it is typically pre-built on almost every OS. Additionally, the Nslookup command presents clean and straightforward answers.

(more…)

Traceroute command explainedTraceroute command explained

September 2, 2021| Daniel| 0 Comment | 10:38 am

If you want to know everything about the traceroute command, you came to the right place. Here you will learn what is it, why to use it and how.

Traceroute command explained

Traceroute command, just like the rest of the popular network commands, is a simple small software with command-line interface (CLI) and comes built-in on most Linux distros, BSD distros and even macOS.

It is easy to understand its purpose, to trace the route of a query, from your computer, through all the routers (hops) on the way, to the target that you set.

The result will be data on each hop (host name and IP address), showing if the packets of data arrive and after what amount of time, and which was the next hop.

Traceroute options for Windows, Linux, and macOS

(more…)

What is DNS branding, and why is it useful?What is DNS branding, and why is it useful?

August 17, 2021| Daniel| 0 Comment | 10:46 am

DNS branding is a feature that many hosting providers love to read on the page of a DNS provider. That means that they will have an easy way to put their tag on and expand their services by providing DNS services to their clients without the obligation to mention the DNS provider.

It also serves big companies to hide the original DNS provider and show their brand name instead.

What is DNS branding?

DNS branding is a service that a DNS provider offers that gives the freedom to the client to put their domain name instead of the provider’s domain name for the nameservers.

Advantages of using DNS branding

(more…)