WIN_DNS_Record

Alrighty

So I’m behind the curve and am updating all of my collections and testing out playbooks here and there, and I noticed along the way that from between community.windows 1.1.0 to 1.6.0 that there has been a major change to how this module is handling computer_name:

Namely, right before I updated it, I tested the playbook and it ran without incident.
immediately after, I ran it, and failures abound.

Using module file /root/.ansible/collections/ansible_collections/community/windows/plugins/modules/win_dns_record.ps1
Pipelining is enabled.
< Windows_ansible_host.DOMAIN.net > ESTABLISH WINRM CONNECTION FOR USER: SA_REDACTED_Domain@DOMAIN.NET on PORT 5986 TO l1pnchwmgt12.columbuschildrens.net
EXEC (via pipeline wrapper)
ok: [Windows_ansible_host.DOMAIN.net] => {
“changed”: false,
“invocation”: {
“module_args”: {
“computer_name”: “DNSserverredacted.DOMAIN.net”,
“name”: “deleteme”,
“port”: null,
“priority”: null,
“state”: “present”,
“ttl”: 3600,
“type”: “A”,
“value”: [
“10.60.24.121”
],
“weight”: null,
“zone”: “DOMAIN.net
}
}
}

The above are the results for what worked in 1.1.0.

Immediately after update, it appears that the Computer_name: field is being entirely ignored and this module is trying to process the request locally, seeing as my ansible node isn’t a DNS server, domain controller, or anything special, its failing every time with a complete inability to find the DNS Zone, duh.

The full traceback is:
Failed to get the zone information for DOMAIN.net on server Windows_ansible_host.
At line:73 char:12

  • $records = Get-DnsServerResourceRecord -ZoneName $zone -Name $name -R …
  • CategoryInfo : NotSpecified: (columbuschildrens.net:root/Microsoft/…rResourceRecord) [Get-DnsServerResourceRecord], CimException
  • FullyQualifiedErrorId : WIN32 1722,Get-DnsServerResourceRecord

ScriptStackTrace:
at Get-DnsServerResourceRecord, : line 3130
at , : line 73

Microsoft.Management.Infrastructure.CimException: Failed to get the zone information for DOMAIN.net on server Windows_ansible_host.DOMAIN.

Am I mishandling something here?

I’ve attempted FQDN, NetBios name and IP addr for computer_name, and nothing is successful.
it is a VERY simplistic playbook for simply testing the module that it will work.
I can post it if necessary.

Thanks
Jess

That issue appears to have been fixed in the collection, but the change has not been included in a release yet:

https://github.com/ansible-collections/community.windows/pull/277

Welp, time to integrate that myself.

Thanks for the assist Matt.

Howdy,

I am also seeing this issue.

chris:~/git/ansible$ ansible -m community.windows.win_dns_record -a “type=CNAME computer_name=‘dc1.example.local’ name=myapp zone=‘internal.example.co.uk’ ttl=60 value=‘docker1.example.local’” -i inventory/test.yml admgmthost -vvv
ansible [core 2.11.5]
config file = /home/chris/git/ansible/ansible.cfg
configured module search path = [‘/home/chris/.ansible/plugins/modules’, ‘/usr/share/ansible/plugins/modules’]
ansible python module location = /home/chris/git/.venv/lib/python3.8/site-packages/ansible
ansible collection location = /home/chris/git/ansible/installed_collections
executable location = /home/chris/git/.venv/bin/ansible
python version = 3.8.10 (default, Jun 2 2021, 10:49:15) [GCC 9.4.0]
jinja version = 3.0.1
libyaml = True
Using /home/chris/git/ansible/ansible.cfg as config file
host_list declined parsing /home/chris/git/ansible/inventory/test.yml as it did not pass its verify_file() method
script declined parsing /home/chris/git/ansible/inventory/test.yml as it did not pass its verify_file() method
Parsed /home/chris/git/ansible/inventory/test.yml inventory source with yaml plugin
Skipping callback ‘default’, as we already have a stdout callback.
Skipping callback ‘minimal’, as we already have a stdout callback.
Skipping callback ‘oneline’, as we already have a stdout callback.
META: ran handlers
Using module file /home/chris/git/.venv/lib/python3.8/site-packages/ansible_collections/community/windows/plugins/modules/win_dns_record.ps1
Pipelining is enabled.
<admgmthost.example.local> ESTABLISH WINRM CONNECTION FOR USER: example\service.ansible on PORT 5985 TO admgmthost.example.local
EXEC (via pipeline wrapper)
The full traceback is:
Failed to get the zone information for internal.example.co.uk on server admgmthost.
At line:73 char:12

  • $records = Get-DnsServerResourceRecord -ZoneName $zone -Name $name -R …
  • CategoryInfo : NotSpecified: (internal.example.co.uk:root/Microsoft/…rResourceRecord) [Get-DnsServerResourceRecord], CimException
  • FullyQualifiedErrorId : WIN32 1722,Get-DnsServerResourceRecord

ScriptStackTrace:
at Get-DnsServerResourceRecord, : line 4075
at , : line 73

Microsoft.Management.Infrastructure.CimException: Failed to get the zone information for internal.example.co.uk on server admgmthost.
at Microsoft.Management.Infrastructure.Internal.Operations.CimAsyncObserverProxyBase`1.ProcessNativeCallback(OperationCallbackProcessingContext callbackProcessingContext, T currentItem, Boolean moreResults, MiResult operationResult, String errorMessage, InstanceHandle errorDetailsHandle)
admgmthost | FAILED! => {
“changed”: false,
“msg”: “Unhandled exception while executing module: Failed to get the zone information for internal.example.co.uk on server admgmthost.”
}

I have verified that the ps1 file looks correct located at: /home/chris/git/.venv/lib/python3.8/site-packages/ansible_collections/community/windows/plugins/modules/win_dns_record.ps1
(It appears to have the changes in the above-mentioned PR: https://github.com/ansible-collections/community.windows/pull/277)

Installed 1.7.0 of the ansible.windows collection.

Re-created the Get-DNSServerResourceRecord command used here and ran on a windows machine via winrm to the same admgmthost server with no issue. Also ran find on the host machine logged in as the service.ansible user. Interestingly, if I omit the -ComputerName switch in the powershell replicas I get the same response. However, it appears as though the variables are being set correctly in the win_dns_record.ps1 file… unless I missed something :slight_smile:

Any thoughts?

Cheers

Chris

I should add that we’ve been using this in various playbooks for a while now. It mysteriously stopped working some time between the 9th of August and the 21st of September. Although, that is quite dependant on when our ansible build process ran and picked up new dependency versions.

Cheers

Chris

Ok, after finding the last version of my ansible container that worked and digging around in the galaxy collection versions. I managed to fix it by installing the collection community.windows at version 1.5.0,

This should keep me going for now :slight_smile: Although I’m interested to know if I can help troubleshoot the issue (or indeed if a newer version will also work)

Cheers

Chris