I've transitioned to a new DevOps role at a different company after working in a big corporation where things were pretty standard. Now, with this outsourcing setup, I've noticed some practices that are faster but not necessarily correct. I usually worked with one project per subscription, but now we have multiple projects grouped within a single subscription and separated by resource groups.
The issue arises with the naming of the private DNS zone. Here's what I've got:
The private DNS zone name appears as [pgsql-xxxxx-dev.private.postgres.database.azure.com](http://pgsql-xxxxx-dev.private.postgres.database.azure.com). There's also a hostname/DNS A record like a3e977ewewf, making the fully qualified domain name (FQDN) a3e977ewewf.[pgsql-xxxxx-dev.private.postgres.database.azure.com](http://pgsql-xxxxx-dev.private.postgres.database.azure.com).
The nslookup for this works fine, and I can connect to Postgres from the VNet, but I'm uncertain if this configuration is correct. Previously, I would use one DNS zone in a common/shared resource group for ease of management, and I'd like to confirm whether this setup is good or if there's a better way to organize it. Any help would be appreciated!
2 Answers
It sounds like you might have a bit of a chaotic setup with multiple DNS zones. If you have several different private DNS zones scattered throughout, it could lead to confusion. I recommend using a centralized DNS zone, such as [privatelink.postgres.database.azure.com](http://privatelink.postgres.database.azure.com), where you can link the A records directly to your Azure Database for PostgreSQL resource without the mess. It keeps things neat and manageable!
Just a heads up, for vNet integrated Postgres servers, the DNS zone defaults to private.postgres.database.azure.com. They shouldn't have public IPs, so typically, you won't see the typical privatelink domain used for them. It's generally not great practice to go too deep with subdomains under the private DNS zone’s address—it can cause issues, but it seems to work for some setups like yours. It might be beneficial to rationalize things, given that you're already managing multiple resource groups.
Absolutely! I agree with you. It would be best to consolidate. You mentioned some odd names for the zones—I've seen that happen when junior team members try to avoid confusion but end up making it worse. Sometimes, sticking to naming conventions is crucial, especially when multiple zones exist.