3 ms·

>You don’t have an “IP address service”, resources just have addresses and then you can query for a flat list of them if you like. >DNS ought to work the same

>You don’t have an “IP address service”, resources just have addresses and then you can query for a flat list of them if you like. >DNS ought to work the same way in the cloud: resources should just “have” DNS addresses and those should vanish with the resource if it’s cleaned up. Yes, those are what Azure DNS calls alias records. If you use Azure DNS then you can use them. Otherwise you have to resort to CNAME records. Alias records also have the benefit that they flatten automatically to save the client one or more hops.

jiggawatts 3y ago
That's true, but those "alias records" are created as a sub-resource of the DNS Zone parent resource. In Windows Server Active Directory integrated DNS zones, the records are registered and maintained by the computers themselves. So if a server is assigned 10.1.2.3 as its IP address, it'll register itself in DNS without someone having to go into the DNS Server and add an alias record for it. Similarly, certificates shouldn't be "under" a Key Vault, they should be linked to the DNS record. It should all work like DHCP + ACME as seen in Let's Encrypt. Within a single cloud, there's no need to emulate the traditional system boundaries. E.g.: If I create a virtual machine with DNS name "foo.bar.com" and a public IP address of "1.2.3.4" it should register itself into that zone, and then un-register itself if the VM is deleted. It should also get a matching certificate (for free!) without any TXT records or manual steps. Weirdly, some things already work this way, inconsistently. Azure Front Door automatically issues certificates. App Service auto-registers itself in DNS, mostly. Virtual Machines can register themselves for Private DNS Zones, but won't get certificates... unless they're AD domain joined and have an Enterprise PKI available. It's such a mess.

jiggawatts 3y ago

That's true, but those "alias records" are created as a sub-resource of the DNS Zone parent resource. In Windows Server Active Directory integrated DNS zones, the records are registered and maintained by the computers themselves. So if a server is assigned 10.1.2.3 as its IP address, it'll register itself in DNS without someone having to go into the DNS Server and add an alias record for it. Similarly, certificates shouldn't be "under" a Key Vault, they should be linked to the DNS record. It should all work like DHCP + ACME as seen in Let's Encrypt. Within a single cloud, there's no need to emulate the traditional system boundaries. E.g.: If I create a virtual machine with DNS name "foo.bar.com" and a public IP address of "1.2.3.4" it should register itself into that zone, and then un-register itself if the VM is deleted. It should also get a matching certificate (for free!) without any TXT records or manual steps. Weirdly, some things already work this way, inconsistently. Azure Front Door automatically issues certificates. App Service auto-registers itself in DNS, mostly. Virtual Machines can register themselves for Private DNS Zones, but won't get certificates... unless they're AD domain joined and have an Enterprise PKI available. It's such a mess.