Dns doctoring/dnsmasq -V on bind?

[Kevin Darcy]

On 1/16/2011 7:23 PM, someone wrote:
> Hi,
>
> After googeling a lot I kinda gave up and ended here.
>
> Im running a bind server, where we have out .loc zone on and also use it for
> caching.
> We have our domains hosted @ our ISP's DNS-Servers.
> Now recently management decided to migrate from cisco to
> linux-routers/firewalls.
> Now as you might know, there is a dns-doctoring feature on cisco devices,
> that will rewrite ip addresses in dns-query-responses.
>
> I found a nice non-cisco explanation by someone who had my problem some
> years ago:
>
>> My dns server sits outside my firewall on the internet and answers queries
> for both my internal network and the world. Of course it only contains real
> world ips.
>> The pix has an option (called alias) that doctors dns request from my
> internal lan so that the reply packet contains the internal ip address
> instead of the public address given out by my dns server.
>> This lets the internal machines access internal hosts via dns without
> having to run two dns servers.  For example with following command:
>> alias (inside) 192.168.0.5 245.243.3.5 255.255.255.255
>>
>> all dns queries passing through the pix containing the address 245.243.3.5
> are re-written to contain 192.168.0.5.
>
> He obviously didnt get an answer from the netfilter dudes...
>
> Well dnsMasq seems to have the -V option which seems to work like dns
> doctoring on cisco devices.
> Im curious if there is an equivalent function on bind servers.
> I do not want to have dhcpd + bind + dnsmasq on one machine and use some
> hacks (loopback interfaces + iptables redirects) to achieve dnsdoctoring
> with dnsmasq - if possible.
> Also creating zones for all domains and subdomains that are hosted on the
> remote nameservers is not an option either.
Don't you know what names are being used to access these internal 
resources? If not, why not?

Seems to me you have, at its heart, an administrative problem here -- 
seems your "content" people are going out and registering domains to 
point to their content without your knowledge or consent -- and you've 
been covering up the fundamental problem by mangling DNS packets in a 
way that's confusing to troubleshoot and prevents you from ever 
implementing DNSSEC or other authentication technologies. Your 
packet-mangling approach isn't really forward-looking, or consistent 
with best DNS practices; it appears to be an attempt to perpetuate an 
old hack that was proprietary to one particular vendor (Cisco).

Why not fix the problem in the most straightforward, scalable and 
vendor-independent way? Run "internal" versions of the zones that are, 
in fact, used to access internal resources. The BIND "view" feature 
should allow you to implement this without running more boxes, network 
interfaces or even nameserver instances than you are today, although 
admittedly it does add a certain amount of additional complexity to your 
config.

                                                                         
                                                                 - Kevin