18 votes2 comments · Networking » Domain Name Service (DNS, Traffic Manager) · Flag idea as inappropriate… · Admin →
Thank you for your suggestion on feedback.azure.com for Dynamic DNS support in Azure DNS.
Please can you clarify a couple of points about your suggestion for us:
1. Are you looking for Dynamic DNS support for Internet-facing domains, or for internal domains?
2. In the case of Internet domains, how would you expect requests to be secured?
I'd expect it to operate exactly like dyndns and noip and other services do. Azure DNS doesn't even have internal domains, does it?
I wrote a Functions app to implement dyndns2, actually. If you're curious what I'm thinking of.
This is implements the dyndns2 protocol. Accepts BASIC authentication. Uses that to scan the configured subscription for the matching Azure DNS zone, and then updates the specified record.
876 votes46 comments · Networking » Domain Name Service (DNS, Traffic Manager) · Flag idea as inappropriate… · Admin →
Thanks you for the suggestion. This remains a key backlog item for us.
We’d be interested in further input via your comments. Please consider the following questions:
– Do you require zone transfers in to Azure DNS, or zone transfers out? Why?
– Do you require AXFR or IXFR?
– How should zone transfers be secured?
I'd like to add onto this: you should be able to extend the DNS secondary into a VNet. So as to export from an AD DC.
Hi Deane, thank you for the feedback, This is a good ask, we are actively looking into it. This is in our road map.
— Anavi N [MSFT]
Because that's not how routing works.
The next-hop has to actually be reachable from subnets connected to the router. You know, the next router.
And how would they do that, since they don't even know the login is part of your organization until AFTER you select it.
Thank you for all the votes and feedback. We have started work on this and the capability will be supported soon. If you would like to get in touch with us to discuss your scenarios, please fill this form: https://aka.ms/ApplicationGatewayCohort
Probably should not happen. This would require .NET type information to move across the wire where you probably don't want it to. The caller would have the ability to spawn instances of types on the remote service.
You are free to build the Service Fabric cluster yourself, using your own ARM templates. Multiple Load Balancers are possible, as are custom VM images and everything else.
You can put your Actor interface type directly on the Actor state DataContract. The framework already manages to internally convert this to an ActorReference when it needs to, and back again.