Re: Reverse Policy Zone to make MS Azure stuff work?
Another thing I forgot to mention, is the need to express these parameters in
the options clause in named.conf:
options {
// RPZ zone
// Source: https://deteque.com/m3aawg-bind-training/named.conf
response-policy {
zone "rpz.local";
};
};
My apologies for not double-checking earlier, but I think this should be
everything.
--
Met vriendelijke groet / Best regards,
Michael De Roover
signature.asc
Description: This is a digitally signed message part.
--
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
Re: Reverse Policy Zone to make MS Azure stuff work?
Create a catalog zone and use that to distribute the zone configuration to all your recursive servers. As for using a zone that is not delegated to you. Microsoft own appserviceenvironment.net and are telling you to use it this way. This is no different to the IETF saying you can have your own 10.in-addra.arpa for RFC 1918 addresses. Mark > On 14 Apr 2023, at 08:28, John Thurston wrote: > > Due to a requirement to use something Microsoft crafted, we are being asked > to assert (internally) authority over 3rd-level names under ç > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- 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
Re: Reverse Policy Zone to make MS Azure stuff work?
On Friday, 14 April 2023 00:28:24 CEST John Thurston wrote:
> 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-a
> se
Hello John,
For what it's worth, I've been working on Microsoft related domains in an RPZ
recently as
well. The way I've done this is by defining a zone "rpz.local" in my
named.conf, as shown
below.
// Response Policy Zone
zone "rpz.local" {
type master;
file "/etc/bind/zones/rpz.local.db";
allow-update { none; };
allow-transfer { internal; };
allow-query { localhost; };
};
Then I define in this rpz.local.db file, entries like the ones below.
$TTL 300
@ IN SOA localhost. need.to.know.only. (
202303131 ; Serial number
60 ; Refresh every minute
60 ; Retry every minute
43200 ; Expire in 5 days
60 ); Negative cache TTL 1 minute
IN NS LOCALHOST.
; Examples
block.example.com IN CNAME .
passthrough.example.com IN CNAME rpz-passthru.
redirect.example.comIN CNAME example.com.
Pay special attention to the lack of a final dot in the records themselves,
this is important.
As far as I understand, this makes them relative to your rpz.local zone, not
the actual
domain on the internet. The only major issue I've been facing with this so far,
is that AXFR
to secondary and tertiary name servers has some issues, and at least Windows 10
Home
will query those when the primary name server does not give a satisfactory
answer.
--
Met vriendelijke groet / Best regards,
Michael De Roover
--
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
Reverse Policy Zone to make MS Azure stuff work?
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 Thurston907-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
