Front Door Health Probe DNSTimeout

Ian Clements 0

In the Azure Front Door Health Probe Log we are getting regular failures with 'DNSTimeout' errors when checking the health of our Azure App Service Origins.

This is triggering regular false alerts for us and seems to be an Azure DNS Issue.

I saw some mention that Azure reserves a particular UDP port number within a standard range and when this get's used you will get an intermittent failure. Seems odd that Azure Front Door Origin Health Probes wouldn't account for this though.

Our App Services are public with Access Restrictions in place and allow for AzureFrontDoor tagged traffic.

Ian Clements 0 Reputation points

2024-10-28T17:00:44.1533333+00:00

Ah OK I think it is just a transient issue and not a genuine problem. I hadn't realised the health probes would be coming from so many edge locations we just need to adjust how we alert on origin health.

Thanks for the information.
KapilAnanth-MSFT 46,876 Reputation points Microsoft Employee

2024-10-29T05:22:09.2133333+00:00

@Ian Clements ,

You are most welcome.

Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others", I have summarized our discussion into an answer.

I would greatly appreciate if you could Accept the answer and close this thread

Original posters help the community find answers faster by identifying the correct answer.

Thanks,

Kapil

1 answer

KapilAnanth-MSFT 46,876 Reputation points Microsoft Employee

2024-10-22T04:23:16.1966667+00:00
@Ian Clements ,

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

Wrt, "Azure reserves a particular UDP port number within a standard range and when this get's used you will get an intermittent failure."

Can you please share the source/documentation mentioning this

I am afraid I am not aware of any such behavior

Also, I believe you are confused between "Access log" and "Health probe log"

Both are different

Can you please confirm that you are in fact checking Access log and not Health probe log

Can you share the entire Access log ( you can redact PII such as ClientIp, SocketIp, Hostname etc)

Especially, the following fields

HttpStatusCode

Cache Status

ErrorInfo

OriginURL

OriginIP

OriginName

Cheers,

Kapil
Please sign in to rate this answer.
Ian Clements 0 Reputation points

2024-10-22T09:09:11.4466667+00:00

So on UDP port point it was in a post and was related to VMs being resolved through Azure DNS but the symptoms seemed very similar so that's why I mentioned it - https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/unmasking-dns-timeouts-the-hidden-culprit-in-azure-virtual/ba-p/4250444

To confirm the errors are coming from the 'FrontDoorHealthProbeLog'. An examples is below -

OperationName

Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write

SourceSystem

Azure

healthProbeId_g

eb85e449-a45e-41dc-9bfb-f6d4a4d90900

pop_s

CYS

httpVerb_s

GET

result_s

DNSTimeout

httpStatusCode_s

0

probeUrl_s

https://**********-public-api-ukwest.azurewebsites.net:443/api/health-check?appHealthProbeRequest=true

originName_s

*********-public-api-ukwest.azurewebsites.net

totalLatencyMilliseconds_s

3000

connectionLatencyMilliseconds_s

n/a

DNSLatencyMicroseconds_s

3000000

Type

AzureDiagnostics

KapilAnanth-MSFT 46,876 Reputation points Microsoft Employee

2024-10-24T07:06:36.07+00:00

@Ian Clements ,

Thanks for sharing the details.

I see that the log is from "Health probe log" only.

Wrt to the document you shared,

This has nothing to do with DNS or AFD/CDN

This is documented here in FAQ | What protocols can I use in virtual networks?

This is with behavior of VMs in a VNET, not for public traffic.

May I ask if this is actually affecting the traffic?

Health probe logs failing occasionally should not affect the actual Traffic to the Backend

As multiple health probes from different regions would constantly probe it and check the backend status

As long as "SuccessfulSamplesRequired" is met, the origin is considered healthy.

See : How Front Door determines origin health

Further,

I see the POP Location is "CYS", which stands for Cheyenne, Wyoming, USA (Central US)

See : Microsoft POP locations

Is the issue isolated to the above specific region/POP?

Or are you facing health probe failures across several regions?

It is quite possible that the DNS was unable to respond within the specified time out period resulting in DNS Time out

And if you are not using Azure DNS for Origin, please check the DNS Propagation of your origin in the above region(s)

Cheers,

Kapil

Ian Clements 0 Reputation points

2024-10-28T17:02:28.3566667+00:00

Appears to be a transient network issue from a single edge health probe location which is to be expected. We will adjust how we alert going forwards.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Front Door Health Probe DNSTimeout

1 answer

Your answer