Extend Azure DNS to support zone transfers so it can be used as seconday DNS
If Azure DNS supported zone transfers, then if could be used both as a reliable secondary DNS service, or as an external proxy service for AD split-brain, or on-premise hosted DNS configurations.
Zone transfer is on our roadmap however not planned for CY 2019.
Sethuraman A commented
We will consider using Azure DNS as the primary and have another provider as backup.
- Do you require zone transfers in to Azure DNS, or zone transfers out? Why?
Both. Initially we would start using Azure DNS as a backup and later we would want to migrate that backup to become the primary.
- Do you require AXFR or IXFR?
It depends on the other providers, so at this point I think support for both makes sense.
- How should zone transfers be secured?
The only thing holding us up from moving to Azure DNS is zone transfers.
– Do you require zone transfers in to Azure DNS, or zone transfers out? Why? - Both, and that allows us flexibility in deciding primary, secondary scenarios in the future. Managing the zone updates between providers of a hosted DNS solution would become very cumbersome.
– Do you require AXFR or IXFR? Both
– How should zone transfers be secured? The same way MS Server DNS handles it today.
100 DNS zones and growing.
Any progress on this task?
In our company (~50 DNS zones) the migration is on hold because you're not supporting the feature
JENOUVRIER Eric commented
A client wanted to use Azure as Virtual Datacenter and extend his Private Network by Express Route. Within this scenario the client already have its private DNS infrastructure with its own solution but not reluctant to Azure DNS if it was possible to integrate it (ie. zone delegation) like
Scenario 1 / client DNS (*.clientprivate) => Azure DNS (*.azure.clientprivate)
Scenario 2 / client DNS (*.clientprivate) => client DNS zone delgation (*.azure.clientprivate =>multiple Azure DNS delegation (*.spoke1.azure.clientprivate, *.spoke2.azure.clientprivate)
Looking for zone transfers to azure to act as secondary name server. IXFR preferred but would like option to do AXFR; Authorization by configured static IPs, or by zone NS records, same as current MS setup.
Zone transfers on to Azure DNS via AXFR.
Based on master and ***** IP similar to MS DNS
George Friend commented
Primarily interested in outbound transfers to local linux server in each office (for disconnected use)
Unsure on AXFR or IXFR
Similar to classic MS DNS, allowed transfer IPs / names would suffice
Mainly looking for IN transfers to use Azure DNS as secondary.
Both AXFR and IXFR, with NOTIFY support, of course.
Authorization by configured static IPs, or by zone NS records.
- Both, please
- Both, please
- VPN tunnel net requirement?
– Do you require zone transfers in to Azure DNS, or zone transfers out? Why?
Both in and out to support secondary DNS and hidden masters
– Do you require AXFR or IXFR?
– How should zone transfers be secured?
by IP address or listed NS like in Windows Server DNS
We would love to use this and give Microsoft some money, but cannot until zone transfers are supported. We are looking for inbound, and outbound. (Inbound would help with the initial setup of hundreds of domains and thousands of records).
We would like to have a secondary DNS provider as well, so that is why we would look for zone transfers out. We have seen cases where an outage or DDoS attack has taken down a DNS service, and need redundancy with a second unrelated provider.
Is this not yet implemented? seems like core functionality to having a DNS service
We'd like to be able to do (secure) zone transfers as well.
Primary: Azure / Secondary: On-premise and vice versa.
We would require zone transfers out of Azure to our own DNS servers.
Both AXFR and IXFR.
TSIG or IP based.
+1 for allow private zone transfer for Azure DNS. It will be a great business case.
Doug Ferguson commented
My main use case would be to leverage Azure DNS to host secondary zones. As a secondary use case, I would plan on hosting a few primary zones in Azure and have offsite secondary zones. The idea being to maintain high availability and performance where express route isn't an economical option (and support a "fog" model). AXFR would be minimum requirement. Just don't use any proprietary mechanisms for securing transfers.
We would require zone transfers into Azure DNS. Because of our environment and relationships with other entities, we require different views based on source. Today, this is all handled through a single user interface. While the benefits of moving DNS to Azure DNS (Or AWS Route 53) are intriguing, introducing the possibilities for user error and additional workload of managing DNS services in multiple user interfaces is preventing us from utilizing either. Since we're an Office365 customer already, Azure DNS would be the preferred service.
AXFR would be a minimum needed, but IXFR would be a nice.
TSIG would be my preference. IP ACLs would be sufficient for our uses, though.
We need it too!
If there is any problem (for example we forgot to pay the bills and you disable the service) we can have an updated DNS in ither place
I would also +1 this as an urgent requirement
- I require both in and out, IN to facilitate taking my current estate into Azure and OUT so I can improve reliability, security, resiliency by running something like dynDNS as a secondary service. I would probably look to make Azure a hidden master. It would be the killer feature to make me choose Azure DNS over AWS R53, which would seriously influence cloud strategy for organisation.
- Ideally both AXFR and IXFR
- to my mind security should be similar to AD - AD Integrated model? Lock by IP as option also.
I'm setting up a server/azure structure for my school project and came here looking for answers... Very surprised this isn't even an option yet. Explains a lot.