DNS BIND9: Restrict certain entries from being transfered
 

Hi there!

We set up a proxy server in our company and wanted to use the browser's feature to automatically detect browser settings. It took us some time to get it to work, and now we are stuck with a small inconvenience:

For the automatic detection to work you will have to be able to resolve wpad.yourdomain.com, which resolves to a webserver that then serves the config file. So far so good. Out Webserver serving this file has a private IP address, 10.0.0.2. This is the only entry in our DNS zone using a private IP.

The Problem is: With every DNS update, our wpad entry gets transfered like every other domain and thus can be resolved with every other DNS - and of course it resolves to 10.0.0.2. It would not be that much of a problem that the domainname can be resolved, because the private IP is useless anyway, but it does look a bit unprofessional (at least I think it does) to transfer useless entries.

So the simple question is: Is there a way to hinder our DNS to transfer this entry? The DNS is not reachable from the outside, but has a public reachable DNS slave. If the slave is still serving our private IP that would be ok. But we do not want to "flood" other's DNS with our (for them) useless entries.

And if there is a simple way, how could that be accomplished? I suppose noone will ever notice this single entry so if a working solution would require rebuilding our architecture I guess we could live with the fact that we are responsible for one useless DNS entry.

Thank you in advance,
Klaus.

Hmm...well, it might be possible to do this using the 'views' function in BIND9.

It allowd you to set up differnet DNS records to be served to different addresses that are making the request. So you could serve the view that contains the internal address to internal clients only, and then the DNS records without the internal address to external clients.

It gets pretty involved though! Especially when you bring slave name servers into the equation.

It would require a new )or revised) named.conf and it would also require new zone files.

Cheers,

Steve

Hi!

Thanks for your reply! I read about that kind of solution here somewhere on the forums before and I thought maybe there is a simpler way. But thanks anyway at least I now know that I didn't miss a simpler solution.