Handle MS AD (or similar) zone where the forward zone is not owned by Route 53 local zone

[cho00013]

per @badra001

Hi. I have enabled the dynr53 code in a different account and region. I'm about to do a second one.

One thing that just came up -- Windows hosts. They get an A record added automatically to csp1.ead.census.gov by Windows itself (through DDNS). We need to add the PTR (and associated TXT).

If we have the host with the following tags:

Name = edlw001appd
boc:dns:zone = csp1.ead.census.gov

It will not have a valid zone for the A and its associated TXT record.

However, the PTR zone is available. Do you recall if we will handle just a PTR (+TXT) if the forward zone doesn't exist?

[cho00013]

per @badra001

Ok, here is what happened with this host.

Tags:

• Name = edlw001appd
• boc:dns:zone = csp1.ead.census.gov

stop and start

• It got A and TXT with the DNS domain of the VPC
• edlw001appd.dev.edl.census.gov
• PTR and related TXT for that same VPC domain.

It did not use the boc:dns:zone. It is expected that it would not use it for the A and its TXT records, as that domain does not (and cannot) exit in route53.

However, I'd like the PTR and the PTR TXT to use this domain.

Now the question is, how do we enable that behavior?
new tag boc:dns:ptr_zone
new tag with option of some sort
code to pass a set of domains that should be treated as PTR only
windows hosts update their own A (or AAAA) records
new Lambda variable PtrOnlyZones = comma separated list, like ead.census.gov, csp1.ead.census.gov, boc.ad.census.gov, ad.census.gov, etc
but do we WANT only the PTR set here? Do we also want some sort of A or TXT here, even if it is wrong?
do we instead make this a CNAME to the real FQDN (with the AD zone)?

[cho00013]

per @badra001

I was thinking about it more today.

Create a tag boc:dns:options on the instance

1. all (default, equivalent to cname,forward,reverse)
   creates A/AAAA and TXT
   creates PTR and TXT
   creates CNAME if present
2. cname (only)
   only creates CNAME if present
3. forward (only)
   only creates A/AAAA and TXT
4. reverse (only)
   only creates PTR and TXT
5. none (conflicts with all, cname, forward and reverse)
   creates NO entries (like, if we want to manually populate it)

But it would be nice to have an option to register a different domain for a PTR vs the A/AAAA. For that we may need boc:dns:name_reverse

[badra001]

from @cho00013

parsing through the script and email. Created an issue for this to track it in case.
#29

• Name = edlw001appd
• boc:dns:zone = csp1.ead.census.gov
• VPC Associated R53 Domain = dev.edl.census.gov
• DHCP Option associated domain = dev.edl.census.gov (?? can you confirm)

Yes, the result sounds right - the logic always uses the R53 associated VPC domains either DHCP scope domain OR boc:dns:zone specified but it needs to be a Route 53 private hosted zone associated with the DNS. So even though you specified "csp1.ead.census.gov" in the tag, it is not considered as a valid domain since it is not R53 PHZ.

So what we need is some trigger to let the script know that a custom zone is being used that is not VOC Associated Route 53 PHZ.

• boc:dns:options
  • all (default, equivalent to cname,forward,reverse)
    • creates A/AAAA and TXT
    • creates PTR and TXT
    • creates CNAME if present
  • cname (only)
    • only creates CNAME if present
  • forward (only)
    • only creates A/AAAA and TXT
  • reverse (only)
    • only creates PTR and TXT
  • none (conflicts with all, cname, forward and reverse)
    • creates NO entries (like, if we want to manually populate it)

Few thoughts to your proposal.

1. If boc:dns:options is not specified or empty, it is "default" or all.
2. I think we need another option -- something like "non-phz" or ("custom-zone") that signifies that the zone is NOT on Route 53 but the zone is valid and it will handled by "outside" solution that will create the proper records (forward entries) in that zone, and only worry about the PTR/TXT record and also the CNAME if that CNAME is in the R53 zone. I think that will solve your AD issue.
3. Regarding the other options:
   • none -- I guess that just tells the script to ignore creating anything, so disable DDNS for its record.
   • customzone (or whatever) - the forward zone is somewhere else, only handle records that it owns (PTR and possibly CNAME)
   • cname - I don't think it is necessary if we handle TXT records #2 above.
   • forward - I guess it would make sense if somehow we needed to skip PTR creation.
   • reverse - would this be handled by the TXT records #2?

So the logic introduction and change is actually going to take some time to redo and re-write. How urgent do you think this is? Reading the option should not be that big deal but we will need to modify good chuck of the logic to do what we intend.

Anyway, let me know what you think. I might be able to spend some time next week but may not be devote to it until sometime the week after.

[badra001]

from @cho00013

parsing through the script and email. Created an issue for this to track it in case. #29

• Name = edlw001appd
• boc:dns:zone = csp1.ead.census.gov
• VPC Associated R53 Domain = dev.edl.census.gov
• DHCP Option associated domain = dev.edl.census.gov (?? can you confirm)

Yes, this is the case.

Yes, the result sounds right - the logic always uses the R53 associated VPC domains either DHCP scope domain OR boc:dns:zone specified but it needs to be a Route 53 private hosted zone associated with the DNS. So even though you specified "csp1.ead.census.gov" in the tag, it is not considered as a valid domain since it is not R53 PHZ.

So what we need is some trigger to let the script know that a custom zone is being used that is not VOC Associated Route 53 PHZ.

• boc:dns:options

  • all (default, equivalent to cname,forward,reverse)

    • creates A/AAAA and TXT
    • creates PTR and TXT
    • creates CNAME if present

  • cname (only)

    • only creates CNAME if present

  • forward (only)

    • only creates A/AAAA and TXT

  • reverse (only)

    • only creates PTR and TXT

  • none (conflicts with all, cname, forward and reverse)

    • creates NO entries (like, if we want to manually populate it)

Few thoughts to your proposal.

1. If boc:dns:options is not specified or empty, it is "default" or all.

Yes.

2. I think we need another option -- something like "non-phz" or ("custom-zone") that signifies that the zone is NOT on Route 53 but the zone is valid and it will handled by "outside" solution that will create the proper records (forward entries) in that zone, and only worry about the PTR/TXT record and also the CNAME if that CNAME is in the R53 zone. I think that will solve your AD issue.

The option of reverse implies the zone can be anything. Obviously, the PTR zone has to be in R53, but what it points to can be anything, and would come from the boc:dns:name trag.

3. Regarding the other options:

   • none -- I guess that just tells the script to ignore creating anything, so disable DDNS for its record.

Yes. We may want a TXT only one too. heritage.

• customzone (or whatever) - the forward zone is somewhere else, only handle records that it owns (PTR and possibly CNAME)

I don't think this is needed. A combination of reverse and the tag boc:dns:name will handle that.

• cname - I don't think it is necessary if we handle TXT records #2 above.

We may want a cname for a Windows hosts, so yes.

• forward - I guess it would make sense if somehow we needed to skip PTR creation.

RIght.

• reverse - would this be handled by the TXT records #2?

So the logic introduction and change is actually going to take some time to redo and re-write. How urgent do you think this is? Reading the option should not be that big deal but we will need to modify good chuck of the logic to do what we intend.

Anyway, let me know what you think. I might be able to spend some time next week but may not be devote to it until sometime the week after.

If you can't work on it, that's fine, I just wanted some thoughts on it.

[badra001]

I'd like to remove "only" from the description. We woudl have options:

• all, default, null: do everything == forward,reverse,cname,heritage
• forward (a/aaaa, txt)
• reverse (ptr, txt)
• cname (cname, txt)
• none (no entries)
• heritage (txt for forward and reverse only)

[cho00013]

I'd like to remove "only" from the description. We woudl have options:

• all, default, null: do everything == forward,reverse,cname,heritage
• forward (a/aaaa, txt)
• reverse (ptr, txt)
• cname (cname, txt)
• none (no entries)
• heritage (txt for forward and reverse only)

Do you think you can come up unique use-case scenarios?

Here's 3 that I can think of currently - there are probably some variation of them. But for each use-case, we can map out what the "tag option" values should/could be that will support that scenario.

1. Route 53 zones exists for forward and reverse zones and associated with the VPC.
2. Forward zone is owned by different system (e.g. Microsoft AD), and the reverse zone owned by VPC/Route53
3. Neither forward or the PTR zones are owned by the VPC/Account

[cho00013]

Yes, let's get the use-cases ironed out so that we know exactly what options exists. So for each use-case, you should determine what the tag options should be.

if you look at the code and look at section 644, you can add the different use-case to the logic where A records are created. The actual code below that creates the A/PTR should also be modified slightly to to skip creation based upon the tag option.

But the custom zone option must come before the "default" behavior.

The CNAME portion would require looking at line 924 and adding additional boolean check.

Let me know if you need help but few recommendations:

1. Test things in an account that has no impact (so not in ma8 🙂)
2. Error handling is huge since no handling may result in incorrect/incomplete records which require cleaning up).
3. For each use-case, make the change and confirm that the result provides exactly what you're looking for.
4. Also for try different tag combinations to see if they result in the proper "end result". Sometimes, you will see that what you expected doesn't quite result in what you're looking for.

I think you figured it out but stopping and starting the instance basically performs the test. Instead of stopping/starting, you can also find the actual event definition and test it directly on the Lambda by creating the test event.

[badra001]

I can easily start/stop some test instances.

Thanks.

[badra001]

I think the first one to implement is "none" which means I could then just manually (through TF) add the PTR entry. We have only one instance in the EDL account for this, but on the main govcloud ones we have a lot. As they all are created by CloudForms in do2-govcloud, that has to be working properly without any manual intervention.

[cho00013]

I think the first one to implement is "none" which means I could then just manually (through TF) add the PTR entry. We have only one instance in the EDL account for this, but on the main govcloud ones we have a lot. As they all are created by CloudForms in do2-govcloud, that has to be working properly without any manual intervention.

Does it make sense to have a global ENV on the Lambda that basically skips DDNS functions no matter what's in the instance? So you can deploy the solution to that Account, but it really doesn't do anything.

So DDNS_Enable = False would mean that that script just exits without doing any other validation.

Anyway, might be good way to quickly disable the solution in a particular account without potentially deleting the stack/resources. The other option is to disable the event rule that creates the trigger but that may not be as obvious.

[badra001]

I think the first one to implement is "none" which means I could then just manually (through TF) add the PTR entry. We have only one instance in the EDL account for this, but on the main govcloud ones we have a lot. As they all are created by CloudForms in do2-govcloud, that has to be working properly without any manual intervention.

Does it make sense to have a global ENV on the Lambda that basically skips DDNS functions no matter what's in the instance? So you can deploy the solution to that Account, but it really doesn't do anything.

So DDNS_Enable = False would mean that that script just exits without doing any other validation.

Anyway, might be good way to quickly disable the solution in a particular account without potentially deleting the stack/resources. The other option is to disable the event rule that creates the trigger but that may not be as obvious.

I don't want to skip everything, just the Windows ones.

But, a rapid bypass, maybe ..