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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
