Thursday, June 24


I discovered a few interesting technical bits this morning that I haven't seen before.

First, DNS operating order (as you may know) is:
(1) Check local host name
(2) Check hosts file
(3) Check DNS servers

If you query for domain name on an Active Directory domain controller, it doesn't resolve in the first step. So, you'd need proper DNS entries for the domain (or an entry in Hosts). I would've thought a query on a DC for domain name would resolve immediately, but when using a client that relies on DNS (like an ADSI script), it doesn't resolve.

Next, I found that a simple LDAP lookup (using domain name / rootDSE) via ADO resolved fine where a similar script using ADSI did not. So, apparently, ADO does NOT rely on DNS to attach to the rootDSE but ADSI DOES rely on DNS.

When evaluating whether to use ADO or ADSI, I recall that ADSI was generally easier, but there may be improved performance with ADO for larger record sets. I'm not sure if that's true, but that's what I remember reading years ago. I wonder if use of DNS should be an additional consideration in some cases?


Larry Aucoin said...

Hey Matt, Interesting findings. If you are talking about using ADSI to talk LDAP, then I would recommend using the newer "System.DirectoryServices.Protocols" (S.DS.P) API.

I wouldn't say it is easier than ADSI, but far more flexible, powerful, efficient and stable than ADSI. Here is the link:

Matt Flynn said...

Thanks for the update Larry. It's been a while since I've had use any of these. Doesn't System.DirectoryServices use ADSI? If not, I wonder how it deals with name resolution.