|
It was
a combination but the main problem was the domain they used, that solved it
cleared up most of the problems
Clearly the problem was deeper than just the domain they
choose, there were issues with their overall architecture. Was that not
the case?
Matt
ISPhuset Nordic / Benny Samuelsen
wrote:
sure
but yuo will still have the same problem as i see it if I fex register the
domain then I can "steal" the traffic... its the same
result.
I
have an ex. hereon a company who set up there system like this and they could
suddenly not send internal mail anymore... why wll someone had registered the
domain they used as an internal domain... 600 users couldnt send mail for 8
weeks cost them big money to fix this
ISPhuset Nordic / Benny Samuelsen wrote:
Thats why you are supposed to use fex
.loc That makes some sense, however there has
been plenty of talk about allowing an infinite number of TLD's on the
Internet. Also, many companies actually use a sub-directory of their
primary domain for their Active Directory. I believe that your AD server
would be sending lookups out to the root servers even if you used .loc as your
TLD, the only difference is that .loc won't return SiteFinder, but something
on .com and .net will now, but before it worked the same as .loc as long as
your name wasn't registered.
if fex someone register this domain u use and then
someone on the inside want to send an email to to them it will never get
trough !!!! Only if your E-mail server is behind
your Active Directory server. I can't see why you would want to do
that. My Web/mail server doesn't use Active Directory and is located
off-site.
Jesus this is so basic in AD i thought most people know about those
failures When I set up my AD server, I spent
dozens of hours trying to figure the thing out by reading just about every
document on Microsoft's Web site that I could find. No where did I ever
see such a thing mentioned. As things stand, I wasted enough time
setting up AD for what is currently a 2 computer network and I'm sure that
many others feel the same way. I'm quite happy with my internal name
also, and have no interest in changing it. If I want to register it,
it's only $10 a year.
What I'm pointing to with this is actually
support for why something needs to be returned by the root servers saying
record doesn't exist instead of just matching whatever they get with their
site, even processing the E-mail that is received which would otherwise be
unaddressable.
Matt
Who says that I have to register the domain that
Active Directory is using? My Active Directory name isn't intended to
be used on the Internet. In most installations, you look to your own
Active Directory server first for the lookups, so if it exists on the
Internet it won't interfeer...until now.
I think this is one of the
issues that ICANN was talking about concerning how the change can have
unintended consequences (besides spam blockers). This also looks to be
a problem in general with how Microsoft delegates lookups. Their
software shouldn't take the root of your Active Directory tree and then
append sub-domains to it and turn to the root servers for resolution.
That appears to be a security risk if you ask me, and it doesn't make sense
to do.
Matt
John Tolmachoff (Lists) wrote:
Ah yes, using an unregistered domain name with a real TLD is a no-no. When
are people using AD going to get this?
AD must be configured correctly or else problems will come up when you least
expect it.
John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 12:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your
domain.
I figured it out. The problem is definitely with Active Directory. Turning
off DNS Client on the local server only created a situation where their
first bogus sub-domain would timeout but a retry would still go to
SiteFinder. Here's what nslookup returns when directed at the DNS server on
the co-located machine (not running Active Directory):
adsfadsfasfdadsf.declude.com
Server: ns1.igaia.com
Address: 208.7.179.11
Non-authoritative answer:
Name: adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com
Address: 64.94.110.11
That's the bogus sub-domain appended to my local Active Directory domain
(replaced for security with an equivalent). The issue relates to the fact
that my real Active Directory domain name is not registered and lies in the
.com namespace, so when the lookup fails on the primary server, it goes back
to the local Active Directory server and appends the lookup that produces no
match to my unregistered Active Directory name, which returns the IP for
SiteFinder. If I registered my Active Directory name, I wouldn't be
directed to SiteFinder.
Make sense now?
Matt
|
