Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

win_dns_record: option to automatically create PTR record #41

Open
jborean93 opened this issue Mar 11, 2020 · 6 comments
Open

win_dns_record: option to automatically create PTR record #41

jborean93 opened this issue Mar 11, 2020 · 6 comments

Comments

@jborean93
Copy link
Collaborator

From @senilio on Oct 18, 2019 10:47

SUMMARY

When creating an A or AAAA record using the win_dns_record module, it would be nice to have the option to automatically create the "associated PTR record". This tick box is available in the DNS Manager GUI when manually creating an A record.

Having this option would basically cut my DNS definition dict in half, since I would't have to define all PTR's.

DNS Manager GUI screenshot

ISSUE TYPE
  • Feature Idea
COMPONENT NAME

win_dns_record

ADDITIONAL INFORMATION

Add a new boolean ptr to win_dns_record.
Default value false, to stick to the current default behavior.
When true, the behavior should be the same as when ticking the box in the GUI.

  - name: Create records
    win_dns_record:
      name: "{{ item.name }}"
      type: "{{ item.type }}"
      value: "{{ item.value }}"
      zone: "{{ item.zone }}"
      ptr: "{{ item.ptr }}"
    with_items: "{{ dns_records }}"

Copied from original issue: ansible/ansible#63672

@jborean93
Copy link
Collaborator Author

From @johnboy2 on Oct 21, 2019 18:15

While this sounds great at a surface level, I'm having trouble seeing how this could be done while remaining idempotent (which Ansible requires).

Although the DNS Manager UI can help you to create mirrored PTR and A records at the same time, the resulting artifacts aren't actually linked in any way other than common convention. That's a pretty terrible thing for any algorithm to depend upon, especially when idempotence is required (which it is here).

Eg consider the update case -- where you change the IP address on an A record using an Ansible task with the proposed ptr: yes. On the PTR side, does that mean you only create the new (matching) record? Or does it also imply deleting the old (no longer matching) record? What about cleaning up other stale PTRs that refer to the same hostname? How could it even find them efficiently given that DNS record values are unindexed?

I'm guessing similar problems exist anywhere else where idempotence is required of things that only agree by convention.

Anyway, I'm happy to be proven wrong here; but I think we're going to need much greater clarity on how idempotence can remain enforced around the various corner cases. This shouldn't be a "creation-time only" thing.

@sabman3
Copy link

sabman3 commented Apr 5, 2022

Since the -CreatePtr option is available with the creation of an A or AAAA record, I think we can make this a boolean option. I already have the code partially done for this. Thoughts?

@jakubauskas
Copy link

Since the -CreatePtr option is available with the creation of an A or AAAA record, I think we can make this a boolean option. I already have the code partially done for this. Thoughts?

Could you share your code for ptr you have? It would be very helpful for everyone

@manuh-L
Copy link

manuh-L commented Feb 27, 2023

This feature will be added any time in the future?

@MallocArray
Copy link

I'm here for the same request, as the lack of this feature is either making me write some awful block/rescue logic to try to figure out which reverse zone I need to create the PTR in, or I'm rewriting my own module to use Add-DnsServerResourceRecordA so I can use the -CreatePtr flag.

@xd999e
Copy link

xd999e commented Feb 28, 2024

This option would be great. Any plans to add this flag in the near future?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants