<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFCC">
To me this looks like it could be done with a bit of programming.<br>
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.<br>
<br>
This is a different look at the task, if not relevant, just ignore.<br>
<br>
<div class="moz-cite-prefix">On 28/05/2019 19.13, David Bank wrote:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.LSU.2.21.1905281251471.124197@etdusnm0pws01.ebsad.local">On
Tue, 28 May 2019, Grant Taylor via bind-users wrote:
<br>
<br>
Hello, Grant! Thanks for replying.
<br>
<br>
<blockquote type="cite">On 5/28/19 10:16 AM, David Bank wrote:
<br>
<blockquote type="cite">To recap what I'm attempting to create:
a host in the 10. network knows
<br>
to ask buzz or woody for DNS resolution, and if such a host
wants to
<br>
resolve andy.internal.local, it gets (for example) 10.0.2.4
(moreover,
<br>
the host can't even reach the DNS server on zurg). This part
already
<br>
exists.
<br>
</blockquote>
<br>
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?
<br>
</blockquote>
<br>
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.
<br>
<br>
<blockquote type="cite">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?
<br>
</blockquote>
<br>
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.
<br>
<br>
<blockquote type="cite">I'm wondering if it might be possible to
use a simple flat DNS zones with sorting of replies.
<br>
</blockquote>
<br>
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).
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">However, a host in the 192.168. network
has been told to use zurg, and
<br>
if it asks to resolve andy.internal.local, I want it to get
192.168.8.9
<br>
(even though when zurg forwarded the request to buzz, the
response was
<br>
10.0.2.4)
<br>
</blockquote>
<br>
Sorting and apex overrides come to mind.
<br>
</blockquote>
<br>
I'm not familiar with those techniques, but I'm interested in
learning.
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.
<br>
<br>
<blockquote type="cite">This would mean that any host in the
192.168/16 bubble would get a
<br>
192.168/16 address listed first in the reply. Similarly, any
host in
<br>
the main 10/8 network would get a 10/8 address listed first.
<br>
</blockquote>
<br>
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").
<br>
<br>
<blockquote type="cite">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.)
<br>
</blockquote>
<br>
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.
<br>
<br>
<blockquote type="cite">About the only thing that I can see RPZ
being used for here would be to
<br>
override the information that zurg might return if the zone
didn't
<br>
already have the data (multiple A records) which could be
sorted. I see
<br>
two potential solutions for this:
<br>
<br>
1) Apex overrides
<br>
2) RPZ overrides
<br>
<br>
#1 is simply a new zone that is the FQDN of what you want to
override
<br>
and put an A record with the address you want in the apex.
<br>
</blockquote>
<br>
OK - I have no idea how to do it, but if that would work....
<br>
<br>
<blockquote type="cite">#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.)
<br>
</blockquote>
<br>
Yes, that's what I was thinking of originally.
<br>
<br>
<blockquote type="cite">Please ponder this and help me understand
why having a single common zone across buzz, woody, and zurg
using response sorting wouldn't work.
<br>
</blockquote>
<br>
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.
<br>
_______________________________________________
<br>
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to
unsubscribe from this list
<br>
<br>
bind-users mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a>
<br>
</blockquote>
<br>
</body>
</html>