googlecloud.getHostedZone doesn't work correctly for CNAMEs that cross zones

[ixdy]

In my Google cloud project, I have two domains and two zones:

• example.com, with google cloud dns zone example-com-zone
• example.net, with google cloud dns zone example-net-zone

Subdomains on example.com and example.net are synonyms of each other, so for simplicity, the A records are in example-com-zone, and example-net-zone just has CNAMEs to the equivalent domain in example-com-zone. So for example:

• foo.example.com. A 1.2.3.4
• foo.example.net. CNAME foo.example.com.

Unfortunately, when googlecloud.getHostedZone does a lookup of the SOA record (using acme.FindZoneByFqdn) for foo.example.net, the reported authority is example.com. I've confirmed this with dig -t soa.

As a result, we try to add the txt record in example-com-zone instead of example-net-zone, and the call fails.

[ixdy]

This similarly affects lookupNameservers in acme/dns_challenge.go, which also uses FindZoneByFqdn:

2016/12/06 18:17:22 [foo.example.net] Could not obtain certificates
        Time limit exceeded. Last error: NS ns-cloud-b2.googledomains.com. returned REFUSED for _acme-challenge.foo.example.net.

In this case, ns-cloud-b2.googledomains.com. is the authoritative server for example.com, whereas ns-cloud-c2.googledomains.com is authoritative for example.net.

[tamalsaha]

@ixdy I have tried to address this issue here #336

[ixdy]

@tamalsaha I tried your fix while working on kubernetes-retired/spartakus#16 and it seemed to work. Thanks!

[fd]

#449 Should resolve this issue. The idea is to ignore SOA records that are not a suffix of the domain.

[xenolf]

Close via #449