pfSense

• Amending previous post to remove item number 3, reducing FR to one correction and one enhancement. API will only attempt to change fields in request, so geolocation configuration is not required and does not belong in the application; this will remain an AWS configuration item.

However, SetIdentifier is still required to perform a successful record set lookup and update.

M

I'm interested in this bug now too as I've just discovered that 2.3.2 + AWS Route53 is inoperable. With 2.3.2 I can no longer use AWS Route53 for dynamic DNS at all. I am assuming that the old API the r53.class file is using is no longer present but there doesn't seem to be any debugging output I can enable to verify that. However /etc/rc.dyndns.update will not create a new record nor will it update one. But in both cases, the system believes that it did.

I'd be happy to test any code that fixed this, either as part of this issue or #3973.

Also, I think this tracker type should be bug not feature? I see it tagged for 2.3.3 but as "Feature". In my testing, DynDNS + AWS Route53 is broken.

The previous version works for me on a non-policy subdomain. What type of permission policy do you have set in IAM for the update user?

Here's the wrench; the r53.class uses the 10-1-2010 API version, which doesn't support recordset modification with the SetIdentifier attribute. See link for details:

http://docs.aws.amazon.com/Route53/latest/APIReference/api-change-resource-record-sets-old-versions.html

I've already made the change to include the UPSERT action, which handles creation and updates. Need someone from pfsense to speak up here and give some guidance on external open source implementations so I don't have to reinvent the wheel. Once the class is updated, I can include the secondary enhancement. Otherwise, I will reduce scope here and only request the UPSERT action.

Matt Williams wrote:

The previous version works for me on a non-policy subdomain. What type of permission policy do you have set in IAM for the update user?

The IAM user has full Route53 permissions (AmazonRoute53FullAccess). If I look at the IAM users' API key, it will not mark as having been used whenever I click on the force update.

Matt Williams wrote:

I've already made the change to include the UPSERT action, which handles creation and updates.

I tried to hand-edit the file as listed in #3973 but it did not work for me. Do you have example code/diff I could try?

Just to confirm my issue was not an IAM Policy problem, I gave my IAM user full permissions and created a new record in PFsense that didn't exist before and still no access. The IAM access time for the API key did update in the interim (and sans Admin access) but it matches a timestamp for updating the existing record not making any modifications (forced or otherwise).

Diff file:

https://github.com/williamsmt/pfsense/commit/d96a547cc722d04880d50f7b6a1308c0d9575123

This works for me as of this evening. I will continue development before requesting a pull, but it should get you and going. For reference, this is what your IAM security policy should look like:

{
"Version": "2012-10-17",
"Statement": [ {
"Effect": "Allow",
"Action": [
"route53:ListResourceRecordSets"
],
"Resource": "arn:aws:route53:::hostedzone/{zone}"
}, {
"Effect": "Allow",
"Action": [
"route53:ChangeResourceRecordSets"
],
"Resource": "arn:aws:route53:::hostedzone/{zone}"
}, {
"Effect": "Allow",
"Action": [
"route53:GetChange"
],
"Resource": "arn:aws:route53:::change/*"
}
]
}

Looks like formatting messed up the JSON encoding on that policy; be sure syntax is correct before using; {zone} = your ZONE ID

Does this require an updated r53.class file? Keeping what looks like an unmaintaned (upstream) legacy file seems like the wrong way to solve this permanently, especially since it's using the very old API and maintains a lot of methods that are unnecessary to pfSense. Doing a single UPSERT action and checking the response is a trivial amount of code that could really clean up the r53.class.

I started looking through the dyndns.class and the Route53 is really non-standard for how pfSense is trying to do this. I forked a copy of the code and am rewriting it clean to live within dyndns.class. I'll post results when I finish it (hopefully tomorrow). Have the code written but need to test now.

I agree; r53.class is overkill compared to the updated API. I've been busy at work and haven't finished rewriting. If you want someone to test it with you, I'll volunteer.

Okay. I'm hoping to finish the original replacement code tonight and I will pass along a GitHub repo. I guess a different issue would be in order for replacing the class and fixing the current issues and leave this as the feature add?

The code is at https://github.com/jxmx/pfsense/commit/cc5adcaa679686e54e4035fa5bc283b1cac085a2. The code has an AWS signing key error. Getting the AWS keys to work is finicky. I also opened a new issue for replacing the r53.class.

Figured out my bug and an XML tag error. This now works so far in my testing - https://github.com/pfsense/pfsense/compare/master...jxmx:6751_route53. I've opened 6751 for the replacement of r53.class.

Matt, you mentioned you submitted a Pull Request, what is the #?