[External] Re: Request assistance configuring RPZ

[Grant Taylor]

On 5/28/19 11:13 AM, David Bank wrote:
> Hello, Grant! Thanks for replying.

Hi.

You're welcome.

>      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.

Okay.

>     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.

Okay.

>     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 the moment, I'm thinking about having one zone, "internal.local", 
with almost all hosts having A records in the 10/8 IP space.  "andy" and 
"sid" would also have A records in the 192.168/16 IP space in addition 
to their A records in the 10/8 IP space.  (More details below.)

> at least not without supplying zurg with a flat file to reference 
> (which I don't want to do).

Please clarify, is it that you want to not have to maintain and update 
special zone file(s) for zurg?  Or do you want zurg to not have the rest 
of the zone contents that the main DNS servers have?

Asked another way:  Is it okay for zurg to have copies of the 
"internal.local" zone?  (Assuming that the necessary IP changes can be 
effected with easy.)

>     I'm not familiar with those techniques, but I'm interested in learning.

There may be a different name for what I call "apex override".  In 
short, you would create two additional zones on zurg; 
"andy.internal.local" and "sid.internal.local".  They would look 
something like the following:

@andy.internal.local.   SOA   ...
                          NS    zurg.internal.local.
                          A     192.168.123.234

@sid.internal.local.    SOA   ...
                          NS    zurg.internal.local.
                          A     192.168.234.123

This way, when clients query andy.internal.local or sid.internal.local, 
zurg will have a local authoritative zone that specifies alternate IPs 
in the 192.168/16 network.

Note:  There is some potential for (lack of) delegation issues.  This is 
because there's a very good chance that those names won't be delegated 
in the internal.local zone.  -  However, this can be worked around by 
doing delegation to service names.  -  The only time I've run into 
problems like this is if you run some sort of test to validate 
delegation.  All of the real world examples I've seen have worked okay.

Sorting, or "sortlist" in BIND / named parlance is a way to tell BIND / 
named to sort the response records being sent to clients such that they 
are (theoretically) in the best order for the client.

Link - DNS BIND9 Query Statements - sortlist
   - http://www.zytrax.com/books/dns/ch7/queries.html#sortlist

You would add sortlist something like the following:

options {
	...
	sortlist {
		{
			192.168/16;
			{
				192.168/16;
			};
		};
		{
			10/8;
			{
				10/8;
			};
		}
	}
	...
}

This tells BIND / named that when it replies to clients in the 
192.168/16 network, that any address in the 192.168/16 network should be 
listed first.  Similarly, clients in the 10/8 network should get IPs in 
the 10/8 network as the first IP.

So BIND / named will reply to clients with multiple IPs.  It will just 
order them in what it thinks (based on the configuration) is the best 
order for the client.

So, if you have two A records for andy and sid, one in each network 
(10/8 and 192.168/16), BIND / named will be able to use the zone as is 
without modification.

>     No, because I don't have a non-manual way to supply zurg with the 
> Zone data for *.internal.local.

Why do you have to do it manually?

Why can't you use standard zone transfer mechanisms?

> 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.

You don't need to do a zone dump.  (See above.)

I'm not convinced that you /need/ to alter the zone.  (See above.)

>     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").

Unfortunately, that doesn't indicate if anything about DNS needs to 
prevent hosts in 10/8 from talking to hosts in 192.168/16 by never 
resolving anything.  This is a key difference.

Is it okay for hosts in 10/8 to know that there are 192.168/16 IP 
addresses?  Even if they will never use them?  Or does there /need/ to 
be hard separation that prevents hosts in the 10/8 network from ever 
knowing about 192.168/16?

I'm assuming that buzz and woody would apply the same type of sorting 
(sortlist) technique to make sure they reply with the 10/8 IPs to clients.

>     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.

I'm not convinced that zurg actually needs to alter the zone. Especially 
if the zone already has the information that zurg needs and zurg just 
needs to sort (sortlist above).

> Athough, zurg is BIND on SLES; buzz and woody are Winblows DNS.

I thought MS-DNS supported sorting replies.  I'm not sure.

>     OK - I have no idea how to do it, but if that would work....

See above.

>     Yes, that's what I was thinking of originally.

ACK

>     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.

If you have no control (direct where you change or indirect where you 
ask someone else to change) over buzz or woody, and you can't ensure 
that it sorts properly, you will likely need apex overrides or RPZ.



-- 
Grant. . . .
unix || die


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190528/6395e1b7/attachment-0001.bin>