Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Traffic Ops /api/1.4/cdns/name/{name}/dnsseckeys returns 500 if Snapshot or DS TTL Parameter doesn't exist #3204

Closed
rob05c opened this issue Jan 10, 2019 · 1 comment · Fixed by #3206
Labels
bug something isn't working as intended Traffic Ops related to Traffic Ops

Comments

@rob05c
Copy link
Member

rob05c commented Jan 10, 2019

The problem is, the 1.4 endpoint adds the DS Record text, which must come from the Snapshot, and which requires the DS TTL to construct.

There are a few ways we can fix this

  1. Still require those things, and return a 400 with a helpful message if they don't exist, e.g. "CDN must be snapshotted", "a Parameter name 'tld.ttls.DS' config file 'CRConfig.json' must exist on the profile of a server on this CDN".
  2. Automatically create an initial Snapshot when a CDN is created.
  3. Automatically create a Parameter when a CDN's DNSSEC is turned on. This may not be possible, because the Parameter currently must be on a Server's Profile, and no servers may exist.
  4. Use a default TTL if the Parameter/Snapshot doesn't exist. This should be the same default the Router uses, if the TTL doesn't exist in the CRConfig. I'm not sure this is an acceptable solution, if the Router has no default.
  5. Move the mandatory tld.ttls.DS data to a table/row which must exist if DNSSEC is enabled. I know we aren't willing to do that work, but I feel obligated to note it's a solution, and the ideal solution which will make errors like this impossible.

My current intention is #4, and log a warning. It's not ideal, but it's relatively quick to implement, and mostly right.

I specifically do not think we should simply omit the DS Record from 1.4 if we can't create it. The new version is defined to return it, and it could break any number of things if it simply isn't there.

@rob05c rob05c added bug something isn't working as intended Traffic Ops related to Traffic Ops labels Jan 10, 2019
@rob05c
Copy link
Member Author

rob05c commented Jan 10, 2019

@jhowell-comcast if you have any comments/suggestions.

rob05c added a commit to rob05c/trafficcontrol that referenced this issue Jan 11, 2019
rob05c added a commit to rob05c/trafficcontrol that referenced this issue Jan 18, 2019
@elsloo elsloo closed this as completed in a96b466 Jan 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug something isn't working as intended Traffic Ops related to Traffic Ops
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant