Project

General

Profile

Feature #6728

Route53 API mod and Geolocation

Added by Matt Williams 11 months ago. Updated 7 months ago.

Status:
Needs Patch
Priority:
Low
Assignee:
Category:
Dynamic DNS
Target version:
Start date:
08/18/2016
Due date:
08/26/2016
% Done:

50%

Estimated time:
2.00 h

Description

This is a request to modify/simplify the POST Route53 API for Dynamic DNS. One correction and two enhancements are required;

1. Migrate from sequential DELETE/CREATE actions to UPSERT, which can handle creates and updates for all relevant attributes. This addresses bug #3973, and is the recommended implementation of the Route53 API.
2. Include SetIdentifier in the form and class(es) to support weighted, latency, geolocation or failover record sets (API will attempt to create new record and fail if this is not provided on W/L/G/F record sets)
3. Since this request is specific to geolocation functionality, including ContinentCode, CountryCode and SubdivisionCode attributes on the from and in the class(es)

Use Case: WLGF record sets can be used to direct traffic to an appropriate location. For site-site pfSense implementations, this could prove effective for road-warriors when tunneling source nets. A positive consequence: geolocation can also be used to mask IP addressing when queried outside of the DNS scope (AWS will return a no-answer). This is not the intended deployment scenario, but can help thwart botnet queries if implemented to do so.

Assigning to myself since I intend to have this submitted as a pull request this evening.

History

#1 Updated by Matt Williams 11 months ago

  • 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

#2 Updated by Jason McCormick 11 months ago

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.

#3 Updated by Jason McCormick 11 months ago

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.

#4 Updated by Matt Williams 11 months ago

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.

#5 Updated by Jason McCormick 11 months ago

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?

#6 Updated by Jason McCormick 11 months ago

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).

#7 Updated by Matt Williams 11 months ago

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/*"
}
]
}

#8 Updated by Matt Williams 11 months ago

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

#9 Updated by Jason McCormick 11 months ago

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.

#10 Updated by Jason McCormick 11 months ago

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.

#11 Updated by Matt Williams 11 months ago

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.

#12 Updated by Jason McCormick 11 months ago

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?

#13 Updated by Jason McCormick 11 months ago

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.

#14 Updated by Jason McCormick 11 months ago

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.

#15 Updated by Jim Pingle 10 months ago

  • Target version changed from 2.3.2_1 to 2.4.0

#16 Updated by Renato Botelho 8 months ago

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

#17 Updated by Renato Botelho 7 months ago

  • Status changed from New to Needs Patch
  • Target version changed from 2.4.0 to Future

Target to future while we wait for the patch

Also available in: Atom PDF