Reverse Policy Zone to make MS Azure stuff work?

[John Thurston]

Due to a requirement to use something Microsoft crafted, we are being 
asked to assert (internally) authority over 3rd-level names under 
appserviceenvironment.net

I've pushed back on this, because I don't think it's nice to publish 
"authoritative" answers in domains we have not been delegated. But I'm 
told it's all ok, because Microsoft says its ok* Having accepted that 
the ship has sailed, it's now a question of how to deliver such answers.

One obvious way is to define a zone for each 3rd level under 
appserviceenvironment.net, and publish them in a way our resolvers can 
find them. In the absence of catalog-zones, this could be a lot of 
additional work (for me).

Then I wondered if adding these 'hijacked' names to our RPZ would meet 
the need. I first thought, "Yeah. It'll work.", but then I re-read the 
statement from MS saying each 3rd level was going to need to have a 4th 
level zone defined. A zone definition requires at least an SOA and NS 
record  . . and last time I checked, an RPZ would not deliver an NS 
record. So it seems that idea may be squashed.

Who else has need to publish locally-defined appserviceenvironment.net 
names? Were you able to do it with your RPZ?

* 
https://learn.microsoft.com/en-us/azure/app-service/environment/create-ilb-ase


-- 
--
Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230413/dac255d6/attachment.htm>