"host doesn't exist" whn using astaro as dns proxy

is there really no one who has a clue??

the problem basically comes down to this:

when asking astaro about an internal address, it says: "authorative answer: host does not exist" (see post above)

but when asking an external dns server directly it gives the right information.

In other words: the dns entries are RIGHT, astaro just does not forward or resolve any addresses from the internal range.

What's wrong here?? (internal range are REAL ip's, btw)

I don't perhaps couldn't follow all details here, but it seems to me that ASL doesn't forward DNS queries for addresses that are it's local subnets . So it thinks it is authority, but doesn't have that address.

What do you have as forwarders?

OK: You are asking DNS to do reverse lookups on private network numbers (a collection of numbers recognized by Internet edict as non-routable: 192.*..., 172.*..., 10.*...).

You don't 'own' private network numbers; you only use them in the privacy of your LAN (or network home, as it were). When private numbers leave your LAN, ISPs will (should??) not route them. Entering them in DNS is illegal (10 years in Folsom; other DNS servers in the DNS hierarchy will probably not, or at least should not, propagate them). So a reverse lookup will not happen for them.

You can make DNAT entries for external IPs you 'own' (your ISP will say what's yours, either statically or temporarily through DHCP or PPOE).

In the case of static IPs you have defined DNATs for, you can then subsequently define DNS entries in your DNS (maybe yours is maintained by your ISP?). Whoever makes these entries has to take care to also make corresponding reverse lookup entries (this is sometimes mistakenly overlooked).

If your Astaro is temporarily assigned its external IPs by an ISP (by DHCP or PPoE), then you will have to use Dynamic DNS; the Dynamic DNS provider needs to take care that these reverse-lookup entries are also temporarily created.

Another option is to use real IPs behind Astaro. Some people use the real IPs from a DMZ; others use multi-homing on a LAN if you also need to use private numbers. If the private numbers don't need to use Astaro/the Internet, you could dispense with concerning Astaro about private numbering schemes.

So if your ISP says you also own 137.120.1.127, and there is a DNAT rule mapping that address to 192.168.whatver else, you can now call up your ISP and tell them to add a DNS entry for that address (picking a name like mail.unimaas.nl, for your mail server, for example). Now when you enter 137.120.1.127, you will see (after propagagation of DNS record info!!) your name resolved. As far as getting the 192 DNAT mapping info, ain't going to happen -unless you are running a renegade DNS server on the Internet. And even then, it will be the only one saying that, since most other DNS servers will not propagate info for entities purporting to own private numbers...

P.S. I think we have a clue...

P.P.S. Hey Mike; I replied to your post when I should have to his; my misstep. It often happens, you know -you just reply to the last post because it's the last thing in the list...

SecApp, that's okay [:)]

But, I think that mourik_jan has the public ip's in his internal net, thus some part of the 137.120.1.x network. Now I haven't tried public nets with Astaro, but at least it makes private nets into /var/sec/chroot-bind/zones

There I have 192.168.1.zone for example. Now, it clearly doesn't forward queries at least for the private net's. And don't know if it does for public net's if they exist in the zones.

My INTERNAL addresses are NOT private. They are normal ("real", as i called them in mytwo posts) addresses.

Could that be the issue? that astaro always expects the internal ip's to be private..? How to change this behaviour..?

I'm very happy to finally get some replies to my posting.. [:)]

thanks!

ow, magicmike, you wanted to know what i have as forwarders:

four ip's:
192.87.106.106
137.120.1.5
137.120.1.1
192.87.36.36

tried with sam spade, and oll of these servers (at least last time i tried) are fully functional. (AND succussfully resolve our internal addresses to dns names)

Maybe -maybe- the DNS proxy is not adhering to the particulars of RFC, and it is seeing your 192 as private, and thus not forwarding the request.

SecApp, it's just that every interface with DNS proxy enabled will be written into ASL DNS proxy zones. Therefor, it will resolve reverse queries for all those networks. The matter was fixed with certain "under the hood" tweak [:)]

What matter was fixed under the hood? Sorry, not following that...

You mean to say it should be resolving it?
I know; I'm saying it (the "under the hood" components) is not because it might be seeing the address as private and dropping it.

Sorry, I meant ASL thinks it is authoritative for all those net's with DNS proxy "listening". So the reverse query doesn't get forwarded. The fix was to edit named.conf-default from the command line.

Sorry! I see what you're saying now.
(That's why I used those italicized maybes!)

That's probably it...

And here's the post: BIND edit for local DNS

The ASL generates zones for local interfaces. This leads to a non-working reverse. Strange enough, this is in since Version 2, but you seem to be the first who needs that functionality ;-)
If those zone definitions do not exist. the firewall asks for the IP address in the internet, creating possibly unwanted traffic for most of the customers; I think that might be the reason why this was implemented.

The solution for your problem is to remove the line containing  [] from /var/chroot-bind/etc/named.conf-default and disabling/enabling the DNS proxy.

I entered this in our bug database and we will discuss internally if this "feature" should be removed.

The ASL generates zones for local interfaces. This leads to a non-working reverse. Strange enough, this is in since Version 2, but you seem to be the first who needs that functionality ;-)
If those zone definitions do not exist. the firewall asks for the IP address in the internet, creating possibly unwanted traffic for most of the customers; I think that might be the reason why this was implemented.

The solution for your problem is to remove the line containing  [] from /var/chroot-bind/etc/named.conf-default and disabling/enabling the DNS proxy.

I entered this in our bug database and we will discuss internally if this "feature" should be removed.

[ QUOTE ]
, this is in since Version 2, but you seem to be the first who needs that functionality ;-) 

[/ QUOTE ]
Not really  

Greetings
cyclops

I've been having this problem for years in 3.x!
Now I know how to fix it.

Thanks,
Barry

I think it should be an option in the proxy config.

I agree with you -- you don't want private IP's trying to resolve on the internet.

On the other hand, you want your real IPs to resolve.

I'd been wondering why none of my log analyzers have been able to resolve our own IPs, but other IPs resolve fine.

Thanks,
Barry

Interesting problem. I was not aware there was an issue with getting the ASL DNS proxy to resolve local addresses.

In my home LAN, I have a file server on the local LAN, which runs DNS and DHCP server for the LAN. All DNS requests go to it, which means that all my local fakenet DNS names get properly resolved. For external DNS lookups, my DNS server calls the ASL DNS proxy, which calls my ISPs DNS servers. It is a simple setup, and it resolves everything. No reconfiguration of the ASL DNS proxy was ever required.

That's how I have mine setup and it works great. It would be a nice option however to be able to set up a 2ndary zone for the internal network. This way you could have ASL be a 2ndary DNS server for internal clients and still be able to resolve both internal and internet address. As it stands now if you point your internal clients to ASL and Not your internal server you lose internal reolution. I would bet this coule be done with the exsisting BIND loaded on the ASL it would just be a mater of adding the configuration option in the DNS proxie pages.

Its worse than that... we have real DNS setup on an External server at our ISP, but ASL won't resolve the addresses... it seems to throw requests for INT DNS to /dev/null or something.

Barry

[ QUOTE ]
As it stands now if you point your internal clients to ASL and Not your internal server you lose internal reolution.

[/ QUOTE ]That is why my local file server also runs the DHCP server for the local LAN. The DHCP server in the ASL box is only used for the DMZ network. That way no PC connected on the Internal network will get the ASL DNS proxy as their DNS server, they get the file server's IP address as their DNS server address instead.

My home LAN infrastructure depends on having two PCs being operational 24x7. They are the ASL firewall machine, and the file server located on the Internal network, which has the DNS and the DHCP services running on it. These two PCs, along with a D-Link ADSL modem, a Wi-Fi access point and a 24-port 3Com SuperStack II 3300 switch, all run off of a large APC Smart-UPS 1400, which will keep all my infrastructure gear online for up to 35 min during a power failure.

It is a compact and reliable setup hidden in a basement closet, and it feeds my two story home, which I wired 7 years ago with Cat5e and 100BaseTX RJ-45 jacks throughout. I simply wanted a no-brainer Ethernet environment in my home where everything just works, including local DNS resolution on my fake domain 192.168 series subnet.

I do network support for a living, so when I get home, I just want to relax, with a local Internet connected network that is safe, secure, readily available and always on, without requiring much in the way of support by me.