[Autogenerated] In the realm of system administration.
We all know that DNS is the backbone of all network communications.
Now, when DNS goes down, that's a catastrophe.
Waiting to happen, emails can be sent.
Internal services aren't accessible and there's not even talk about
the chaos when users can't access their apps.
So quick resolution is not a luxury.
It's a necessity and that's what we're focusing on today,
how to quickly identify and resolve D NEST issues using PowerShell.
The it team at Bethany's Pie Shop has been receiving an increasing
number of complaints for employees that certain websites and
internal applications are timing out or even failing to load
during certain periods of the day.
Now, upon investigation,
you discover that the issue seems to be related to DNS
resolution on the internal DNS server.
So let's jump into another demo and see what's going on.
So we're in something deep here critical website can't be reached.
Let's figure out what's going on.
Let's start with DNS because it's always DNS, right.
I'm here on my admin workstation, logged in as a domain admin as usual.
Don't tell security with my PowerShell console up.
Now, the internal app is hosted on a server called SRV two.
Let's first see if I can resolve the server that the app is hosted on.
It's failing.
Not good.
It is.
In fact, DNS shocker.
Well,
let me see if the DNS record exists at all in the ad integrated zone by
running G DNS server resource record on my main DNS server,
which is Srb one.
So i'll use POWERS MO and connect to Srb one and run get DNS server
resource record and see if I can find Srb two.
Not good.
That's a problem.
The record isn't showing up.
Well,
the server should be dynamically adding its DNS record to the
zone since we have dynamic DSS on all servers.
Hm What could be interfering with that registration?
Well,
let's first manually attempt to register a DNS record for the SRB two server.
All right.
So now I've used remote desktop to connect to the IP address of SB two.
So it should be on SB two now.
Yep,
I don't have Windows PowerShell up because I don't have
PowerShell seven installed in this machine.
So to attempt a manual registration, I can use registered DNS client.
All right, it looks like it was successful.
At least it didn't give me an error.
It's still not resolving.
Great.
The registration process isn't working.
Let me come back over to my SRV two server and look around its N
settings instead of futzing around with the gooey.
I always like to stay in PowerShell, so I can use the G DNS client command lit.
And I'm specifying the interface alias of Ethernet,
which is the main Nick on this machine.
And I typed it to select star.
So select all properties on it to see all the properties.
Since get DNS client doesn't usually return all of the
properties looking through here.
I see it.
It's a property that looks like it might be.
It, it says register this connections address and it's set to false.
That means that the client isn't configured to use dynamic DNS at all.
Let's turn that on.
Unfortunately, there's no way to do this in PowerShell.
But what I can do is use the Gooey.
Unfortunately, I have to use the Gooey in this instance.
So I go to change adapter settings, come over here,
go to properties and that is embedded in the TCP/IP properties,
go to advanced and DNS on the try here register this
connection addresses in DNS right now.
Uh click, okay and OK to confirm and OK to confirm again now that that's enabled,
let's try to register this DNS client again and now come back over
to my workstation and try to resolve it again.
Yay, the record is back,
I guess some numbs call decided it was a good idea to turn that off when it
clearly was not as a final test since I can resolve it.
Let me just now try to run, get DNS server resource record.
And just query it directly on the server just to be sure.
And it is successful.
The record is now back and for good, I hope.