pfSense

Service no longer works in that is receives a signing error even though all details are correct.

I've tested changes and created a pull request to resolve this issue: https://github.com/pfsense/pfsense/pull/3473.

Again please note the need to change how the Zone ID field now requires the region prepended to the zone ID. This seems cleaner than trying to shoehorn another field in no one but Route53 users will use. However this will have to be documented well in the release notes somehow.

Also, wanted to note that the use of v4 signing enables newer regions that didn't support the legacy authentication type.

I tried it, but received an error. Here's the log with redactions:

/services_dyndns_edit.php: phpDynDNS (home.example.com): (Error) Route53 API call failed
/services_dyndns_edit.php: error message: <?xml version="1.0"?> <ErrorResponse xmlns="https://route53.amazonaws.com/doc/2013-04-01/"><Error><Type>Sender</Type><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details. The Canonical String for this request should have been 'POST /2013-04-01/hostedzone/XXXXXXXXXXX/rrset content-type:text/xml host:route53.amazonaws.com x-amz-date:20170302T021712Z content-type;host;x-amz-date bd949ca9fd38158acb171c46732a582b4c09bf43839ae2588fb76106c0315f9f' The String-to-Sign should have been 'AWS4-HMAC-SHA256 20170302T021712Z 20170302/us-east-1/route53/aws4_request 011e7fcf0327585f97382de6196e1b2af584dc9412a62a0da582363a88520bfa' </Message></Error><RequestId>58aad100-feee-11e6-b0df-ed7636b544a0</RequestId></ErrorResponse>
/services_dyndns_edit.php: Dynamic DNS route53 (home.example.com): _checkStatus() starting.
/services_dyndns_edit.php: XMLPOST: <?xml version="1.0" encoding="UTF-8"?><ChangeResourceRecordSetsRequest xmlns="https://route53.amazonaws.com/doc/2013-04-01/"><ChangeBatch><Changes><Change><Action>UPSERT</Action><ResourceRecordSet><Name>home.example.com</Name><Type>A</Type><TTL>3600</TTL><ResourceRecords><ResourceRecord><Value>XXX.XXX.XXX.XXX</Value></ResourceRecord></ResourceRecords></ResourceRecordSet></Change></Changes></ChangeBatch></ChangeResourceRecordSetsRequest>
/services_dyndns_edit.php: Header: Authorization: AWS4-HMAC-SHA256 Credential=XXXXXXXXXXXXXXXXXXXX/20170302/us-east-1/route53/aws4_request, SignedHeaders=content-type;host;x-amz-date, Signature=f6c6b226426515071d2d853fbbb4b4d2e948a732f29a709284c36219bf3f6cc6

It tried it with two different sets of credentials.

Also, as far as I can tell, since Route 53 is global in scope, the region used for credentials is always us-east-1. In their request template in the docs us-east-1 is not in red and should therefore be constant.

I've looked for evidence that the only Route53 region is US-EAST-1 and I've never been able to find a definitive statement about that. The documentation seems to imply that but I didn't want to make a false assumption on that. It's easy to hard-code that if it's true, but I'd like to see real documentation that effect. I'll have to look again.

That error you're getting is an incorrect public/secret key pairing. I've had a weird problem with the Pfsense UI + Firefox inserting a space at the end of pasting in some fields. Make sure you don't have an extra space at the end of any of the Dyndns fields. I'll dig up the test harness code I wrote to test this and send it to you.

I created new credentials and it worked this time. I'm not sure what went wrong before. Is there any chance that certain base64 characters like "=" or "/" could cause a problem?

I'll try out the test code and let you know if I find anything, but for now I'd say it works.

Concerning the region, this site shows Route 53 API endpoints only existing in us-east-1: [[http://docs.aws.amazon.com/general/latest/gr/rande.html#r53_region]]. Putting in the us-east-1 in the form is not a big deal, but if we don't need to do it, it would make it less confusing. I'm no AWS expert, so independent confirmation that us-east-1 is the only region for Route 53 would be nice.

Glad you got it working. There shouldn't be anything coding unsafe with base64. Feel free to look through the signature generation code but every string is hashed and the final output is encoded so it should be HTTP-safe.

Thanks for digging up that link about us-east-1. I never came across that before so that seems pretty definitive. I'll update this branch in Github to remove the need to change the UI to add the region.

Here's a diff on my pfsense fork: https://github.com/pfsense/pfsense/compare/master...jxmx:7206_route53

I don't have any more time to test this tonight but it should work just fine - changes are trivial. I'll test this over the weekend and make a new pull request on the master repo.

Okay I've done more testing with this and I'm getting more random errors that don't make any sense to me. The same code used with the standalone PHP script I included here works flawlessly. However the same calls from the dyndns.class yield non-deterministic behavior. Some of my Route53 entries work (at one point they all did!), yet some don't now. But they're all using the same IAM keypair. If I add a new entry, it uniformly fails. But Doug you reported you added one and it started working. So now I'm very confused.

It helps if I completely reverted the items I changed for the region being added to the zone. Just needed to step away from the code for a bit. I've tested this with existing and new entries and everything works now. Doug, if you could give this diff a whirl.

https://github.com/pfsense/pfsense/compare/master...jxmx:7206_route53

Pull #3608

Applied the patch. It works. Thanks!