Graph and PowerShell Blog

Having contracted at a number of companies over the years I've seen my fair share of horror shows with regard DNS. For something so simple it does have a lot of importance and should be regularly reviewed.

In my latest role the DNS setup was quite simple and I'm happy to report DNS scavaging was enabled, so the majority of records were correct and up-to-date.

↑ Scavenging set correctly for the main AD domain zone.

So what to check?

Static records, do they still ping?

Cross reference records with AD.

Cross reference records with DMZ servers, hosted on VMware so we can use PowerCLI to check.

Check if A record has reverse lookup record (PTR) set?

With our secondary domain we had spit DNS setup, checks to ensure all records were correct.

# Use PowerShell to pull the PTR reverse records

$records = Get-DnsServerResourceRecord -ZoneName domain.locla -RRType A -ComputerName dnsServer.domain.local

foreach ($rec in $records)
{
$r_name = $rec.hostname
$r_timestamp = $rec.timestamp
$r_ttl = $red.timeToLive
$r_date = $rec.recordData.IPv4Address.IPAddressToString
...

What did we find? A few hundred records were wrong:

About 50 A records could be deleted

Several subnets were missing for reverse DNS lookup zones.

Some DMZ servers had been removed from VMware but the DNS record remained.

We found that our Fortinet Site-to-Site VPN did not have the rights to update the PTR record.

In our split DNS zone we added an MX record, it didn't fix an issue but some of the Microsoft health scripts we ran were a lot happier with it present.

While some of the fixes may sound trivial, when an issue occurs and you need to track down a client you will be happy to have a correct DNS setup.

Graph and PowerShell Blog	Articles 2024 Advanced Postfix configuration Installing Exchange 2019 in Azure Landing Zone Upgrading PHP on Windows Adding a Postfix server for relay to O365 O365 Integrated Apps troubleshooting Domino and O365 Co-existence Delegate Control in AD App mail relay via HVE Setting up Mail Relay with HVE Getting BIMI certified Orbea Occam SL H30 Installing FreeSat and Saorview Changing broadband provider Replacing a DIN timer on fuseboard Outlook Desktop Notifications stop working Outlook folders keep moving sort order Teams report uploading to SharePoint with Runbooks Teams PowerShell module can't run CS cmd as App 2023 Cannot map new Shared Mailboxes in O365 Renewing an Exchange 2016 certificate Connect to Compliance PowerShell behind a Proxy Sensitivity Label not shown in Outlook Client Room Finder Error in Outlook Teams not showing Rooms Teams unable to open file Unable to review quarantined mails for shared mailbox Set Locale for various Apps Delegate Sent Items placed into external Tenant Overview of Microsoft Support cases When centralized mail sends via O365 Cleaning up your Windows DNS server Set OneDrive for Business Locale O365 Migration Tips Reporting on successful Azure logons IIS Mapi Queue full with NetScaler Secure Office365 reports with a certificate Using Graph to send emails with inline images Visualizing Graph data with Google Charts Keeping a log of NetScaler AlwaysON connections \| About \| Links

Cleaning up your Windows DNS server 01-Mar-23 Having contracted at a number of companies over the years I've seen my fair share of horror shows with regard DNS. For something so simple it does have a lot of importance and should be regularly reviewed. In my latest role the DNS setup was quite simple and I'm happy to report DNS scavaging was enabled, so the majority of records were correct and up-to-date. ↑ Scavenging set correctly for the main AD domain zone. So what to check? Static records, do they still ping? Cross reference records with AD. Cross reference records with DMZ servers, hosted on VMware so we can use PowerCLI to check. Check if A record has reverse lookup record (PTR) set? With our secondary domain we had spit DNS setup, checks to ensure all records were correct. # Use PowerShell to pull the PTR reverse records $records = Get-DnsServerResourceRecord -ZoneName domain.locla -RRType A -ComputerName dnsServer.domain.local foreach ($rec in $records) { $r_name = $rec.hostname $r_timestamp = $rec.timestamp $r_ttl = $red.timeToLive $r_date = $rec.recordData.IPv4Address.IPAddressToString ... What did we find? A few hundred records were wrong: About 50 A records could be deleted Several subnets were missing for reverse DNS lookup zones. Some DMZ servers had been removed from VMware but the DNS record remained. We found that our Fortinet Site-to-Site VPN did not have the rights to update the PTR record. In our split DNS zone we added an MX record, it didn't fix an issue but some of the Microsoft health scripts we ran were a lot happier with it present. While some of the fixes may sound trivial, when an issue occurs and you need to track down a client you will be happy to have a correct DNS setup.