name server "discovery" ?

Re: name server "discovery" ?

From:

Date:

Time:

At 9:42 AM -0400 6/5/01, Joseph D'Andrea wrote:
>I have a co-lo client in our facility and his box is running
>windows2000. That's his first problem. ;-) He claims that he
>doesn't have to provide any name servers in his TCP/IP set-up
>because when there are no name servers specified, windows2000 will
>"discover" the "closest" name servers and use them. I know he's full
>of it because he is also convinced that _every_ name server on the
>entire internet gets a "root update" at 5am and 5pm every day.
>
>How does this relate to QDNS... well he's saying that since I'm his
>ISP and since he can't resolve certain DNS names and numbers then my
>name server (QDNS) must be wrong. Is there such a thing as name
>server discovery?

It's technically feasible to discover services on the local network,
by either sending a broadcast packet (not sure if this will work) or
attempting to connect to every possible address on any and all local
subnets. Timbuktu does something like this, for example, with its TCP
scanner.

However, since it isn't working for him, most likely one of the
following has occurred:

- Your QuickDNS servers aren't on the same subnet as his server, or

- discovery is working fine, but the "certain DNS names and numbers"
that his server can't find have screwed up delegations or other
problems outside your control, or

- the discovery uses some port other than 53, or otherwise is only
supported by Microsoft DNS (and thus the customer should be soundly
beaten for assuming anything Microsoft does is automatically
"standard"), or

- the customer is simply full of it.

Rather than presenting these possible explanations to your customer,
which would be highly impolitic, I suggest presenting the customer
with this (hopefully unlikely) scenario:

Suppose each of the following:
- This discovery method really works.
- An attacker somehow gains access to your network.
- The attacker proceeds to set up a malicious DNS server on your
network, such that his server for some reason uses the malicious
server in favor of your normal servers.

Now suppose his web server tries to connect to a backside cc
authorization service, but is redirected by the attacker's malicious
resolver to somewhere else. Suddenly your customer is liable for lots
of stolen credit cards, all because he couldn't be bothered to
hard-code in the addresses of your servers.
____________________________________________________________________
Chris Buxton Men & Mice
cbuxton@menandmice.com We Make DNS Easy!

Sales:
888/4-DPOINT

Support:
858/452-3696