Question about FQDN vs CNAME fields in Dangling DNS script
Gleland opened this issue · comments
Hi everyone,
At my company we've been reading up on Azure's recommendations for how to detect dangling DNS records, and came across this repository. I'm curious if there's a specific reason why the FQDN value is being assigned to the CNAME field for a given record set. Here is one example, but it occurs in multiple places, including in the final logic for determining if a given record is dangling or not.
Thanks for your time!
Hello @Gleland
Thank you for the feedback. We are looking into this issue and we will provide a feedback shortly
@Gleland The script scans only CNAME records in the zone. The CNAME field for a records is where the target for the CNAME record is populated. This is why that field is being read everywhere in the code.
@abhijeetgaiha Thanks for the quick response! I'm not sure I understand:
- If the CNAME record is the field being checked, why does the script rename it to
FQDNin a few places? - Shouldn't the script actually be checking for the FQDN resource itself (as mentioned in Azure's dangling record documentation)?
@Gleland The script is doing exactly what you describe.
Like I said, the CNAME field is where the target of the CNAME record is stored, which would be the FQDN of the resource.
Ah! @abhijeetgaiha Thank you! I understand now. The canonical name is indeed what the script is referencing when checking for resources. Thank you for clarifying this! For any future readers, these two pages helped me with some more background reading:
- https://en.wikipedia.org/wiki/CNAME_record#Details
- https://datatracker.ietf.org/doc/html/rfc2181#section-10.1.1
I'll close this, thank you for your help!
@Gleland Glad to help!