aws-samples / aws-lambda-ddns-function

Dynamically create Route 53 resource records using CloudWatch Events and Lambda
Apache License 2.0
236 stars 116 forks source link

Wrong CNAME/A records created with private domain name #22

Closed bossastudios-ltd closed 5 years ago

bossastudios-ltd commented 7 years ago

I've created a VPC with an associated private DNS zone, us-east-2.mydomain.com and created all of the necessary roles, and scripts which create associated records when a new machine is created in the VPC. I have also associated a DHCP option set with domain-name = us-east-2.mydomain.com and domain-name-servers = AmazonProvidedDNS

I've noticed that it creates the A records like this:

ip-10-0-0.100.us-east-2.mydomain.com A 10.0.0.100

which seems reasonable, but the CNAME entry beneath it is:

myserver.us-east-2.mydomain.com CNAME ip-10-0-0-100.us-east-2.compute.internal

Which kinda goes against most of my instincts as a DNS admin, to resolve that CNAME, you'll have to make extra queries, instead of being able to request it directly from route53.

Is this by design, is there some other option I can modify to have the CNAME point to the A record created by your script?

bossastudios-ltd commented 7 years ago

As an aside, to get the lambda working consistently, the 30 second timeout just isn't enough, as mentioned earlier, 5 minutes seems to be overkill, but does mean that the script executes every time.

jicowan commented 7 years ago

@bossastudios thanks for the feedback. I'm not sure I follow your first comment about extra queries. Can you explain how the CNAME that is created by the function creates additional DNS queries? The function purposely creates an A record with the VPC provided hostname for the instance. If you want to refer to the instance by another name, you have to use the CNAME tag. You could modify the code to change this behavior so it uses a tag value for the host name, but that's not the way I wrote it. With regard to your second comment; I should probably update the CFN template to create the DDB table. That's what takes the longest to complete. Once the DDB table is created, you can probably lower the timeout to 30 seconds. -J

bossastudios-ltd commented 7 years ago

OK, so what strikes me is odd is the creation of a us-east-2.mydomain.com A record, which is then referenced nowhere.

You're going through the effort of creating a proper A record and but both the PTR record and the CNAME record are referencing a different zone compute.internal, normally, in a zone file you create an A record, then point your CNAMES, and your PTR record to that A record, not another A record outside that zone file (unless the zone you're pointing to is not administered by you).

My point about extra queries is this:

I want to find myserver.us-east-2.mydomain.com, so my server makes a request to 10.0.0.2 asking "what IP address does myserver.us-east-2.mydomain.com point to?" The DNS server for us-east-2.mydomain.com responds "I don't know, all I know is that it points to ip-10-0-0-100.us-east-2.compute.internal " So then either the DNS server, or my server needs to find out who is responsible for the us-east-2.compute.internal domain, then go ask that server "what IP does ip-10-0-0-100.us-east-2.compute.internal point to?"

It's an extra step, and rather redundant considering that there's an A record for that machine in my zone, and my DNS server could be responding to the entire query in one reply.

Does that explain things a bit better?

I could be coming from a too traditional DNS background, possibly there are reasons you are doing this, I'm trying to understand if there are technical reasons, or it's something that I can adjust in my configuration to use a single zone file.

As for the timeout, I find most of the lambda logs end up around this sort of time (around 65 seconds I think?) and this is just an update, the DB table and record exist for this instance.

' 09:37:19 Updating PTR record 65.10.33.172. in zone in-addr.arpa  09:37:19 No matching zone for AmazonProvidedDNS.  09:37:19 END RequestId: e806454e-50e4-11e7-bf75-0fa8758620e0  09:37:19 REPORT RequestId: e806454e-50e4-11e7-bf75-0fa8758620e0 Duration: 65212.82 ms Billed Duration: 65300 ms Memory Size: 128 MB Max Memory Used: 67 MB'

jicowan commented 7 years ago

Did you say you were using a private hosted zone and a DHCP option set? How is your DHCP option set configured? I initially wrote this to support EMR when it's deployed onto a private subnet which required instances to resolve their own FQDNs. This was fixed in a 5/5.1 release so you no longer need to use this solution for EMR. I'm not really sure why the script created an A record for us-east-2.mydomain.com. I'd have to see how your private hosted zone and DHCP option set are configured.

bossastudios-ltd commented 7 years ago

I'll gladly share whatever info you need..

I'm using mydomain.com as a placeholder, but everything else is correct.

My DHCP option set is configured like this:

DHCP options set ID: dopt-dff00ab6 | UsEast2_domain Options: domain-name = us-east-2.mydomain.com domain-name-servers = AmazonProvidedDNS

I associated the private domain I created in route 53 with the VPC:

Domain Name:us-east-2.mydomain.com. Type:Private Hosted Zone for Amazon VPC Associated VPC: US_EAST2 | vpc-7057ae19 | us-east-2

Do I possibly need to change the DNS server type? Run my own DNS servers? I was planning to set up some forwarders in each VPC to allow people in our office to resolve internal VPC names without having to SSH into instances or check EC2 for the IP..