Public and Private DNS in Route53 about octodns-route53

[ross]

Not familiar with a setup that uses a single zone for both internal and external records and octoDNS doesn't have any Route53 code specific to handling that sort of set up. We manage dozens of internal zones and dozens of external zones, but nothing that's both.

[yzguy]

octodns/octodns#260 and octodns/octodns#190 are essentially the same thing. It's somewhat trivial to add it just looking at public hosted zones or private hosted zones. The tougher part is how to keep them in config/dump because with a very basic configuration one would overwrite the other.

I believe your earlier response: octodns/octodns#260 (comment) is probably the way to go

You would have providers configured like

  route53:
    class: octodns.provider.route53.Route53Provider
    access_key_id: env/AWS_ACCESS_KEY_ID
    secret_access_key: env/AWS_SECRET_ACCESS_KEY

  route53_private:
    class: octodns.provider.route53.Route53Provider
    access_key_id: env/AWS_ACCESS_KEY_ID
    secret_access_key: env/AWS_SECRET_ACCESS_KEY
    private_zones: true

Then you can use them like normal.

I have a draft PR up for the small change but need to work on coverage and hear any feedback: octodns/octodns#421

This would be somewhat of an impactful change for people who use OctoDNS for private hosted zone management already, as they would need to go add the private_zones: true to their provider.

[opardalis]

Thanks, I use that info above to make it work. Honestly, I just need to get the data out of Route53 via octodns-dump, we're migrating to a new provider and in the future the public/private wont be over the same domain again. The dump saves me time since we have so many records.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[ross]

From: octodns/octodns#728 (comment)

is there any opened issue for this in the new repo.

Doesn't look like it. I guess it stalled out and was forgotten about. My gut says that the VPC-ID would be better tied to provider rather than per zone, that way you could do things like:

providers:
  vpc-1234:
    ...

  vpc-2345:
    ....

zones:
  something.in.both.:
    sources:
      ..
    targets:
      - vpc-1234
      - vpc-2345

Don't off-hand know if that'll run into any problems. Working on Route53Provider is annoying as it costs me $ out of my own pocket, so if you have a TAM or any connections there i'd be nice if they could do something like a lot of the other providers and provide some sort of test account or credits.

[ross]

Reopening this while I'm investigating things, but this is looking really complicated. My above thinking of doing vpc_id isn't really viable even if it was switched to an array vpcs.region/id. Problem is that if the vpc associations are changed there's nothing saying which one in the config matches which in Route53 since they're many-to-many. Same is true if the metadata is associated with the Zone as @yzguy originally suggested, just in the opposite direction. It would require some sort of manual association or external state to record the mappings.

Going to poke around a bit more, but not seeing an obvious path and the non-obvious ones are enough work that it's not going to happen short of someone interested in paying for the research & development required.

[ross]

OK. So I think this is doable, but as mentioned above more involved than I have the time to devote to it as free/OSS work atm. Mostly the API for managing this stuff is multi-step and thus requires lots of edge case and error handling as well as the complications involved in keeping the associated VPCs in sync.

Going to leave this here & open atm. The bot will auto-close if it ends up sitting.

/cc @JohanLeirnes fyi