<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 16/05/22 20:05, Angus Clarke wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DB9PR02MB6524E39A479936A0B7BF3BACB5CF9@DB9PR02MB6524.eurprd02.prod.outlook.com">
<div style="font-family: Arial, Helvetica, sans-serif; font-size:
12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255,
255);" class="elementToProof">
As mentioned in a separate reply to Grant, the goal is to have
(amongst other things) local recursors "find" the locally
deployed authoritative servers through NS records. What hasn't
been mentioned is that I am also looking to simplify
configuration management by means of a single set of data which
can be deployed to all authoritative servers - I don't think the
RPZ solution proposed by Nick achieves that.</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size:
12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255,
255);" class="elementToProof">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size:
12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255,
255);" class="elementToProof">
That being said, can RPZ-CLIENT-IP be a subnet? I don't think it
can.</div>
</blockquote>
<p>Hi Angus.</p>
<p>Thanks for clarifying. Based on what you've said, what I proposed
probably has slightly more merit than I concluded, although
admittedly it doesn't quite tick all the boxes...</p>
<p>Firstly, yes RPZ-CLIENT-IP can be a subnet. IPv4 addresses are
represented as prefixlength.B4.B3.B2.B1.rpz-client-ip. In my
examples I was specifying a single host which is why the
RPZ-CLIENT-IP records all started with 32.</p>
<p>Secondly, RPZs are more commonly used on recursive resolvers
rather than the authoritative nameservers for the zone, although
in your case if you are wanting to change the answer that an
authoritative nameserver gives to the NS question from the
recursive resolver, then it probably makes the most sense to put
the RPZ on the authoritative nameserver. In this case you'd also
need to specify "recursive-only no". (FYI Default behaviour is to
apply RPZ rewriting to queries with RD=1 and DO=0.)</p>
<p>However this still doesn't meet your requirement for "a single
set of data", unless you are only talking about zone data, and in
that case you could replicate all the RPZ zone files to all
authoritative nameservers, and then configure each server to
specify only one of these in its "response-policy" configuration?</p>
<p>But the anycast suggestion sounds like it has the most merit? Or
at least it sounds the coolest to me. :-)<br>
</p>
<p>Nick.<br>
</p>
<p>P.S. I don't think this will be useful to you, but FWIW... if
your goal is simply to have the recursive resolvers use a specific
subset of nameservers for specific zones, then there is yet
another option: static-stub zones. Static-stub zones allow you to
effectively override the authoritative nameserver that will be
used for a particular zone. So you could configure the static-stub
zone on the recursive resolver, and that would point to the local
authoritative nameserver(s). However the main drawback with
static-stub zones is that you need to create a static-stub zone
(on the local resolver) for every authoritative zone that you are
doing this with, so it probably isn't practical if you have many
zones or are adding or removing zones frequently?<br>
</p>
</body>
</html>