forward problem

Kevin Darcy kcd at chrysler.com
Mon Oct 27 23:00:58 UTC 2008


Trixter aka Bret McDanel wrote:
> I have been asked basically to provide a "sitefinder" like service for
> some people so they have something other than the default browser 404
> page.  I am fully aware of the problems this can cause, however in this
> limited environment it wont be a problem, but I am finding that the
> forward options do not appear to be working as advertised (at least what
> I have read).  As such I would request that the discussions related to
> the political side of this issue be ignored for this thread, I know its
> a charged issue, but I also dont operate a root server, or really
> anything outside of a small office of people who wanted this, as I am
> the "goto volunteer" the task fell to me.
>
> I have tried both forwarding to my local bind via a different view, as
> well as to a 3rd party DNS server (ISPs) and neither appear to be
> working.  I have tried placing the forward/forwarders options both in
> the main options{} section as well as in the view that really needs it,
> both failed.  
>
> When I use the localhost view it works as one would expect, 
And what would one expect, exactly? It should work like a normal 
iterative resolver, the same as if the "internal" view, or the wildcard, 
didn't exist at all.
> when I use
> the internal view I get only the wildcard data.  I verified with tcpdump
> and setting to the ISP NS that it does not send any packets out to
> 'forward' the request.
>
> So my question is why does "forward first" not forward first then check
> the root zone, why does it go directly to the root zone and not even
> attempt to forward first?  Its either a broken (as I understand it)
> feature or my config is bad.
>   
"Forward first" just means that if the forwarding doesn't work, then 
iterative resolution is performed.

It does *not* mean "forward even for a name in your authoritative 
zones". The authoritative/non-authoritative distinction is made before 
forwarding is even considered. Your "internal" zone is essentially 
authoritative for *everything*, so it never forwards. Working as designed.
> Or is there some other way to basically remap a NXDOMAIN to something
> else short of either a proxy, code hack, or something else that I would
> prefer to avoid if it can be done via the configs.
>   
It would require a code hack, and since it's an unethical thing to do, 
good luck finding an experienced BIND hacker who would be willing to do 
it...

Probably your best bet is to have all your clients blindly forward their 
HTTP/HTTPS requests to a proxy and have the proxy do the evil deed.

                                                                         
               - Kevin

> Here is what I am doing (which doesnt forward):
>
> options {
>         forward first;
>         forwarders { 127.0.0.1; }; // also tried the ISP NS
>         // I also tried putting these in the view and the zone
>         // and neither had the desired effect      
> };
>
> acl "internal" { 192.168.0.0/16; 10.0.0.0/8; 172.16.0.0/20; };
> view "internal" {
> 	match-clients { "internal"; };
> 	recursion yes; // out of desperation
> 	zone "." { type master; file "wildcard";   };
> }
>
> view "localhost" {
> 	match-clients { localhost; }
> 	forwarders {};
> 	zone "." {type hint; file "db.root"; };
> }
>
>   



More information about the bind-users mailing list