Edge DNS

Edge DNS is a domain hosting service that is part of Azion’s traffic routing solution. With Edge DNS, your domains are hosted on Azion’s global infrastructure using the same performance and security solutions built for other Azion products, combining request optimization techniques with protection against Distributed Denial of Service (DDoS) attacks.

Edge DNS works as an authoritative DNS solution that allows customers to manage their domains, zones, and records directly from Azion Console. It’s designed for customers who need high performance and high availability for their domain hosting.

Implementation

Scope	Source
Main settings	How to configure Edge DNS main settings
Dig command	How to look up DNS servers with the dig command
Traceroute command	How to diagnose performance and delivery issues with the traceroute command

Domain Name System (DNS)

As the name implies, it’s a domain name resolution system. It translates your site’s domain name into an Internet Protocol (IP) address so a connection can be established with the destination that will provide the requested content.

It’s the DNS that allows you to type in a domain name instead of a string of numbers. In other words, DNS translates the string of numbers (IP) of the domain you want to access into words that form the URL you know.

After configuring Edge DNS, you can test if your zone is processing your information.

Go to test zone guide

Edge DNS Records

Go to add records guide

Zone Name

Identifier for the newly created Record.

This description is the domain that you want to create. For example: manager in console.azion.com.

Type

This is the type of record that is being added, such as types A, AAAA, MX, or CNAME, among other examples. You can create ANAME type entries, which allow you to host and use naked domains with other Azion products.

Supported DNS Records Types

To provide record creation, Edge DNS supports the following types of DNS entries.

Type	Description	Reference
A (IPv4 Address)	Address Mapping record (A Record), also known as a DNS host record, stores a hostname and its corresponding IPv4 address.	RFC1035
AAAA (IPv6 Address)	IP Version 6 Address record (AAAA Record) stores a hostname and its corresponding IPv6 address.	RFC3596
ANAME (Maps a name to another name)	ALIAS record is a virtual record type created to provide CNAME, like behavior on apex domains.	draft-ietf-dnsop-aname-04
CAA (Certification Authority Authorization)	A CAA record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain or subdomain.	RFC8659
CNAME (Canonical name)	Canonical Name record (CNAME Record) can be used to alias a hostname to another hostname. When a DNS client requests a record that contains a CNAME, which points to another hostname, the DNS resolution process is repeated with the new hostname.	RFC3658
DS (Delegation Signer)	In the DNSSEC’s Chain of Trust, it indicates that the delegated zone can be trusted, by storing the hashed DNSKEY of its KSK (Key-Signing Key).	RFC1035
MX (Mail exchange)	Mail exchanger record (MX Record) specifies an SMTP email server for the domain, used to route outgoing emails to an email server.	RFC1035 e RFC7505
NS (Name Servers)	NS-records identify the DNS servers responsible (authoritative) for a zone. A zone should contain one NS-record for each of its own DNS servers (primary and secondaries).	RFC2782
PTR (Reverse DNS lookup)	PTR records are used for the Reverse DNS (Domain Name System) lookup. Using the IP address, you can get the associated domain/hostname. An A record should exist for every PTR record. The usage of a reverse DNS setup for a mail server is a good solution.	RFC1035
SRV (Location of server or service)	A Service record (SRV record) is a specification of data in the Domain Name System defining the location. For example: the hostname and port number, of servers for specified services. It’s defined in RFC 2782, and its type code is 33.	RFC2782
TXT (Text)	A TXT record is a type of resource record in DNS used to provide the ability to associate arbitrary text with a host or other name, such as human-readable information about a server, network, data center, or other accounting information.	RFC1035 e RFC1464

Value

This is the DNS response to the registered record. For example, an IPv4 address.

TTL (seconds)

This is the time, in seconds, that a DNS response can be cached by a resolver. When the TTL expires, the resolver discards the cached response and queries the authoritative nameserver again for a fresh answer.

Policy

It allows you to specify which policy Edge DNS should consider while resolving requests answered by this record entry.

You can select either Simple Policy (to use the standard DNS functionality) or Weighted Policy (to specify the amount of traffic to send to each Record).

By choosing the Weighted Policy, there’ll be two more fields to be completed, which are:

Weight: you can choose a number between 0 and 255 to specify the weight for each record. When you choose 0, Edge DNS stops using this record.
Description: used to differentiate records with the same Name and Type.

From this point on, this set of information will be synchronized with the Edge DNS service. Your settings are saved and distributed to the Azion network practically in real time.

Your domain is now set up and ready to be served by Azion Edge DNS. To make sure everything is working well, run some of the tests described in the test zone guide.

Record Policies

While you are adding or modifying a record on Edge DNS, you will find the “Policy“ field. This field is enabled just when you are configuring either A, AAAA, CNAME, ANAME or MX type records. This field lets you to choose between two policies to specify how Edge DNS should deal with requests answered by this record.

Simple Policy

By selecting simple policy, Edge DNS uses the standard DNS records behavior, routing all the traffic to the specified addresses in the “Value” field.

Weighted Policy

By selecting weighted policy, Edge DNS allows you to create multiple records with the same Name and Type, enabling you to specify a Weight that defines how much traffic should be routed to each record. This configuration allows you to load balance your applications or even gradually test new configurations.

By selecting weighted policy, different fields options are displayed:

Field	Description
Weight *required	You need to specify a weight value between 0 and 255. Higher values increase the chances of a specific record to be used. Setting 0 disables the record.
Description *optional	You may add a description up to 45 characters to distinguish between records with same Name and Type. Example: Florida Load Balancer

Given a set of Weighted Records, with same Name and Type, the chances of a specific record to be chosen by Edge DNS is defined by the following formula:

Weight of the record / Sum of all Weights

Go to load balance DNS records guide

Recommendations to configure DNS Record Types

Name

This field requires you to enter a subdomain. To create a record for the root domain, use @.

Value

The accepted value’s format varies according to the chosen record type.

Record type	Restriction rule	Example
A	It must be in IPv4 format. Maximum of 10 IP addresses (one per line).	`192.209.210.67` `198.199.105.93`
AAAA	It must be in IPv6 format. Maximum of 10 IP addresses (one per line).	`2800:3f0:4001:815::2004` `2001:db8:3333:4444:CCCC:DDDD:EEEE:FFFF`
ANAME	It must be in FQDN format. Only domains below `azioncdn.net`, `azionedge.net`, and `azionedge.com` are accepted. Only one domain for each ANAME type record. It can coexist with records of the same name but of different types (MX, TXT, among others).	`32082s.ha.azioncdn.net`
CAA	Specify the settings separated by spaces, following the format: `[flag] [tag] [“value”]`. It won’t be possible to register a CAA type record when the zone already has a CNAME type record. The tool SSLmate can help when creating and querying.	About flags: if it has a value of 0 (zero), all flags will be switched off. If the flag has a value of 1, the 0 bit (Issuer Critical Flag) is on. For example: a CA must not send certificates for any FQDN, if the relevant record for that FQDN contains a CAA. About tags: the tags must be in lower case and must follow the naming convention in the RFC. Example: `issue`, `issuewild`, `iodef`. - issue indicates that the CA of the ACM specified in the value field can send a certificate to your domain or sub-domain. - issuewild indicates that the CA of the ACM specified in the value field can send a wildcard certificate to your domain or sub-domain. - iodef indicates that instead of the CA receiving an invalid request for a certificate, it should send a notification to the domain owner. Use url (http/https) or mailto. For example: `mailto:email@domain.com`, `https://url`, and `http://url`. Value: `0 issue "ca.example.net"` `value`: must always be between double quotes and the content will depend on the tag you use. `issue`: url or a sequence. For example: “ca.example.net; account=123456” or “ca.example.com” `issuewild`: must use a domain with a wildcard. For example: “*.example.com” `iodef`: a url callback or an email address. For example: “mailto @domain”, `https://example.com/callback`, and `http://example.com/callback`.
CNAME	It must be in FQDN format. Only point it to another domain name, never an IP address. It can’t be added at the level of the root domain. Only one domain is allowed for each CNAME type record. A defined host name in a CNAME record must not include records from other types of resources (MX, A, others). CNAME records can point to other CNAME records, but this isn’t considered good practice, as it’s inefficient. If a CNAME record is pointing to a record in the same zone, Edge DNS will respond to all of them in just one query.	`example.com`
DS	It must be in the format `[tag] [algorithm_numeric_id] [digest_numeric_id] [hex_digest]`	`12345 3 1 123456789ABCDEF`
MX	It must be in the format `[priority] [address]`. Maximum of 10 IP addresses (one per line).	`10 mailserver.example.com` `20 mailserver2.example.com`
NS	It must be in FQDN format or be an IP address. Maximum of 10 records (one per line). An NS can’t be configured by the main domain of the zone (naked domain). It must point to the servers that have authority over that record.	`ns1.aziondns.net` `ns2.aziondns.com` `ns3.aziondns.org
PTR	Reverse zones lined to IPv6 addresses follow other rules.	After creating a reverse zone, you must create a type PTR record associated with it. `www.exemplo.com`
SRV	The zone name must have the following format: `_service._protocol.name`. Example: `_ldap._tcp.azionsrv".<br /><br />The response values must be in the format` [priority] [weight] [port] [target]`. Maximum of 10 records (one per line). It must point to the host name that has an A or AAAA record. Note: Edge DNS won’t validate this automatically.	`0 60 5060 bigbox.example.com`
TXT	Limited to 1000 characters. Text that is separated by ENTER is considered as different responses by Edge DNS	This domain name is reserved for use in documentation. `"printer=lpr5"` `"favorite drink=orange juice"`

You can set up a domain, such as www.domain.com, to be used as a naked domain, that is, only domain.com. There are two ways to configure this:

Create an A-type entry pointing to your webserver. Then, it’ll be redirected to Azion. This option may impact your Google ranking.
Create an ANAME entry in your DNS and point it to Azion. If you’re using a DNS service outside Azion or a domain pointing to another platform, this option may not be supported.

Go to access addresses through a root domain guide

Wildcards

A wildcard record is a record that responds to DNS requests by domains that you haven’t defined yet. You can create them for any type, inserting an asterisk (*) in the record name. For example, imagine that you have the following configuration for a zone whose domain is “example.com”:

Name	Type	Value
www	A	192.168.0.1 192.168.0.2 192.168.0.3
*	A	1.1.1.1
*.wildcard	A	2.2.2.2

This means that:

If the query is made by www.example.com, the response will consist of 3 IP addresses: 192.168.0.1, 192.168.0.2, and 192.168.0. N.B. It isn’t a wildcard, but it’s given priority for the response because it correctly meets the record that is queried.
If the query is made by ghost.example.com, the response will be according to the wildcard it found. The response will be: 1.1.1.1.
If the query is made by another.wildcard.example.com, the response will be according to the wildcard it found this time. The response will be: 2.2.2.2.
If the query is made by wrong.record.example.com, the response will have no value, because there’s nothing that corresponds to this structure.

Only the left-most asterisk followed by a dot will be considered a wildcard. All other asterisks, if any, will be considered as valid characters.

It isn’t allowed to use wildcard characters in SRV type records because it requires a standard format in its name.

DNS provider configuration

In order for Edge DNS to become the authority over your zones, you must point it at your DNS registry. For example: registro.br, GoDaddy, AWS.

To point to your DNS registration, use one of the nameservers listed in the Main Settings tab of your Azion registered zones.

Domain Name System Security Extensions (DNSSEC)

The Domain Name System Security Extensions (DNSSEC) is a feature of the Domain Name System (DNS) that authenticates responses to domain name lookups. It doesn’t provide privacy protections for those lookups but prevents attackers from manipulating or poisoning the responses to DNS requests.

Go to DNSSEC compatibility reference

Monitoring and Troubleshooting

Check Service Status

Before troubleshooting DNS issues, verify the current health of Azion’s platform on the Azion Status Page. This page provides real-time information about service availability and any ongoing incidents affecting Edge DNS or other Azion services.

DNS Propagation Time

When you create or modify DNS records on Edge DNS, changes are distributed across Azion’s global network within seconds. However, full propagation to all DNS resolvers worldwide depends on your record’s TTL (Time-to-Live) configuration and the caching behavior of intermediate resolvers.

Typical propagation characteristics:

Azion network: Changes propagate within seconds to all Azion data centers
Global resolvers: May take up to the configured TTL value (default: 3600 seconds)
Negative caching: Failed lookups may be cached according to the SOA minimum TTL

Verify DNS Configuration

To confirm your DNS zone is processing requests correctly, use the following diagnostic tools:

Tool	Purpose	Guide
DIG	Query DNS servers directly, verify record responses	How to use the DIG command
HOST	Convert domain names to IP addresses and vice versa	Test zone guide
NSLOOKUP	Query DNS records for domains and IPs	Test zone guide
Traceroute	Diagnose network path and latency issues	How to use Traceroute

Monitor DNS Queries

Track DNS query patterns and identify potential issues using Azion’s Observe products:

Real-Time Metrics: View aggregated charts showing query volumes, response codes, and geographic distribution over time.
GraphQL API: Query raw and aggregated DNS data for custom analysis and integration with monitoring tools.

View Edge DNS metrics guide

Report Issues

If you experience unexpected behavior with Edge DNS replication or query responses:

Collect diagnostic information:
- DIG or HOST command output showing the unexpected response
- Timestamp of the observed issue (UTC format preferred)
- Affected domain names and record types
- Nameserver used in the query (e.g., ns1.aziondns.net)
- Geographic location where the issue was observed
Check the status page for any ongoing incidents at status.azion.com
Contact Azion Support through Azion Support with the collected information

Massive redirect for domain migration

Massive Redirect is Azion’s serverless integration for processing many simultaneous redirects. It can be used where there is a need to change a significant number of addresses, for example, in domain migrations.

To configure massive redirection for domain migration, access the Massive Redirect documentation.

Monitoring and troubleshooting replication issues

When you create or update records in Edge DNS, changes are distributed across Azion’s global infrastructure in near real time. However, DNS propagation depends on TTL values and resolver caches, which means some resolvers may still return stale responses for a period after a change is applied.

How replication works

Edge DNS synchronizes zone data across Azion’s distributed infrastructure automatically. The time a resolver takes to reflect a change depends on the TTL (Time to Live) value set on the record: lower TTL values reduce the window during which outdated responses are served.

Verifying propagation

To confirm whether a record change has propagated correctly, use the dig command against one of Azion’s authoritative nameservers directly, bypassing any intermediate resolver cache:

dig @<azion-nameserver> <your-domain> <record-type>

Replace <azion-nameserver> with any of the nameservers listed in the Main Settings tab of your zone in Azion Console (for example, ns1.aziondns.net or ns2.aziondns.net), <your-domain> with your zone’s domain, and <record-type> with the DNS record type (for example, A, CNAME, or MX).

Go to dig command guide

Common replication issues

Symptom	Likely cause	Recommended action
Record not resolving after update	Resolver is serving a cached response	Wait for the TTL to expire or lower the TTL before making changes
Inconsistent responses across regions	Propagation still in progress	Wait a few minutes and re-query; check the record in Azion Console
Zone not resolving at all	Nameservers not pointed to Azion	Verify that your domain registrar is using Azion’s NS records
NXDOMAIN for a record that exists	Record name or type mismatch	Confirm the record name and type in Edge DNS match the query

Using Real-Time Events to investigate DNS queries

Real-Time Events records queries received by your Edge DNS zones, including the query type (Q Type), resolution method (Resolution Type), and response status code (Status Code). Use these logs to identify unexpected query patterns, resolution failures, or anomalous traffic.

Go to Real-Time Events reference

Using Real-Time Metrics to track query volume

The Edge DNS tab in Real-Time Metrics displays the Total Queries graph, which shows the total number of queries received by your zones over a selected time range. You can filter by zone using the available filters. A sudden drop in query volume may indicate a misconfiguration or a propagation issue, while an unexpected spike may signal abnormal traffic.

Go to Real-Time Metrics reference

Checking platform status and service disruptions

Azion publishes real-time operational status for all platform components, including Edge DNS, on the Azion Status Page.

What the status page shows

The status page reports the current health of Azion services across regions and components. For Edge DNS, it reflects:

Operational: all zones are resolving normally across all data centers.
Degraded performance: query resolution is slower than expected in one or more regions.
Partial outage: some zones or record types are not resolving in specific regions.
Major outage: Edge DNS is unavailable in one or more regions.

Subscribing to status updates

You can subscribe to incident notifications directly from the status page to receive email alerts when Azion opens, updates, or resolves an incident affecting Edge DNS or any other platform component.

During a service disruption

If the status page reports an active incident affecting Edge DNS:

Check the incident details on the status page for the affected regions and estimated resolution time.
Avoid making zone changes during an active incident, as propagation behavior may be unpredictable.
Monitor your TTL values: if your records have low TTL values, resolvers will re-query Azion’s nameservers more frequently, which may amplify the impact of a disruption.
Contact Support if your service is critically affected and the incident is not yet reflected on the status page.

Go to Azion Status Page Go to Support documentation