Fails on nested HostedZones

Hi in our organization we have setup different HostedZones for different nested levels of DNS. For example our HostedZones look like this:

HostedZone 1: example.com
HostedZone 2: stage.example.com

Unfortunately when I use route53 to create a DNS record for "kubernetes.stage.example.com" it wrongfully creates the record in the "example.com" HostedZone. As everything that ends with "stage.example.com" is handled by the "stage.example.com" HostedZone, this obviously doesn't work.

Would it be possible to make route53 choose the HostedZone that is most specific?

I suspect that my issue is also what is mentioned in this comment:

route53-kubernetes/service_listener.go

Line 161 in 5eb3615

    
           // The AWS API may return more than one zone, the first zone should be the relevant one

In my Let's Encrypt controller the logic for finding the most specific zone is rather simple:

route53.listHostedZones().getHostedZones().stream()
        .filter(zone -> fqdnRecord.endsWith(zone.getName()))
        .reduce(((acc, zone) -> {
          if (zone.getName().length() > acc.getName().length()) {
            return zone;
          }
          return acc;
        }));

The theory being that the longest zone-name with a matching suffix is the most-specific one. I don't check whether records are actually delegated to that zone though.

Maybe something similar can be done here to fix the issue.

Thanks, yeah, I haven't used hosted zones like this so I wasn't aware of this use case. But, it's definitely something we could add pretty easily. As you pointed out our HostedZone lookup is pretty naive.

@tazjin thanks for the code, seems like a decent approach.

@iterion That would be awesome!

FYI, made #28 to address this. I haven't tested it yet but it should be close.

@FrederikNS I just tested #28 so I'm going to merge it shortly. I also created a new docker tag @ quay.io/molecule/route53-kubernetes:v1.3.0 that includes the changes.

I'm going to close this issue, but please reopen if the problem still exists for you.

Thank you @iterion, I just tried it out and it worked flawlessly!

I appreciate the quick resolution