problem with qdns and secondary ip address

Re: problem with qdns and secondary ip address

From:

Date:

Time:

At 8:24 PM +0200 6/8/00, Matthias Gruber wrote:
>Hello,
>
>thanks for the fast answer.
>
>
>>>it has turned out now, that whenever a secondary ip address, or more
>>>than one, are in use on the qdns servers some clients especially dig
>>>will fail. this happens even when the qdns server is bound to the
>>>primary ip address (as enterd in the tcp/ip control panel). if there
>>>is only the primary address, qdns connectivity worked.
>>
>>This is the first we've heard of problems with connecting to
>>QuickDNS on the primary address. What versions of Mac OS and Open
>>Transport are you using?
>>
>
>We are using a beige G3 Server with MacOS 9.0.4 int. english
>version. Open Transport is 2.6.1. this server is a public internet
>server, you can reach it: dns2.wolnet.de 194.162.66.6. it was ment
>to become our public primary, but is now secondary.
>
>i tested it: secondary ip address in use - dig does not work. only
>one ip address (the configuration now in use)- dig works.
>
>i have tested it on several machines all with macos 9.0.x.

OK, here's the scoop as near as I can figure it - some facts followed
by some informed speculation:

1. QuickDNS uses the MacTCP compatibility interface.

2. In older versions of Mac OS (8.0 to about 8.5.1 or 8.6), this
meant that QuickDNS had access to the primary IP address and no other.

3. In Mac OS 9 (and some versions of 8.6), this changed: QuickDNS now
effectively listens on all IP addresses. However, it still only
replies from one IP address - this one address is used as the source
address of all outgoing packets sent by QuickDNS. At least, that's
been the experience so far.

4. Some query tools, such as DNS Expert and nslookup, don't care
where the reply comes from, so long as it comes to the correct port.
This potentially opens the way for someone to feed you false
information, but it would be extremely tricky to exploit. Whoever
wrote Dig was paranoid - it checks the source address.

5. Many NAT servers also check source IP addresses, so this can play
havoc with resolvers behind NAT servers as well, since they never get
the reply if the reply is sent from a different address than the one
to which the query was sent. In fact, this is a known problem: Some
organizations run their DNS servers behind proxy servers, and the
response doesn't always come from the correct address. The problem is
so prevalent that Microsoft wrote a knowledge base article on the
subject.

And now for the speculation:

6. It may be that, if you give a machine multiple IP addresses taken
from different subnets, Open Transport may try to send these packets
from the interface it considers "closest" to the destination. This is
in keeping with what I know of the Mentat Streams library.

So the solution may be to simply figure out which address OT
considers closest to your domain registrar, and use that as your DNS
server's IP address.

Part of what gave me this idea was my own testing: I set up my
workstation to have multiple IP addresses. I then started a local
copy of QuickDNS Pro Server, with the logging level set to Debug. I
then started a copy of DNS Expert and queried my local copy of
QuickDNS, using the second IP address. The QuickDNS log stated that
the request was *received* from the secondary IP address. When I
queried the primary address, the log window said the request was
received from the primary address.

Now DNS Expert is OT native, unlike QuickDNS Pro, but it doesn't know
anything about multiple IP addresses on the client end. Which means
that OT was picking the interface from which to send the request
based on the destination.

BTW: If anyone's concerned about the speed hit taken by QuickDNS for
running on the MacTCP emulation layer, consider that it's still quite
fast. And consider also that version 3 will be fully OT native. ;-)
____________________________________________________________________
Chris Buxton cbuxton@menandmice.com
Men & Mice http://www.menandmice.com
Makers of: QuickDNS Pro

Sales:
888/4-DPOINT

Support:
858/452-3696