Problem Adding PTR record with API

[kburetta]

The Wiki Specifies the following constructor and example function::

// <summary>
/// Create PTR record
/// </summary>
/// <param name="recordName">Dns Record Name</param>
/// <param name="recordData">Dns Zone Name</param>
/// <param name="dnsIpAddress">DnsServer IpAddress</param>
/// <param name="dnsZoneName">DnsServer Zone name</param>
/// <returns>Message about result status</returns>
public string AddPtrRecord(string recordName, string recordData, string dnsIpAddress, string dnsZoneName)

Sample: Invoke-SwisVerb $swis IPAM.IPAddressManagement AddPtrRecord @("10.10.11.111","roman.zone.", "10.199.1.149", "10.10.in-addr.arpa")

However, in my attempts at sending the command: Invoke-SwisVerb $swis IPAM.IPAddressManagement AddPtrRecord @("10.206.6.33","TestMachine.company.net.","10.206.1.0","6.206.10.in-addr.arpa") It fails with the following exception: "Invoke-SwisVerb : Record name should start with '6.206.10'"

This is obviously incorrect as the PTR Record Name should theoretically begin with it's ordinal identifier, or the ordinal should at least be specified as a separate parameter.

Inverting the RecordName (to 33.6.206.10) to get the Ordinal first also fails with the same exception: "Invoke-SwisVerb : Record name should start with '6.206.10'"

If I try getting creative and sending the command with an inverted Reverse Zone Name (which is obviously wrong to do): Invoke-SwisVerb $swis IPAM.IPAddressManagement AddPtrRecord @("10.206.6.33","TestMachine.company.net.","10.206.1.0","10.206.6.in-addr.arpa") -or- Invoke-SwisVerb $swis IPAM.IPAddressManagement AddPtrRecord @("33.6.206.10","TestMachine.company.net.","10.206.1.0","33.6.206.10.in-addr.arpa")

Both attempts fail (as you would expect) with a very reasonable exception like: "Invoke-SwisVerb : DNS Zone '33.6.206.10.in-addr.arpa' is not found for DNS server 10.206.1.0"

It seems to me that in the case of the first exception where the method tries to validate that the PTR RecordName begins with the Reverse Zone's Prefix is just wrong. A PTR Record never begins with the same octet/s as its corresponding Reverse Zone. In microsofts DNS implementation, the PTR Records "Name" is just the ordinal octet (33 in my case). Within the Orion IPAM DnsRecord Data itself (from the IPAM.DnsRecord entity) the RecordNames for all PTR Records (Type Number: 12) is actually a fully qualified name for the PTR in its zone with the Ordinal first. IE: "33.6.206.10.in-addr.arpa." which is a little bit weird but i would be fine with that implementation if it actually passed validation in the method.

Does anybody have experience with using this method successfully?

[mrxinu]

I can't help with this one but I wanted to pop in and say how excellent your issue details were. 🤘

[wjch-krl]

First, Let me explain what is happening when you are invoking this verb. Let's say that we are using the following parameters:

• recordName = "10.10.11.111" (IP address for record)
• recordData ="roman.zone." (DNS name for record)
• dnsIpAddress = "10.199.1.149" (IP address of DNS server, that should be monitored by Orion)
• dnsZoneName = "10.10.in-addr.arpa" (the name of DNS zone in DNS server, to which the record will be added)

What IPAM actually does:

1. Validates if the dnsZoneName has a following sufix ".in-addr.arpa" or ".ip6.arpa." "10.10.in-addr.arpa"
2. Verifies that recordName starts with the dnsZoneName without the suffix defined above ("10.10.11.111", "10.10.in-addr.arpa")
3. Tries to parse recordName as IP address: "10.10.11.111"
4. Checks if DNS server with provided IP & DNS zone exists in Orion. ( "10.10.in-addr.arpa")

This how it will look after invoking the Verb with parameters described above:

• IPAM:
• DNS Server:

To make this API call work for your data: Invoke-SwisVerb $swis IPAM.IPAddressManagement AddPtrRecord @("10.206.6.33","TestMachine.company.net.","10.206.1.0","6.206.10.in-addr.arpa") You should change the parameters to: Invoke-SwisVerb $swis IPAM.IPAddressManagement AddPtrRecord @("10.206.6.33","TestMachine.company.net.","10.206.1.0","**10.206.6**.in-addr.arpa")

and make sure that "10.206.6.in-addr.arpa" exists as DNS zone on your DNS server

[kburetta]

Hey @wjch-krl, I understand your breakdown of the situation and appreciate your input very much, however my point remains that a PTR record for the IP address: 10.206.6.33 by convention should not go into a reverse zone called "10.206.6.in-addr.arpa" It should go into a reverse zone called: "6.206.10.in-addr.arpa"

For the example IP address. 10.10.11.111 by convention might go into the zone "11.10.10.in-addr.arpa" or even "10.10.in-addr.arpa" depending on the subnet size the zone contains (/24 or /16 respectively)

A document from Microsoft specifies the standard for naming reverse zones (https://social.technet.microsoft.com/wiki/contents/articles/51904.windows-server-creating-a-dns-reverse-lookup-zone-with-smaller-zones.aspx) and it indicates a fairly straightforward directive:

"We have a reverse lookup zone 168.192.in-addr.arpa. This is an AD Integrated Zone. This zone contains all reverse records for the 192.168.x.x network."

The case remains, that I cannot run the method with the parameters as you specified them: Invoke-SwisVerb $swis IPAM.IPAddressManagement AddPtrRecord @("10.206.6.33","TestMachine.company.net.","10.206.1.0","**10.206.6**.in-addr.arpa") because the command fails that the DNS Zone doesn't exist, and of course it doesn't exist, and shouldn't exist. Because for it to exist would violate the standard naming convention of reverse zones, which is to be named as the inverse of the subnet whose records they contain. I have polled multiple sources and have found absolutely no support for the idea that the IP Address 10.206.6.33 would ever go into a reverse DNS zone named "10.206.6.in-addr.arpa"

To further this sort of madness, the Orion IPAM method that creates a pair of DNS records together (AddDnsARecordWithPtr) works perfectly fine and puts the PTR into the correct reverse zone (6.206.10.in-addr.arpa)! and it only takes in the name of the Hostname, IP Address, DNS Server Address, and name of the FORWARD zone. This result tells me that Orion IPAM totally knows how to find the correct reverse zone by inverting an input IP Address and placing a PTR into it. How else would it be able to create the PTR correctly as you don't have to specific the name of the reverse zone to put it in. It's just with this one specific method (AddPtrRecord) that there is a problematic input validation and it is expecting an input that would never occur.

Does this make sense?

[wjch-krl]

Well, yeah it does makes sense - you are correct. I have created a bug in IPAM to fix the verb behavior (tracked internally as IPAM-2857)

[kburetta]

Any update on the status of this bug?

[wjch-krl]

Sorry for the late response - I was out of the office last week. I have pinged the team - we are hoping to fix it in the next IPAM release. When I will have more information I will get back to you

[hazenet]

I am seeing the same issue as @kburetta For this current setup we are running SolarWinds 4.9

Any updates on this issue or how to structure the parameters should it works?

[wjch-krl]

Unfortunately, the issue is not yet fixed, we are hoping to fix it in the next IPAM release. I have asked the team to prioritize this issue

[hazenet]

Okay, thanks Our normal Reverse Zone is called 63.30.10.in-addr.arpa Using the API I am e.g. not able to add a PTR for the IP: 10.30.63.12 But if I add a dummy Reverse Zone called: 20.20.in-addr.arpa And then try to add a PTR for the IP: 20.20.0.12 It works fine, as the reverse zone "name" is identical reading it from front-to-back and from back-to-front. But our normal reverse zone is not identical reading it from front-to-back and from back-to-front.