On 5/28/19 10:16 AM, David Bank wrote:
I want to configure zurg so that it will refer ALL requests to buzz or woody; however, when a request is made to resolve andy.internal.local or sid.internal.local, then zurg rewrites those IPs from the 10. addresses that buzz and woody know about to 192.168. addresses that only zurg knows. andy and sid also have addresses in both networks.
Okay.I'm not convinced that you need RPZ to do what I think you want to do. But I'm not convinced that I fully understand what you want to do, much less why you want to do it. (More below.)
Reverse lookups shouldn't be an issue - hosts won't live in this bubble long enough to care
I think reverse lookups may be a relatively simple after the fact, if you care to do them.
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?
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?
I'm wondering if it might be possible to use a simple flat DNS zones with sorting of replies.
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.
When zurg takes a request from a host in the 192.168. network to resolve anything EXCEPT andy or sid, then the request is processed normally, and zurg returns whatever reply was given by buzz or woodyIs such a configuration possible, and how do I do it?
I'm still not convinced that I understand what you're wanting to do, much less why you want to do it. As such, this response may be completely wrong for you.
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.
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.
Based on my limited understanding of your needs, I think such sorting of replies might solve your problem. But my understanding is incomplete and there may be other requirements that I'm not aware of.
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.)
BTW, right now, zurg is up and running - I understand his configuration will have to radically change. Currently, he considers himself as authoritative for internal.local, but he only knows of 2 hosts (andy and sid); he does not forward and does not contain the full Zone information for internal.local
I don't see any reason to make zurg have a completely independent zone with a conflicting name. I don't see any reason why zurg can't have a slave copy of the real zone(s).
Please let me know if additional information is needed.
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.
#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.)
Please ponder this and help me understand why having a single common zone across buzz, woody, and zurg using response sorting wouldn't work.
Please help me understand why any assumptions I've made are incorrect.Once we know which direction we're going, then we can get into syntax. (Read: I don't have time to look up syntax /now/ and am using this as an excuse to do so later. ;-)
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
