FCrDNS does not resolve to Fitbit

[pstickne]

Servers are receiving push notifications from a DNS (resolved from IP) entry not ending in .fitbit.com - in particular, the reported IPs resolve to google cloud DNS entries. Change from previous behavior occurred 0830 PST on 17MAY.

[pstickne]

Actually, I looks like the IPs have "never" resolved to .fitbit.com, but a different proxy, hmm. The results below are using an explicit name server connected over a non-corporate network:

nslookup - 4.2.2.1
Default Server: a.resolvers.level3.net  (Using Level 3 NS explicitly)
Address: 4.2.2.1

> 35.192.192.240  This is the "new IP seen"
Server: a.resolvers.level3.net
Address: 4.2.2.1

Name: 240.192.192.35.bc.googleusercontent.com
Address: 35.192.192.240

> 75.126.122.162  This is the IP given in the FCrDNS example. It does not resolve to a Fitbit domain.
Server: a.resolvers.level3.net
Address: 4.2.2.1

Name: a2.7a.7e4b.ip4.static.sl-reverse.com
Address: 75.126.122.162

So, "what might be going on?"

[pstickne]

It appears

1. A reply of mine with useful information was deleted without notification or remaining placeholder (which is just rude, please leave a placeholder like "message deleted"), and;

2. Fitbit FCrDNS appears to have "never resolved" to '.fitbit.com' on our subscription notification servers. The change on 17MAY resulted in 'exceptions' being incorrect. However, as even the example given in the Fitbit FCrDNS tutorial fails to resolve to '.fitbit.com' as the domain (https://dev.fitbit.com/build/reference/web-api/subscriptions/), and I'm unable to "validate" that the Fitbit FCrDNS is (or has been) functioning as described.

[Gordon-C]

Hi @pstickne 

My apologies if your post was deleted.  I'll see if I can find out what happened and send you a private message.

Regarding your FCrDNS problem, would you please private message me the exceptions you're receiving, the exceptions your expecting and your client ID.  I'll check with our team.

Thanks!

Gordon

[pstickne]

@Gordon-C I will send a private message with specific details around non-public information.

However, to clarify this thread, 'exceptions' refers to the set of white-listed domains we accept 'as probably Fibit'. While the ideal solution would be to only FCrDNS against '.fitbit.com', this is not how the IPs of the hosts that send us messages have resolved (for years). The previous developers decided to add an 'exception' list. The resolved DNS name changed on Friday, invalidating the 'exceptions' white-list. I am in the process of increasing the robustness of the interchange.

Here the whois ( http://whois.domaintools.com/75.126.122.162 ) of one of the IPs that previously sent us Fitbit notifications. This is the same IP as used in the FCrDNS example.

This probably resulted in the correct hostname as some point because the Fitbit FCrDNS example shows the following (no longer correct) output:

$ host 75.126.122.162
162.122.126.75.in-addr.arpa domain name pointer api-75-126-122-162.fitbit.com.
$ host api-75-126-122-162.fitbit.com
api-75-126-122-162.fitbit.com has address 75.126.122.162

[Gordon-C]

Hi @pstickne 

Thank you for the additional information.  We've determined there is a problem with resolving the IP addresses to the *.fitbit.com domain.  We have an open ticket with Google to get this resolved.  I'll update this post when the problem is resolved.

Gordon

[Gordon-C]

We are investigating a solution for Forward-Confirmed Reverse DNS (FCrDNS).   In the meantime, we do have a recommend method in our documentation for verifying the signature using the X-Fitbit-Signature HTTP header.  This method uses your client secret which is unique to your application.  No one else should have access to your client secret unless your system has been compromised. 

Please review the X-Fitbit-Signature Header section.  It should provide a secure method to verify  notifications are coming from Fitbit.

https://dev.fitbit.com/build/reference/web-api/subscriptions/#security

[Gordon-C]

It appears GCP doesn’t support masking the IP address such that FCrDNS will report the hostname as a subdomain of fitbit.com.  We do have a recommended method in our documentation for verifying the signature using the X-Fitbit-Signature HTTP header.  This method uses your client secret which is unique to your application.  No one else should have access to your client secret unless your system has been compromised. 

Please review the X-Fitbit-Signature Header section and see if this works for you.  It should be a more secure way to verify the notifications are coming from Fitbit.

https://dev.fitbit.com/build/reference/web-api/subscriptions/#security