Sometimes technicians already know where the problem is in the system!

This user shares how they figured out the issue in the first go when things went downhill.

Check out the full story.

It’s always DNS

The company I work for has decided, in their infinite wisdom, to split into two companies. I work on a team developing and maintaining custom internal apps which are deployed to azure, aws, gcp, and our own data centers.

He explains what has changed around…

As part of this move, several apps I support must be moved from our current azure tenant to a new azure tenant, which affects both hosting & entra authentication.

Now, onto the story:

We’ve been having a… fun and exciting time moving applications for the past 2 months. By fun and exciting, I mean submitting a lot of paperwork about how long things will take, who is going to do them, and so on.

I have fielded several complaints about timelines I submitted weeks ago being invalid because by the time someone reviewed the paperwork, my timeline had us deploying the app — and obviously no work has started yet, since the paperwork hasn’t been approved!

This is where it gets bad…

Today, however, is different. Today I have permission to deploy. The infrastructure requests I can’t handle myself have been completed. In theory, everything can work.

Everything starts out smoothly. I’m able to deploy my resources, replicate the database, and move the source code over. A slight hiccup occurs with npm package locks and custom registry auth, but nothing I can’t handle with some effort.

I deploy a fresh build of the application to the new environment and… it works! I’m able to log in, get to the home page, even navigate and load some data.

This is great.

I’m finally going to get things done and my managers’ manager will stop pestering me with pointless daily updates.

UH OH…

Then one page fails to load. Alright, no need to panic. This is why we have application insights. I’ll just check the request logs, and… what? The logs aren’t there. I double & triple check the config. The connection string is correct.

Now I’m more than a little annoyed. Observability is how we find issues, without it, we’re basically flying blind. I log into KUDU and start checking things.

After nearly a full day of banging my head against the wall, I recall our app service is vnet integrated, and as such has some special™ DNS behavior so it can resolve internal URLs.

I run `nameresolver` on the application insights ingest URL, and… it spits out a couple aliases to azure private link and no IP address.

He knew something was up…

Now *that* is interesting. Our app does not utilize private link at all, it only uses VNET to talk to resources deployed to our on-prem datacenters.

I raise this issue with our architecture team, and it turns out this is a known issue, which is actively being worked on. Excellent.

Next time I’ll check DNS first.

OUCH! That sounds like a lot of trouble.

Why would they not clear out this issue before?

Let’s find out what folks on Reddit think about this one.

This user thinks they might be working at the same company…

This user always double checks before jumping to conclusions…

That’s right! This user knows DNS is always the culprit.

This user knows there’s a reason why these systems exist…

This user knows the issue with DNS.

Somebody’s being a bit extra here!