Get-DnsServerResourceRecord DescriptiveText returns only first string for multi-string TXT records (DnsServer 2.0.0.0 / Windows Server 2025)

Ashok Dinakaran 0 Reputation points
2026-07-03T12:22:12.5833333+00:00

Environment

  • OS: Windows Server 2025 Datacenter (Build 10.0.26100)
  • DnsServer module: 2.0.0.0
  • PowerShell: Windows PowerShell ISE (built-in)

Issue

When a TXT record contains multiple character-strings (RFC 1035 §3.3.14 allows

multiple strings per TXT record), Get-DnsServerResourceRecord only returns the

first string in RecordData.DescriptiveText. The remaining strings are silently

dropped.

Repro Steps

Step 1 — Create a multi-string TXT record in DNS Manager:

  • Open DNS Manager → zone → New Record → Text (TXT)
  • Record Name: txtbug
  • In the "Text" field, add three lines: txt record data

This creates a single TXT record with 3 separate RFC 1035 character-strings.

Step 2 — Query via PowerShell cmdlet:

$r = Get-DnsServerResourceRecord -ZoneName "niosxprimary.com" -Name "txtbug" -RRType TXT

Write-Host "DescriptiveText count:" $r.RecordData.DescriptiveText.Count

$r.RecordData.DescriptiveText | ForEach-Object { "  [$_]" }

Output:

DescriptiveText count: 1

  [txt]

Step 3 — Query same record via Resolve-DnsName (wire-level):

$res = Resolve-DnsName -Name "txtbug.niosxprimary.com" -Type TXT -Server "127.0.0.1" -DnsOnly

Write-Host "Strings count:" $res.Strings.Count

$res.Strings | ForEach-Object { "  [$_]" }

Output:

Strings count: 3

  [txt]

  [record]

  [data]

Step 4 — Also confirmed via nslookup:

nslookup -type=TXT txtbug.niosxprimary.com 127.0.0.1

Output:

txtbug.niosxprimary.com text =

    "txt"

    "record"

    "data"

Summary of Evidence

| Method | Count | Strings returned |

|---------------------------------|-------|--------------------------|

| DescriptiveText (cmdlet) | 1 | txt only |

| Resolve-DnsName .Strings | 3 | txt, record, data |

| nslookup | 3 | txt, record, data |

| DNS Manager UI | 3 | txt, record, data |

The DNS server holds all three strings correctly (confirmed by wire-level tools).

The truncation happens specifically in the DescriptiveText property exposed by

Get-DnsServerResourceRecord.

Expected Behavior

RecordData.DescriptiveText should return a string[] containing all

character-strings of the TXT record, consistent with RFC 1035 §3.3.14 and

consistent with what Resolve-DnsName and nslookup return.

Question

  1. Is this a known limitation of the DnsServer module?
  2. Is there a supported API/cmdlet that returns all character-strings from a multi-string TXT record without using Resolve-DnsName?
  3. Is a fix planned for DnsServer 2.0.0.0 on Windows Server 2025?

Workaround (currently using)

Do we have any work around this issue?

Windows development | Windows API - Win32
0 comments No comments

2 answers

Sort by: Most helpful
  1. Taki Ly (WICLOUD CORPORATION) 2,480 Reputation points Microsoft External Staff Moderator
    2026-07-06T04:33:47.88+00:00

    Hello @Ashok Dinakaran ,

    Regarding your observations, testing across both Windows Server 2022 and Server 2025 indicates that the RecordData.DescriptiveText property currently outputs only the first segment of a multi-string TXT record.

    I dug into the underlying architecture to understand why this happens. Under the hood, the DnsServer PowerShell module leverages the DNS WMI Provider (specifically the MicrosoftDNS_TXTType class) to retrieve record data. If you look at the official WMI documentation for this class, the DescriptiveText property is architected explicitly as a single string data type, rather than an array of strings (string[]).

    Because the core WMI provider parses and maps the multi-string text into a single string property, the PowerShell cmdlet inherently inherits this truncation. This confirms that it is a longstanding architectural limitation of the WMI provider rather than a recent regression in the DnsServer 2.0.0.0 module.

    Given this architectural limitation at the management layer, there is currently no other built-in Server API/Cmdlet that circumvents it. Therefore, your current approach of utilizing the wire-level lookup via Resolve-DnsName -Server 127.0.0.1 is indeed the workaround to retrieve the complete string array.

    To help the product team investigate the gap between the WMI provider's design and the RFC 1035 multi-string standard, I highly recommend submitting your findings through the Feedback Hub by pressing the Windows Key + F on your Windows Server.

    Hope these information help! Please let me know if you have any further questions. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

    Thank you.

    Was this answer helpful?


  2. Warren A. Gonzales 80 Reputation points
    2026-07-03T12:38:35.1466667+00:00

    Thanks for providing such a detailed repro—it clearly demonstrates that the DNS server is storing and serving the TXT record correctly, and that the issue is isolated to Get-DnsServerResourceRecord.

    As far as I'm aware, RecordData.DescriptiveText only exposes the first TXT segment, and there isn't another cmdlet in the DnsServer module that returns the complete multi-string value. In the meantime, Resolve-DnsName (using the .Strings property) appears to be the most reliable workaround if you need all TXT strings.

    It would be helpful if someone else could verify whether this behavior also occurs on Windows Server 2022 or earlier versions of the DnsServer module. If it reproduces across versions, it's likely a longstanding limitation; if it's new to Server 2025, it may be a regression.

    Based on your findings, this does seem worth reporting to Microsoft as a potential bug, since the behavior is inconsistent with the DNS server itself and with tools like Resolve-DnsName and nslookup.

    Was this answer helpful?


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.