>I'm not sure I understand you here. What's wrong with others using my DNS?
1) malicious "users" could DoS your DNS by sending 1000's queries/minute
with some kiddie script, queries from spoofed ip's (DNS queries are UDP and
therefore the source address is easily spoofable) for non/existant domains,
which your compliant DNS would try to resolve, building its cache up
until...., and probably exhausting the DNS resources for your valid users.
2) MS DNS's caches are poisonable out of the box. By allowing recursion,
you are allowing attackers the "triggered poisoning" attack: they query
your DNS to for a domain hosted by their cracked DNS that gives your DNS
bad records in the "additional section" of DNS response packet when your
DNS queries their. You can fix this by hacking your DNS registry entries
with articles on MS site.
3) btw, you also have "zone transfer" unrestricted. I just stole your zone
data for rentpro.com:
# dig @205.217.113.140 rentpro.com axfr
; <<>> DiG 8.3 <<>> @205.217.113.140 rentpro.com axfr
; (1 server found)
$ORIGIN rentpro.com.
@ 1H IN SOA ns2.primocomputers.com.
admin.primocomputers.com. (
13 ; serial
15M ; refresh
10M ; retry
1D ; expiry
1H ) ; minimum
1H IN A 205.217.113.227
1H IN NS ns2.primocomputers.com.
1H IN NS ns1.primocomputers.com.
1H IN MX 10 mail
lists 1H IN A 205.217.113.210
mail 1H IN A 205.217.113.140
ns1 1H IN A 205.217.113.10
ns2 1H IN A 205.217.113.11
www 1H IN A 205.217.113.227
@ 1H IN SOA ns2.primocomputers.com.
admin.primocomputers.com. (
13 ; serial
15M ; refresh
10M ; retry
1D ; expiry
1H ) ; minimum
;; Received 11 answers (11 records).
;; FROM: some.where to SERVER: 205.217.113.140
;; WHEN: Sun Aug 25 09:14:37 2002
You can restrict zone transfers with MS GUI. If you don't know anything
about DNS, at least read all the F1 help screens for all the MS DNS GUI panels.
4) btw, zone transfers are TCP sessions, so it's MUCH easier to exhaust
your DNS' resources with 1000's of zone transfers than it is with UDP queries.
>How would they be stealing from me? I thought the whole idea of a public
>DNS was to allow others to use it so that they can find out how to access my
>resources, such as my web sites and mail servers.
ah, but asking your DNS for YOUR domains is not recursive querying.
The problem is querying your DNS for 1000's of non-YOUR domains. So you
turn off recursion, and Internet can still query your DNS for your
domains. And then Internet cannot query your DNS for other domains.
Great. But then YOU can't use your non-recursive DNS for looking up any
domains not yours, either.
So you really need TWO MS DNS's (licenses for two W2K servers, are you
getting the picture? :)) ). One DNS is authoritative for your domains
with recursion (and zone transfer) off and accessible from Internet. The
other DNS has no domains, but has recursion on, aka "caching-only
nameserver". You will have to block access from Internet to your recursive
DNS at your firewall.
Here's a quote last week in the ISP-DNS list.
"
You may think that the w2k dns server and resolver work great, and they
may in fact provide adequate service to your customers, but I think the
root-servers.net operators and NSI/Verisign, in their capacity as
operators of gtld-servers.net, would have a diferent perspective. When
one operates services on the public internet, one needs to consider the
effect those services have on the internet at large, and this is where
Microsoft's DNS products fall down, hard. I'll grant that w2k dns server
is much improved over their previous offerings, but it is still, by
design and through poor site implementations, responsible for an
astonishing ammount of bad DNS traffic.
Take the way that MSDNS 'balances' queries to multiple authoritative
servers, for example. Simplifying the actual scenario a lot: BIND
servers keep a running tab on how fast each server for a zone is
reponding, and prefers over time the set of servers with the fastest
response times. That set is periodically recalibrated, to adjust for
various possible overload conditions. The algorithm used results in best
performance for users, since better-performing servers are preferred
over poor performing servers, and elegantly balances the load on
authoritative servers, since poor performing servers recieve fewer
queries. I'm told that dnscache does not perform such RTT metrics, but
does pick at random (and given DJB's undeniable skill at mathematics,
I'm quite confident that 'random' here actually *means* random ;) )
among servers in an NS RRSET. MSDNS, on the other hand, *always* sends
queries to the first server listed in the NS RRSET, and if those queries
time out, it resends them in parallel to all other servers in the NS
RRSET. The upshot here is that a.root-servers.net and a.gtld-servers.net
are forced to swallow a vastly disproportionate percentage of the DNS
queries for '.', edu, com, net, and org than they otherwise would, and that
the other root and gtld servers are forced to swallow needlessly
replicated parallel queries for the same RR. There's a graph out there
somewhere of the query load on A during the win2k rollout, and it's
frightening. I always thought NSI should have billed Microsoft for the
cost of upgrading A ;)
Then there's the issue of negative caching. MSDNS still, as far as I
know, performs no negative caching whatsoever, meaning that the load on
the root servers from queries that have already been authoritatively
answered with NXDOMAIN is *enormous*. Further, there seems to have been
a bug in many versions of MSDNS that caused it to repeatedly ask the
same in-addr.arpa PTR query as fast as it possibly could, despite having
recieved authoritative NXDOMAIN responses. At one point,
f.root-servers.net was getting multiple instances of the same PTR query
from the same host *per click* of its (milisecond) timer. Let that sink
in a bit. Sustained instances of the same server asking the same
question several times per milisecond. This is not what I call 'works
great' in an operational context.
MSDNS has historically also had terrible problems with some A queries.
It has an annoying tendency to ask for A records for IP addresses, for
example, and has had a byte order bug that causes some query packets to
claim, mysteriously, to contain 256 questions. Such malformed queries
are known to constitute over 10% of the query load on
f.root-servers.net, and are likely an even higher percentage of the load
on A.
Add to that the load that the root servers see from improperly
configured MSDNS servers in an AD setting- OK, so allowing queries for
internal AD names out onto the internet is a configuration issue, not a
product design issue, but the rate that these things escape from
Microsoft shops onto the internet is not a trivial problem for the root
and gtld server operators. All these factors combined add up to a quite
measurable traffic load for the target audience of this list, ISP dns
operators.
Evi gave an extremely interesting talk at NANOG this past February
discussing these issues. It's not specifically dedicated to discussing
breakage of MSDNS, but in the end the percentage of global DNS
brokenness that's directly attributable to Microsoft turns out to be
dismayingly large. I'd heartily recommend that everyone contemplating
deploying MSDNS in an environment where it can talk to the internet take
a half hour to watch the Real Video stream of the presentation "DNS
Damage- Measurement at a Root Server", available at
http://www.caida.org/outreach/presentations/nanog0202/. Take special
note of Evi's almost offhand comment that she had to use IETF contacts
to get Microsoft to fix certain relatively obvious bugs in MSDNS. That's
atrocious.
So to answer the original poster's question: Yes, it really is That Bad.
Don't deploy it in any scenario where it can talk to servers that you
don't run, because it still causes an incredible slice of brokenness in
the public DNS.
"
Len
__________________________________________________________________
www.menandmice.com/DNS-training : DNS Training
BIND8NT.MEIway.com : ISC BIND for NT4 & W2K
IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
