Windows DNS / PowerShell

Use Test-KTDNS v1.0.0 for Read-Only DNS Troubleshooting

Download, verify, review, and run KrippyTech's first public PowerShell tool without changing DNS or system configuration. Treat each result as evidence from one DNS query—not proof of overall domain or network health.

Estimated Time

15–20 Minutes

Difficulty

Beginner / Intermediate

Technologies

Windows / DNS / PowerShell

Release

Test-KTDNS v1.0.0

Goal

Ask a specific DNS question and preserve a clear result.

Test-KTDNS passes a name, record type, and optional resolver to the Windows DnsClient module. It returns stable PowerShell objects so the same fields can be reviewed interactively or used by automation.

The script is read-only. It does not change DNS, write files, download content, modify configuration, or handle credentials. DNS resolvers can log query names, so use only authorized resolvers and do not send sensitive internal names to an untrusted resolver.

Before You Start

Confirm the platform and security boundaries.

PowerShell

Windows PowerShell 5.1 or PowerShell 7 on Windows

The Windows DnsClient module and its Resolve-DnsName cmdlet are required. The script is not supported on Linux or macOS.

Privilege

Standard user is enough

Ordinary DNS queries do not require administrator rights.

Signature

Review and verify first

This release is not Authenticode-signed. Verify the checksum and review the source before running it.

Do not weaken execution policy

Do not weaken, bypass, or globally change execution policy. If RemoteSigned blocks the verified browser-downloaded script, use targeted Unblock-File only as described below.

Procedure

Use the release in eight deliberate steps.

Step 1

Download the versioned release files

Use either the complete ZIP or the direct script. Keep the checksum manifest and README with the script so the approved release can be verified and reviewed.

Supporting files: release README and SHA-256 manifest.

Step 2

Verify the script checksum before running it

From the release folder, use the manifest to compare the expected script checksum with the file you downloaded or extracted.

$expected = (Select-String -LiteralPath .\SHA256SUMS.txt -Pattern '  Test-KTDNS.ps1$').Line.Split()[0]
$actual = (Get-FileHash -LiteralPath .\Test-KTDNS.ps1 -Algorithm SHA256).Hash
$actual -eq $expected

The result must be True. The approved Test-KTDNS.ps1 SHA-256 is:

3BA1629A7A8DCF1EB82CE97114A9047529336667BCE1FB04F374F028E1340C1F

If the comparison is false, stop and obtain the release again from the KrippyTech Downloads page.

Step 3

Review the source and its boundaries

Read Test-KTDNS.ps1 before execution. Confirm that the parameters, supported types, DnsOnly setting, stable output object, and terminating-error behavior match the task you intend to perform.

The script performs DNS queries only. It does not use LLMNR or NetBIOS fallback, launch programs, or accept pipeline input.

Step 4

Use targeted Unblock-File only when appropriate

Windows may mark a browser-downloaded script as originating from the Internet. After the checksum is verified and the source is reviewed, RemoteSigned may permit the script after removing that mark from this file only.

Unblock-File -LiteralPath .\Test-KTDNS.ps1

This step is not a substitute for checksum verification or source review. Do not apply a broad unblock operation and do not bypass or globally change execution policy.

Step 5

Run a basic DNS query

The default record type is A. These documentation-safe examples come from the script's approved help.

.\Test-KTDNS.ps1 -Name example.com

.\Test-KTDNS.ps1 -Name example.com -Type MX

.\Test-KTDNS.ps1 -Name localhost -Type A

Supported record types are A, AAAA, CNAME, MX, NS, PTR, SRV, and TXT.

Step 6

Query a specifically approved DNS resolver

When -Server is omitted, Windows uses DNS servers configured on the active network interface. Use the optional parameter only for an approved resolver.

.\Test-KTDNS.ps1 -Name example.com -Type TXT -Server '<dns-server-ip>'

Replace the placeholder with the authorized DNS server IP address or host name. Do not send internal names to an untrusted resolver.

Step 7

Read the normalized output

Every returned record uses the same property set. Fields that do not apply to the record type are $null.

Request

Query / QueryServer

The requested name and either the selected resolver or System default.

Answer

RecordName / RecordType / Value

The returned name, actual record type, and normalized primary value.

DNS context

TTL / Section

The time to live in seconds and the DNS response section.

Type-specific fields

Preference / Priority / Weight / Port

MX preference and SRV routing fields when they apply.

.\Test-KTDNS.ps1 -Name example.com -Type A |
    Format-Table RecordName, RecordType, TTL, Value

Step 8

Treat expected failures as evidence

Invalid names, resolvers, or unsupported record types fail during parameter binding. DNS failures are terminating errors because the approved script calls Resolve-DnsName with -ErrorAction Stop.

try {
    $result = .\Test-KTDNS.ps1 -Name example.com -Type A
}
catch {
    Write-Error "DNS query failed: $($_.Exception.Message)"
}

A failure may indicate that the name or requested type has no answer, the resolver cannot be reached, the request was refused, or another DNS or connectivity condition interrupted the query. Read the error in the context of the exact name, record type, resolver, and time tested.

Interpretation

Use one result to choose the next safe check.

A successful lookup confirms only that the selected resolver returned that response for the requested name and type at that moment.

Unexpected value

Compare the answer with the intended record

Check RecordType, Value, TTL, and Section. Confirm that the query asked for the correct type before treating the value as wrong.

Resolver difference

Compare only authorized resolver paths

If the system-default and a specifically approved resolver differ, preserve which resolver produced each result and investigate DNS scope, delegation, caching, or replication through authorized tools.

No answer or error

Separate name, type, resolver, and connectivity

Confirm the intended name and record type, then determine whether the resolver was reachable and permitted to answer. Do not assume that a single error identifies the root cause.

Positive answer

Continue testing the original dependency

A DNS answer does not prove authentication, Active Directory, application, server, or end-to-end network health. Continue with the narrowest authorized check for the original symptom.

Verification checklist

Source: the versioned KrippyTech release was used.

Integrity: the script checksum matched the manifest before execution.

Resolver: the system default or a specifically approved resolver was used.

Query: the name and record type matched the question being tested.

Interpretation: the result was kept within the limits of one DNS response.

Related Resources

Review the release and its learning path.

Versioned files

Downloads

Access the ZIP, script, README, and checksum manifest from the published v1.0.0 location.

Open Downloads

Topic hub

Windows & Hybrid

Place DNS evidence in the wider context of Active Directory, networking, services, and hybrid dependencies.

Explore Windows & Hybrid

Learning method

MSP University

Use the understand, investigate, resolve, and verify sequence for the larger troubleshooting task.

Review the learning path