Well, $10 fixes my "problem," but I'm really not concerned with fixing it, though I might register that domain name anyway. And ICANN has no claim to names used on a private network.

What's new/strange to me is that my primary is the non-AD server that has no clue that my local AD server/domain exists. My computer looks up fake.declude.com on my external AD-unaware server and returns no record exists, but then my computer does another lookup using my AD-server's domain and appends fake.declude.com to it. Maybe this wouldn't happen if I was using my local AD server as my primary, but I purposefully chose the external DNS server for testing purposes, and I'm going to keep it that way. Clearly Microsoft intended on providing some form of functionality, but the result is that a Web browser doesn't see the IP being returned as being appended to my AD domain, it just sees it as being the un-resolveable yet registered domain, fake.declude.com.

Matt



John Tolmachoff (Lists) wrote:

Problem1. If the AD domain is called 123exampleforme.com, and someone registers that on the internet, you are now according to ICANNA regulations illegally using a registered name.



Problem 2. If you do not have forwarders properly configured in the DNS server that is used, you are querring the root servers, which are controlled by Verisign. Therefore, you are subject to that control.



This is way it is always recommended that if you are going to use a unregistered domain name in AD, you use a fake TLD, such as .moc or .abc or .mine or such AND have forwarders properly configured.



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 10:40 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.




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 <http://www.eservicesforyou.com>



-----Original Message-----

From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble

Sent: Monday, September 22, 2003 12:52 AM

To: [EMAIL PROTECTED] <mailto:[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







Reply via email to