"forward after" option

Kevin Darcy kcd at chrysler.com
Thu Nov 11 00:00:34 UTC 2010

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 

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 

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 
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
>                 stephanass at ctbc.com.br
>                 Brazil
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20101110/ff00db07/attachment.html>

More information about the bind-users mailing list