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

Native tooling for creating reverse ptr records from a given IPv4 or v6 address #93

Open
danimo opened this issue Jun 16, 2022 · 1 comment · May be fixed by #94
Open

Native tooling for creating reverse ptr records from a given IPv4 or v6 address #93

danimo opened this issue Jun 16, 2022 · 1 comment · May be fixed by #94

Comments

@danimo
Copy link

danimo commented Jun 16, 2022

Actual Behavior

When creating reverse pointers, one has to resort to terraform primitives to transform a given IP to a revere transcription for the PTR record. This works for IPv4, but not for IPv6. For v6 ptrs one could resort to external commands, but this would no longer be idempotent.

Expected Behavior

Provide a utility function that accepts a forward IP address as name and produces a PTR record which it forwards to pdns, e.g. name = to_ptr("192.168.1.1"). Another alternative is to provide a dedicated ptr record resource, similar to the Aure DNS Provider.

@johannwagner johannwagner linked a pull request Jul 4, 2022 that will close this issue
@baryluk
Copy link

baryluk commented Mar 16, 2024

I agree, this would be great.

We had some hardcoded rules to create PTR names, for one of the zone, which was /24, but then we provisioned some other ones which were living in 10.x.x.x, which is /8 zone, so our octet reversing logic not only did not reverse it correctly, it was trying to create entry in non-existing zone.

We fixed it, but this is ugly

A function, output, or something that would make it work out of the box would be awesome.

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

Successfully merging a pull request may close this issue.

2 participants