James Smith enscribed thusly:
> OK you got me, I wrote the original one, and I run an NT network with
> Service Pack 4.
> I have NO internal DNS - is that so strange for a small company with 50
> machines?
Yes... I take it you don't have any real domain for yourself,
where you would have to have a name server, but I've run DNS servers
for networks with a dozen or fewer systems. It's not difficult, especially
for small networks.
BTW... Point of clarification. Like it or not, you are running
DNS. You are not running a DNS server, but you are using the DNS resolver
facility (the client side of DNS).
> So my DNS is not leaking. I believe quite a few commercial packages -
> WinGate for one recommend you use 192.168.x.x. one 2 to 8+ machines with
> [obviously] no internal DNS.
Yes, your DNS (or lack there of) is leaking. Your DNS "queries"
are leaking out of your network and walking up the nameserver tree looking
for *.*.*.*.in-addr.arpa for the reverse lookup. Everytime one of your
systems tries to look up an address, that's what happens...
> Shouldn't NT query WINS first for a reverse lookup? That would solve a lot
> of problems wouldn't it? For us and IANA!
Snicker... Oh please... That's such a joke...
WINS is not DNS...
It may be named Windows Internet Name Service, but it is NOT DNS.
M$ has their own name server for DNS, you know.
M$ allows "."s in machine names but WINS doesn't understand the
Domain Naming System (M$ has it's own idea of what constitutes a "domain").
Ever wonder what in the #$@$#@ M$ does if you name a machine foo.net
(15 characters or less for this excerise, now) and then you have to
figure out "well, is this the windows machine "foo.net", which I know
about, or is this the domain name "foo.net", which I have to query the
network for. And don't get me started when you introduce "scope" into
the picture or the M$ idea of domains.
WINS is not DNS.
> >From RFC 1918:
> [Indirect references to such addresses should be contained within
> the enterprise. Prominent examples of such references are DNS Resource
> Records and other information referring to internal private addresses. In
> particular, Internet service providers should take measures to prevent such
> leakage. ]
>
> HOW? By stopping all reverse DNS lookups? Not practical is it?
>
> So rfc1918 should require you to have a DNS server? This makes it a lot more
> difficult for small companies to implement 1918 addresses, couldn't DNS
> servers just 'ignore' these. If I set up a machine with no DNS entries in
> TCP/IP and a fixed [1918] address ping -a resolves names just fine, from
> WINS I presume.
No it doesn't. DNS isn't that difficult to set up and if your
a Windows Weenie shop, its a snap to get DNS and WINS talking together.
You tell the DNS server what zone's you have and you tell it they are
managed by WINS and where the WINS service is. You're done.
> I guess it would do the same if it received no response from DNS (like it
> always did?).
> Or would the best fix for all be:
> TCP/IP (in MS NT Environment at least) should be patched to
> query WINS first, if available, then,
> IF no response is received from WINS
> IF and only if the address in NOT rfc1918
> query DNS,
> (could it query the responder of a ping? I.e. the addressee?, the host?)
> ELSE trash the query
Best answer is that you set up your DNS server on your WINS server
and tell the two to talk to each other. That's how it's suppose to be
set up. It takes a little bit of time to set up DNS (but if it takes more
that a half an hour then M$ has really screwed it up beyond all belief -
bind on Unix can be set up for small domains in that length of time) but
if you have it tied to WINS you don't ever have to touch it again.
> That is all, Thanks
> James Smith
[...]
> -----------------------------------------------------------------------
> This message is not an official statement of COSPO policies.
Mike
--
Michael H. Warfield | (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
