You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/dns/dns-troubleshoot.md
+1-87Lines changed: 1 addition & 87 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ services: dns
5
5
author: greg-lindsay
6
6
ms.service: azure-dns
7
7
ms.topic: troubleshooting
8
-
ms.date: 11/30/2023
8
+
ms.date: 08/06/2024
9
9
ms.author: greglin
10
10
---
11
11
# Azure DNS troubleshooting guide
@@ -59,92 +59,6 @@ DNS name resolution is a multi-step process, which can fail for many reasons. Th
59
59
60
60
*[Delegate a domain to Azure DNS](dns-domain-delegation.md)
61
61
62
-
## DNS zone status and unhealthy delegation scenarios
63
-
64
-
DNS zone status indicates the current status of the zone. DNS zone status can be **Unknown**, **Available**, and **Degraded**.
65
-
66
-
### Unknown
67
-
68
-
When a resource is newly created, health signals for these new resources aren't available immediately. A maximum of 24 hours may pass to get the correct health signals for DNS zones. Until this time, the health of the DNS zones will be shown as **Unknown**.
69
-
70
-
When resource health check hasn't received information about DNS zones for more than 6 hours, the zones are marked Unknown. Although this status isn't a definitive indication of the state of the resource, it's an important data point in the troubleshooting process. Once the signal is received and the resource is running as expected, the status of the resource will change to **Available** after a few minutes.
71
-
72
-
The following screenshot is an example of the resource health check message.
73
-
74
-
:::image type="content" source="./media/dns-troubleshoot/unknown-status.png" alt-text="Screenshot of unknown status.":::
75
-
76
-
### Available
77
-
78
-
An **Available** status indicates that the resource health check hasn't detected a delegation issue with your DNS zones. This status means that NS delegation records are appropriately maintained in your primary zone and records meant for child zones aren't present in your primary zone.
79
-
80
-
The following screenshot is an example of the resource health check message.
81
-
82
-
:::image type="content" source="./media/dns-troubleshoot/available-status.png" alt-text="Screenshot of available status.":::
83
-
84
-
### Degraded
85
-
86
-
A **Degraded** status indicates that the resource health check has detected a delegation issue with your DNS zones. Correct the delegation configuration and wait 24 hours for the status to change to **Available**.
87
-
88
-
The following screenshot is an example of the resource health check message.
89
-
90
-
:::image type="content" source="./media/dns-troubleshoot/degraded-status.png" alt-text="Screenshot of degraded status.":::
91
-
92
-
If 24 hours have elapsed after correcting the configuration and the DNS zones are still degraded, contact support.
93
-
94
-
### Configuration error scenario
95
-
96
-
The following scenario demonstrates where a configuration error has led to the unhealthy state of the DNS zones.
97
-
98
-
**Unhealthy Delegation**
99
-
100
-
A primary zone contains NS delegation records, which help delegate traffic from the primary to the child zones. If any NS delegation record is present in the parent zone, the DNS server is supposed to mask all other records below the NS delegation record (except glue records) and direct traffic to the respective child zone based on the user query. If a parent zone contains other records meant for the child zones (delegated zones) below the NS delegation record, the zone will be marked unhealthy and its status is **Degraded**.
101
-
102
-
**What are glue records?** - These are records under the delegation record, which help direct traffic to the delegated/child zones using their IP addresses and are configured as seen in the following.
In the preceding example, **child** is the NS delegation records. The records _**foo.child**_ and _**txt.child**_ are records that should only be present in the child zone, **child.contoso.com**. These records might cause inconsistencies if they aren't removed from the parent zone, **contoso.com**. These inconsistencies could cause the zone to be considered as unhealthy with a **Degraded** status.
127
-
128
-
#### Examples of when a zone is considered healthy or unhealthy
129
-
130
-
| Example | Status |
131
-
| ------- | ------ |
132
-
| Zone doesn't contain NS delegation records, glue records, and other records. |**Healthy**|
133
-
| Zone only contains NS delegation records. |**Healthy**|
134
-
| Zone only contains NS delegation records and glue records. |**Healthy**|
135
-
| Zone contains NS delegation records and other records (except glue records) below delegation record, that should be present in the child zone. |**Unhealthy**|
136
-
| Zone contains NS delegation Records, glue records, and other records (except glue records). |**Unhealthy**|
137
-
138
-
**How can you fix it?** - To resolve, locate and remove all records except glue records under NS delegation records in your parent zone.
139
-
140
-
**How to locate unhealthy delegation records?** - A script is provided to find the unhealthy delegation records in your zone. The script will report records, which are unhealthy.
141
-
142
-
1. Save the script located at: [Find unhealthy DNS records in Azure DNS - PowerShell script sample](./scripts/find-unhealthy-dns-records.md)
143
-
144
-
2. Execute the script as mentioned in the script editor. Script can be edited to meet your requirements.
145
-
146
-
**Historical information** - You can access up to 14 days of health history in the health history section of resource health. This section will also contain the reason for the downtime (when available) for the downtimes reported by resource health. Currently, Azure shows the downtime for your DNS zones resource at a 24-hour granularity.
147
-
148
62
## How do I specify the ‘service’ and ‘protocol’ for an SRV record?
149
63
150
64
Azure DNS manages DNS records as record sets—the collection of records with the same name and the same type. For an SRV record set, the 'service' and 'protocol' need to be specified as part of the record set name. The other SRV parameters ('priority', 'weight', 'port' and 'target') are specified separately for each record in the record set.
0 commit comments