[External] Re: Request assistance configuring RPZ

Tue May 28 18:10:28 UTC 2019

To me this looks like it could be done with a bit of programming.
If the addresses of the two hosts needed in 192.168.x.x don't change too
often, a cron job could read those addresses and set them in zurg as
dynamic entries using nsupdate. The time for cron would be smaller than
the TTL of the RRs in their original location.

This is a different look at the task, if not relevant, just ignore.

On 28/05/2019 19.13, David Bank wrote:
> On Tue, 28 May 2019, Grant Taylor via bind-users wrote:
>
> Hello, Grant! Thanks for replying.
>
>> On 5/28/19 10:16 AM, David Bank wrote:
>>> To recap what I'm attempting to create: a host in the 10. network knows
>>> to ask buzz or woody for DNS resolution, and if such a host wants to
>>> resolve andy.internal.local, it gets (for example) 10.0.2.4 (moreover,
>>> the host can't even reach the DNS server on zurg). This part already
>>> exists.
>>
>> Do you want hosts on the 10/8 network (thus not in the bubble) to be
>> able to reach any of the hosts in the bubble?
>
>     No - the bubble is its own world for the most part. No reason for
> general 10/8 inhabitants to try to talk to 192.168/16 - the very, very
> few hosts that need to talk in 192.168/16 already have an IP in there.
>
>> Or is this simply wanting to make sure that hosts (outside the
>> bubble) in 10/8 resolve to IPs in 10/8 and that hosts (inside the
>> bubble) in 192.168/16 resolve to IPs in 192.168/16?
>
>    Hosts in 192.168/16 need to resolve 2 SPECIFIC names to 192.168/16
> when those names would otherwise resolve to 10/8 addresses. All other
> name resolution whould be to 10/8.
>
>> I'm wondering if it might be possible to use a simple flat DNS zones
>> with sorting of replies.
>
>    Perhaps I'm missing something, but I don't see how to make zurg
> reply with 192.168/16 IPs for andy and sid, but correctly resolve the
> rest of *.internal.local - at least not without supplying zurg with a
> flat file to reference (which I don't want to do).
>
>>> However, a host in the 192.168. network has been told to use zurg, and
>>> if it asks to resolve andy.internal.local, I want it to get 192.168.8.9
>>> (even though when zurg forwarded the request to buzz, the response was
>>> 10.0.2.4)
>>
>> Sorting and apex overrides come to mind.
>
>    I'm not familiar with those techniques, but I'm interested in
> learning.
>
>> Can you have a single zone, internal.local that has records for all
>> the hosts, with andy.internal.local, sid.internal.local, and
>> zurg.internal.local having multiple A records, one in each network.
>> Then configure BIND to sort the replies based on the network the
>> client is coming from.
>
>    No, because I don't have a non-manual way to supply zurg with the
> Zone data for *.internal.local. And I'm not too keen on, say, having
> zurg do a routine Zone dump from, say. buzz, and scripting something
> on zurg to massage the information so the records for andy and sid
> return 192.168/16.
>
>> This would mean that any host in the 192.168/16 bubble would get a
>> 192.168/16 address listed first in the reply.  Similarly, any host in
>> the main 10/8 network would get a 10/8 address listed first.
>
>    Hosts in 10/8 don't talk to zurg (aside from the fact zurg will
> talk with buzz and woody) - hosts in 10/8 only talk to buzz and woody,
> and buzz and woody always resolve all queries to 10/8 (e.g. they
> always tell the "truth").
>
>> Also, is there any reason that zurg can't be a slave for the zones
>> that buzz and woody are authoritative for?  (Especially if sorting
>> addresses the issue.)
>
>    No, I don't think so - but I didn't see how that would help, since
> I want zurg to alter the replies for just 2 hosts in the Zone.
> Athough, zurg is BIND on SLES; buzz and woody are Winblows DNS.
>
>> About the only thing that I can see RPZ being used for here would be to
>> override the information that zurg might return if the zone didn't
>> already have the data (multiple A records) which could be sorted.  I see
>> two potential solutions for this:
>>
>> 1)  Apex overrides
>> 2)  RPZ overrides
>>
>> #1 is simply a new zone that is the FQDN of what you want to override
>> and put an A record with the address you want in the apex.
>
>    OK - I have no idea how to do it, but if that would work....
>
>> #2 is configuring RPZ to return different IP(s) (in the 192.168/16
>> bubble) for specific query names.  (This is what traditional RPZ /
>> DNS firewalls do.)
>
>    Yes, that's what I was thinking of originally.
>
>> Please ponder this and help me understand why having a single common
>> zone across buzz, woody, and zurg using response sorting wouldn't work.
>
>    Well, I have no control over buzz and woody. I can only control
> zurg. I'm not sure if Winblows can do response sorting, or if zurg
> would be able to impose a sort on the data after he does a Zone transfer.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190528/aa383f19/attachment.html>