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

by the way: it works both ways when using an internet service such as http://www.webyield.net/domainquery.html to test these addresses.

meaning, from "internet's point of view" everything is fine, i guess.

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.