search

AndersRodland / ConfigMgrClientHealth

ConfigMgr Client Health
116 stars 42 forks source link

Test-DNSConfiguration is not optimal #58

Open Xento opened 3 years ago

Xento commented 3 years ago

There are some issues with the dns check. It wont hurt when it detects a false positive but it distorts the reports.

$localIPs:

172.30.x.x fe80::9578:xy:xy:x 172.29.x.x fe80::e8a1:xy:xy:x 192.168.x.x fe80::8c21:xy:xy:x

Resolve-DnsName -Name $fqdn -Server ($dnsServers | Select-Object -First 1) -Type A -DnsOnly | Where-Object -FilterScript {$_.IPAddress}

Name Type TTL Section IPAddress
Hostname.contoso.de A 1200 Answer 172.30.x.x
dns1.contoso.de A 86400 Additional 172.18.x.x
dns2.contoso.de A 3600 Additional 172.17.x.x

  1. IPv6 adresses in $localIPs but only results for IPv4, so the check will always fail
  2. I'm connected via VPN and have a vSwitch installed so this two addresses won't show up in the dns server

May be it would be best to only check the connection with the corrent dns suffix or make it configureable

ladewig commented 3 years ago

In line 931 of the released code, where it says:

$dnsAddressList = Resolve-DnsName -Name $fqdn -Server ($dnsServers | Select-Object -First 1) -Type A -DnsOnly | Select-Object -ExpandProperty IPAddress

I changed it to be the following with the change in bold and that resolved similar issues we were having.

$dnsAddressList = Resolve-DnsName -Name $fqdn -Server ($dnsServers | Select-Object -First 1) -Type A -DnsOnly | Where-Object {$_.Name -eq $fqdn} | Select-Object -ExpandProperty IPAddress

Had planned to submit this, but it fell through the cracks. If you make this change, does it address your issue?

Xento commented 3 years ago

Seems to fix the issue. My DNS Check is now OK with this change. Maybe this pullrequest is than obsolete https://github.com/AndersRodland/ConfigMgrClientHealth/pull/57

ladewig commented 3 years ago

If I use your change, it doesn't fix the problem we are experiencing with the DNS test, whereas using $FQDN addresses both your problem and mine.

Our issue is that some (but not all) of the DNS servers we use have been configured to provide extra info, and due to organizational structure, we can't change that.

I'll go comment on the pull request.

VertigoRay commented 2 years ago

Resolve-DnsName needs -ErrorAction Stop to be properly caught in the event that DNS is unable to resolve anything.