This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

dear readers,

using astaro as dns proxy for internal. have four external dns servers setup, astaro listens to [internal]. all seems to work, exept for internal addresses.

so: www.unimaas.nl resolves to 137.120.1.126, and this ip resolves to www.unimaas.nl. no problem.

however, with all our own addresses, it works one way: dnsname to ip works, but ip to dns name DOESN'T. error message: (from Sam Spade)


09/21/04 11:24:41 dig 192.87.143.5 @ 192.87.143.1
Dig 5.143.87.192.in-addr.arpa@192.87.143.1 ...
Authoritative Answer
Recursive queries supported by this server
Authoritative answer: Host doesn't exist
 Query for 5.143.87.192.in-addr.arpa type=255 class=1
  143.87.192.in-addr.arpa SOA (Zone of Authority)
        Primary NS: localhost
        Responsible person: firewall@fw-notify.net
        serial:1095756860
        refresh:10800s (3 hours)
        retry:900s (15 minutes)
        expire:604800s (7 days)
        minimum-ttl:86400s (24 hours)


remark: internel addresses are *real* ip's. the dns server containing our entries is not on our network, but hosted somewhere else.

what is going wrong here?


This thread was automatically locked due to age.
Parents
  • 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?
  • 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.
  • [ 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
Reply Children
No Data