What you're suggesting is not really the "inverse" of "forward first".
"Forward first" is basically: (try forwarding) -> [TIMEOUT FROM ALL
FORWARDERS] -> (try iterative resolution)
The inverse would be: (try iterative resolution) -> [TIMEOUT FROM ALL
AUTHORITATIVE NAMESERVERS] -> (try forwarding)
But you're not talking about timeouts, right? You're talking about
perfectly-valid responses that you don't like. This is "not found"
forwarding and in all the years people have been asking for it, it has
not been implemented in BIND because (at a minimum) a) there are
ambiguities with respect to what constitutes "not found" (NXDOMAIN only?
NODATA? REFUSED? SERVFAIL? DNSSEC validation failure?), and b) it
complicates and confuses resolution, and maintenance/troubleshooting of
same.
In your case, what you might end up having to do is either
a) start duplicating all of your external records in the internal
version(s) of your zone(s), and have your business partner use that, or
b) have your business partner look generally at the external version(s)
of your zone(s), and then have them create a zone, with just a single
leaf-node entry in it, for each name that they need to access, which
does not exist in the external version of the zone, e.g.
"foo.bar.example.com". This could potentially add up to a lot of zone
definitions.
c) the inverse of the above: have your business partner look generally
at the internal version(s) of your zone(s), and then create individual
zones for each external name that they need to access.
Note that for browser-based traffic *only*, a slightly-less ugly
solution than (b) or (c) above is for your business partner to use a
proxy auto-config (PAC) file with their clients (or modify their
existing PAC). Then you can selectively control whether the client looks
up the DNS itself (DIRECT), or uses a particular proxy, and then
co-ordinate that with whether the clients or the proxy/proxies see the
internal or external version(s) of the zone(s), respectively.
E.g. internal sites go DIRECT and clients resolve the internal version
of the zone, while external sites are proxied and the proxy sees the
external version of the zone, or
external sites go DIRECT and clients resolve the external
version of the zone, while internal sites are proxied and the proxy sees
the internal version of the zone, or
internal sites go to proxyA and proxyA resolves the internal
DNS, external sites go to proxyB and proxyB resolves the external DNS
- Kevin
P.S. If your internal and external DNS are completely distinct from each
other, how do your own internal users get to your own external websites?
If you're already solved that problem for your own clients, why not just
use the same solution with your business partner, if possible?
On 11/10/2010 3:08 PM, Stéphanas Schaden wrote:
Hi all,
we have a situation on our company today that is: We have a external
authoritative zone in our public DNS.
Have have a partner company that connect to our
network and need to use a internal IP address of our company but using
the internal link and the name of the FQDN of this access is
configured on our external zone.
We were looking about the forward configuration on
BIND and we found that there is the "forward only" and "forward first"
option. If our partner configure our external zone on their DNS and
configured just this specific entry on the zone and configure the
forward of the zone to our public DNS will not work because our public
DNS have this entry and this entry is appointing to the public IP. So
the entry on our customer DNS will be used just after it query our
public DNS.
So we were looking for if there is a option on BIND
(we did not found anything yet) to do the inverse of the "forward
first". Something link "forward after". So, if our customer DNS
receive a query and it have that entry on the zone it will answer to
the source. If it did not find this entry in the zone it will do the
forward process to our public DNS.
There is something that could do this using BIND ?
Thank you very much.
Stéphanas Schaden
stephan...@ctbc.com.br
Brazil
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
