DNS & IIS --resolving a domain and subdomain to the same URL

hi daniel_c,

the problem is that mycompany.com already has a different host record, and that this host is used for the company's Active Directory domain.  For example purposes, let's say the mycompany.com host record contains the following IP's for itself and other DC's in the domain: 10.0.0.1, 10.0.0.2, and 10.0.0.3.

let's also say that www.mycompany.com has a host record which points to IP 255.0.0.1


If I add 255.0.0.1 to the host record for mycompany.com, won't it affect the way the DNS lookups happen on the internal network? Remember, mycompany.com is an AD domain on an internal network; so won't adding a record make an additional DNS "round trip" for those looking for DNS or other AD services on the internal network, and not looking for the web site?

thanks for the clarification!
pete

I have this same problem today.  It looks like it was working, but now is broken.  One thing I came across is this entry for http services in DNS:

_http._tcp.mycompany.com. IN  SRV 0  0  80      webserver1.mycompany.com.

do you already have this in your DNS?  I'm wondering if this is the solution but haven't had a chance to test the theory.  perhaps this solves the problem....which leaves me to wonder how it got removed from my DNS ;o)

Let me know if this is already there, or if it makes a difference.  Thanks

Gord

Gord, I will look into this issue. Maybe this is the solution.

Hi Gord,
I think this might be the answer. I will hopefully be able to test & reply in the next week.
Thanks,
Pete

Hi Gord,

Turns out this does not make any difference in IIS, because few clients actually browse using SRV records. IE, Netscape, and other major web browsers do not support SRV records.

What we may be able to do is just to set up another host record for our domain. Because Active Directory use SRV records to find the location of certain services (ldap, kerberos, etc), it shouldn't pose any problem adding that host record to the domain.

Thanks,
Peter

Hi Peter:

THat didn't work for me either....I thought it was working in the lab, but once I got into the real world, it did't help.  I opened a ticket wih Microsoft....at one point they said you couldn't do it.  They also said you shouldn't name your active directory domain the same as your internet domain.  interesting.......

Microsoft is taking another kick at the can, after I rattled a few cages with them.  If they can find an answer or make a recommendation I'll let you know.  

Have a good one.

Gord

Great, I'd like to hear the resolution Gord.

Yes, I am aware of the issue that you shouldn't name your Active Directory (AD) domain the same as your Internet domain. This is really due to the fact that AD makes such heavy use of DNS that it would be pretty easy to get situations where you want an internet domain to do one thing but AD wants to do something else.

--Pete

Hi Pete:

Yes, you got it.  Microsoft has promised that an internal DNS expert will call me to discuss further.  In a way it all makes sense, but I have two things I need an explanation for.

1) In my case there are 10 DCs all"eligible" to be resolved for a lookup on mycompany.com.  Only 3 are running services on port 80.  Originally, it ALWAYS resolved to server A, and now it ALWAYS resolves to server B.  If it was simply an issue of the web lookups conflicting with DC entries, I'd expect it to be random....different addresses being returned at different times.  This is not the case, so why is it so rock-solid consistent?  Perhaps in understanding this, we'll find a way to "control" the response to lookups (which would allow us to solve the issue).

2) I need a clear explanation of how the SRV records come into play.  Why isn't the _http record I set up doing what I think it should do?  This may be a misunderstanding on my part, but what's the point of having an _http SRV record??  Hopefully they can fill me in.

I'll try to post any further info I get on the matter.  In the meantime, the response is "yup, that's the way it works".  Here's the official word I received from Microsoft:

The AD domain mycompany.ca and the external website have the same domain name.

So, if an internal user types in mycompany.ca and they are configured to use an internal DNS server (which they should be), the internal DNS server will resolve the record to a DC in the local domain (EAGLE).  If they have a DNS host (A) record, “www” in the zone that will resolve to the external web site, then this will work, but just typing in the domain name alone will always resolve to a DC in the domain.

In the domain planning phase, this can be avoided by using an internal DNS namespace such as corp.mycompany.ca, or mycompany.local.  

Hi Gord,

With regards to answer #1, I wonder if it has to do with the "sites" in AD. I have heard that Windows tries to localize certain server requests based on the site that the DC's are a part of. This is by design, to ensure that authentication and directory search requests are handled by the "geographically" closest DC to the client (for example, if you had offices in Los Angeles, New York, and Chicago, you'd want people in L.A. authenticating against the L.A. DC, right?) Anyway, I wonder if this applies at all also to DNS queries, because as you know, A/D is highly integrated with Windows DNS.

Re: the SRV records, my understanding is that SRV records were introduced as part of the DNS protocol, but haven't caught on (see: http://www.faqs.org/rfcs/rfc2782.html). Windows uses them to direct or locate certain services like Kerberos and LDAP within a domain, or to help locate domain controllers, but that's about all. Because no major web browsers support lookups by SRV, using the _http SRV would be worthless.

Re: Microsoft's answer, it's unfortunately very ugly. I don't believe anyone should have to run IIS or any other web server on a DC just to re-direct to the web domain. Obviously IIS on a DC is not very secure, because historically IIS has been prone to exploits.

There's just got to be a better solution... :(  MAybe the solution will "simply" be renaming the Active Directory domain...

--pete