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.thurs...@alaska.gov
Department of Administration
State of Alaska
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
