Disable appending of primary DNS suffix?

Is there a way to disable the appending of the primary DNS suffix when
resolving hostnames but still have the connection-specific DNS suffix
appended?

The problem is that someone registered a domain name that is identical to
our internal AD domain name. (Yeah, I know, we should have taken more care
in choosing our internal domain name, but the people that did this are long
gone and we are stuck with the issue.) Whoever registered the domain name
(let's use company.com as an example) set up a wildcard DNS record (i.e.,
catch-all) that redirects all hostnames to the same external IP address
(e.g., 72.3.135.151). The problem happens when users go to clients' sites.
Unless the FQDN is used, everything resolves to that one external IP address
(e.g., webserver1 resolves to 72.3.135.151 because the DNS client appends the
primary DNS suffix, then looks up webserver1.company.com). On the other
hand, if a user's laptop is not part of the domain and the primary DNS suffix
is not set, then it works properly (e.g., webserver1 get ourclient.com
appended to it, which the internal DNS servers resolve to 10.6.23.16).

I know there are workarounds, but each one I've come up with has drawbacks
(e.g. changing the primary DNS suffix can break certain services unless the
computer object in AD is updated with the new FQDN).

Thanks in advance,

Victor S.

In news:3B8E4807-0EB5-4115-803B-,
Victor S. <> requesting assistance, typed
the following:
> Is there a way to disable the appending of the primary DNS suffix when
> resolving hostnames but still have the connection-specific DNS suffix
> appended?
>
> The problem is that someone registered a domain name that is
> identical to our internal AD domain name. (Yeah, I know, we should
> have taken more care in choosing our internal domain name, but the
> people that did this are long gone and we are stuck with the issue.)
> Whoever registered the domain name (let's use company.com as an
> example) set up a wildcard DNS record (i.e., catch-all) that
> redirects all hostnames to the same external IP address (e.g.,
> 72.3.135.151). The problem happens when users go to clients' sites.
> Unless the FQDN is used, everything resolves to that one external IP
> address (e.g., webserver1 resolves to 72.3.135.151 because the DNS
> client appends the primary DNS suffix, then looks up
> webserver1.company.com). On the other hand, if a user's laptop is
> not part of the domain and the primary DNS suffix is not set, then it
> works properly (e.g., webserver1 get ourclient.com appended to it,
> which the internal DNS servers resolve to 10.6.23.16).
>
> I know there are workarounds, but each one I've come up with has
> drawbacks (e.g. changing the primary DNS suffix can break certain
> services unless the computer object in AD is updated with the new
> FQDN).
>
> Thanks in advance,
>
> Victor S.


Curious, how are you machine's ipconfigs setup in regards to DNS? Are you
using an outside DNS server in conjunction with the internal DNS server? If
so, I can see this would be happening, otherwise, if set based on AD's
needs, which is to ONLY use the internal DNS server, and set a Forwarder to
your ISP's DNS server in DNS properties, then the problem wouldn't occur. If
you have mixed internal and external DNS server in ip properties, then when
it queries an outside address, I can see why this is occuring.

Do me a favor and post an unedited ipconfig /all from one of your
workstations please.

--�
Regards,
Ace

This posting is a personal opinion based on experience, and is provided
"AS-IS" with no warranties or guarantees and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCT
Microsoft Certified Trainer

For urgent issues, you may want to contact Microsoft PSS directly.
Please check http://support.microsoft.com for regional support phone
numbers.

Thank you for your reply. When the computers are on the internal network,
the only DNS servers they have set are the internal domain controllers, so
everything works as it should. The problem occurs when laptop users travel
outside of our network. When that happens, they are obviously not using our
internal DNS servers so whenever the primary DNS suffix get appended, it
always resolves to the same external IP address (because of the wildcard DNS
record for the public domain that is the same as our internal domain).

Here is a sample "ipconfig /all" (with the names changed to protect the
innocent). This is with the laptop on a client's network (not on our
network). The laptop is joined to our domain (which, for this example, is
COMPANY.COM).

Windows IP Configuration

Host Name . . . . . . . . . . . . : laptop-02
Primary Dns Suffix . . . . . . . : COMPANY.COM
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : COMPANY.COM
ourclient.com

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : ourclient.com
Description . . . . . . . . . . . : Broadcom NetXtreme 57xx Gigabit
Controlle
r
Physical Address. . . . . . . . . : 00-1C-23-27-2B-61
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::58c0:4a12:cfd:241d%10(Preferred)
IPv4 Address. . . . . . . . . . . : 172.25.110.3(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Lease Obtained. . . . . . . . . . : Thursday, October 02, 2008 8:52:28 AM
Lease Expires . . . . . . . . . . : Friday, October 10, 2008 8:52:22 AM
Default Gateway . . . . . . . . . : 172.25.0.1
DHCP Server . . . . . . . . . . . : 172.25.19.1
DNS Servers . . . . . . . . . . . : 172.25.0.2
172.25.11.1
Primary WINS Server . . . . . . . : 172.25.0.3
Secondary WINS Server . . . . . . : 172.25.19.1
NetBIOS over Tcpip. . . . . . . . : Enabled


To give you an example of an incorrect resolution:

C:\>ping mail

Pinging mail.company.com [72.3.135.151] with 32 bytes of data:
Reply from 72.3.135.151: bytes=32 time=59ms TTL=46

If the laptop is not joined to our domain (and hence no primary DNS suffix),
then this is what I would get:

C:\>ping mail

Pinging mail.ourclient.com [172.25.10.10] with 32 bytes of data:
Reply from 172.25.10.11: bytes=32 time<1ms TTL=128

I realize that specifying the FQDN (even without the final period) would
produce the correct output, but this is just a simplified example. In some
cases, the laptop user cannot append the domain name, for example when just
the hostname is embedded in a client's intranet pages.


"Ace Fekay [Microsoft Certified Trainer]" wrote:

> In news:3B8E4807-0EB5-4115-803B-,
> Victor S. <> requesting assistance, typed
> the following:
> > Is there a way to disable the appending of the primary DNS suffix when
> > resolving hostnames but still have the connection-specific DNS suffix
> > appended?
> >
> > The problem is that someone registered a domain name that is
> > identical to our internal AD domain name. (Yeah, I know, we should
> > have taken more care in choosing our internal domain name, but the
> > people that did this are long gone and we are stuck with the issue.)
> > Whoever registered the domain name (let's use company.com as an
> > example) set up a wildcard DNS record (i.e., catch-all) that
> > redirects all hostnames to the same external IP address (e.g.,
> > 72.3.135.151). The problem happens when users go to clients' sites.
> > Unless the FQDN is used, everything resolves to that one external IP
> > address (e.g., webserver1 resolves to 72.3.135.151 because the DNS
> > client appends the primary DNS suffix, then looks up
> > webserver1.company.com). On the other hand, if a user's laptop is
> > not part of the domain and the primary DNS suffix is not set, then it
> > works properly (e.g., webserver1 get ourclient.com appended to it,
> > which the internal DNS servers resolve to 10.6.23.16).
> >
> > I know there are workarounds, but each one I've come up with has
> > drawbacks (e.g. changing the primary DNS suffix can break certain
> > services unless the computer object in AD is updated with the new
> > FQDN).
> >
> > Thanks in advance,
> >
> > Victor S.
>
>
> Curious, how are you machine's ipconfigs setup in regards to DNS? Are you
> using an outside DNS server in conjunction with the internal DNS server? If
> so, I can see this would be happening, otherwise, if set based on AD's
> needs, which is to ONLY use the internal DNS server, and set a Forwarder to
> your ISP's DNS server in DNS properties, then the problem wouldn't occur. If
> you have mixed internal and external DNS server in ip properties, then when
> it queries an outside address, I can see why this is occuring.
>
> Do me a favor and post an unedited ipconfig /all from one of your
> workstations please.
>
> --�
> Regards,
> Ace
>
> This posting is a personal opinion based on experience, and is provided
> "AS-IS" with no warranties or guarantees and confers no rights.
>
> Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCT
> Microsoft Certified Trainer
>
> For urgent issues, you may want to contact Microsoft PSS directly.
> Please check http://support.microsoft.com for regional support phone
> numbers.
>
>

In news:92495B48-AAD4-425E-BD6C-,
Victor S. <> requesting assistance, typed
the following:
> Thank you for your reply. When the computers are on the internal
> network, the only DNS servers they have set are the internal domain
> controllers, so everything works as it should. The problem occurs
> when laptop users travel outside of our network. When that happens,
> they are obviously not using our internal DNS servers so whenever the
> primary DNS suffix get appended, it always resolves to the same
> external IP address (because of the wildcard DNS record for the
> public domain that is the same as our internal domain).
>
> Here is a sample "ipconfig /all" (with the names changed to protect
> the innocent). This is with the laptop on a client's network (not on
> our network). The laptop is joined to our domain (which, for this
> example, is COMPANY.COM).
>
> Windows IP Configuration
>
> Host Name . . . . . . . . . . . . : laptop-02
> Primary Dns Suffix . . . . . . . : COMPANY.COM
> Node Type . . . . . . . . . . . . : Hybrid
> IP Routing Enabled. . . . . . . . : No
> WINS Proxy Enabled. . . . . . . . : No
> DNS Suffix Search List. . . . . . : COMPANY.COM
> ourclient.com
>
> Ethernet adapter Local Area Connection:
>
> Connection-specific DNS Suffix . : ourclient.com
> Description . . . . . . . . . . . : Broadcom NetXtreme 57xx Gigabit
> Controlle
> r
> Physical Address. . . . . . . . . : 00-1C-23-27-2B-61
> DHCP Enabled. . . . . . . . . . . : Yes
> Autoconfiguration Enabled . . . . : Yes
> Link-local IPv6 Address . . . . . :
> fe80::58c0:4a12:cfd:241d%10(Preferred) IPv4 Address. . . . . . . .
> . . . : 172.25.110.3(Preferred) Subnet Mask . . . . . . . . . . . :
> 255.255.0.0 Lease Obtained. . . . . . . . . . : Thursday, October
> 02, 2008 8:52:28 AM Lease Expires . . . . . . . . . . : Friday,
> October 10, 2008 8:52:22 AM Default Gateway . . . . . . . . . :
> 172.25.0.1 DHCP Server . . . . . . . . . . . : 172.25.19.1
> DNS Servers . . . . . . . . . . . : 172.25.0.2
> 172.25.11.1
> Primary WINS Server . . . . . . . : 172.25.0.3
> Secondary WINS Server . . . . . . : 172.25.19.1
> NetBIOS over Tcpip. . . . . . . . : Enabled
>
>
> To give you an example of an incorrect resolution:
>
> C:\>ping mail
>
> Pinging mail.company.com [72.3.135.151] with 32 bytes of data:
> Reply from 72.3.135.151: bytes=32 time=59ms TTL=46
>
> If the laptop is not joined to our domain (and hence no primary DNS
> suffix), then this is what I would get:
>
> C:\>ping mail
>
> Pinging mail.ourclient.com [172.25.10.10] with 32 bytes of data:
> Reply from 172.25.10.11: bytes=32 time<1ms TTL=128
>
> I realize that specifying the FQDN (even without the final period)
> would produce the correct output, but this is just a simplified
> example. In some cases, the laptop user cannot append the domain
> name, for example when just the hostname is embedded in a client's
> intranet pages.
>
>

THanks for posting that info. It appears you are in a difficult situation.
How many laptop users do you have? One resolution is to create hosts entries
in the HOSTS file for your domain resources, such as www.domain.com,
ftp.domain.com, mail.domain.com, etc.

Doing a reverse on that IP it pinged, it comes out to be an ISP:
Name: www.2sitelauncher.com
Address: 72.3.135.151

Apparently they have numerous sites and apparently as well that your domain
is one of them. Not much you can do about that. You don't want to disjoin
the laptops either, which would eliminate the Primary DNS Suffix, however
you need to keep that on the laptops to find AD domain resources and other
AD functions to work.

Try a HOSTS file on one of them.

Ace

"Ace Fekay [Microsoft Certified Trainer]" wrote:
>
> THanks for posting that info. It appears you are in a difficult situation.
> How many laptop users do you have? One resolution is to create hosts entries
> in the HOSTS file for your domain resources, such as www.domain.com,
> ftp.domain.com, mail.domain.com, etc.
>
> Doing a reverse on that IP it pinged, it comes out to be an ISP:
> Name: www.2sitelauncher.com
> Address: 72.3.135.151
>
> Apparently they have numerous sites and apparently as well that your domain
> is one of them. Not much you can do about that. You don't want to disjoin
> the laptops either, which would eliminate the Primary DNS Suffix, however
> you need to keep that on the laptops to find AD domain resources and other
> AD functions to work.
>
> Try a HOSTS file on one of them.
>
> Ace

Thank you again for your response. As I mentioned, when on our network,
everything work great so HOSTS entries for our domain would not be needed,
but when on a client's network, that is one of the workarounds that I now use
when a FQDN cannot be used to refer to a client's server (e.g., when the
short name is embedded in a link on their Intranet). It works, but is a pain
to deal with considering multiple laptop users and the clients that are
visited. I was hoping for an easier solution but looks like we're stuck for
now with what we've got (but perhaps not for too much longer - we might be
abandoning our internal AD domain in a few months and become part of a larger
AD domain).

Thanks again,

Victor

In news:CAFCA406-5515-4130-A3AC-,
Victor S. <> requesting assistance, typed
the following:
>
> Thank you again for your response. As I mentioned, when on our
> network, everything work great so HOSTS entries for our domain would
> not be needed, but when on a client's network, that is one of the
> workarounds that I now use when a FQDN cannot be used to refer to a
> client's server (e.g., when the short name is embedded in a link on
> their Intranet). It works, but is a pain to deal with considering
> multiple laptop users and the clients that are visited. I was hoping
> for an easier solution but looks like we're stuck for now with what
> we've got (but perhaps not for too much longer - we might be
> abandoning our internal AD domain in a few months and become part of
> a larger AD domain).
>
> Thanks again,
>
> Victor

Unfortunately HOSTS files are either used or not. It's not easy to
enable/disable hosts files individually for a user. The dupe name
unfortunately is difficult to get around. If you can wait until you are
absorbed by a merger (assuming that is what you mean), I would wait.

--�
Ace

This posting is a personal opinion based on experience, and is provided
"AS-IS" with no warranties or guarantees and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCT
Microsoft Certified Trainer

For urgent issues, you may want to contact Microsoft PSS directly.
Please check http://support.microsoft.com for regional support phone
numbers.

In news:eMmK%,
Ace Fekay [Microsoft Certified Trainer] <>
requesting assistance, typed the following:
>
> Unfortunately HOSTS files are either used or not. It's not easy to
> enable/disable hosts files individually for a user. The dupe name
> unfortunately is difficult to get around. If you can wait until you
> are absorbed by a merger (assuming that is what you mean), I would
> wait.


I forgot to add "when you have numerous users," to this sentence:
"It's not easy to enable/disable hosts files individually for a user."

You could probably use a script using the xcopy command as part of their
logon script.

Ace

"rom" <> wrote in message
news:...
>
> Hello.
> I had the same problem and found a solution, - just add "." in the DNS
> suffix list. You can do this manually or thru Domain Group Policy.
>
>
> --
> rom
> -----------------------------------------------------------------------
>
> http://forums.techarena.in
>


What "same" problem did you have? If you notice your posting, it doesn't
have the original post, so folks in the free (anonymous allowed) Microsoft
Newsgroups can't see what you are talking about. Keep in mind, ALL posts
from techarena are pulled/posted to the Microsoft newsgroups. Yep, that's
where they get their posts from and resulting help comes from, even if a
member in techarena responds, it populates the Microsoft free newsgroups.

When you reply to a post in http://forums.techarena.in, and the post or
thread is older than 90 days, it shows up as a broken thread on a Microsoft
Public newsgroup, and unfortunately, most of the world will not see what you
are responding to, so most of the world can't see what you are replying to
or commenting about. Sure, if you are a techarena subscriber, you can see
the old thread, but remember, that is only a small percentage of the world.
You are not getting good exposure for your problem.

Therefor, any responses or commenets you or anyone makes to such an older
post, means most of the world will not know what you are responding to,
because all we see is your post, and not the original because it will be a
broken thread on the original source, therefore in your current post we have
no reference to what you are talking about.

The reason is that Techarena's site, copies and posts back to the Micrsoft
newsgroups.

Such as if you've selected the following forum:
http://forums.techarena.in/small-business-server/

It copies posts from, and posts back to, Microsoft's SBS newsgroup,
specifically:
NewsServer: news.microsoft.com
newsgroup: microsoft.public.windows.server.sbs

To avoid this problem, either post a fresh thread, copy and paste the
original post and add relevance to your own problems, provide specifics such
as ipconfigs, EventID#s from errors in the event log, symptoms, etc. This
way we can better assist you.

You can also avoid Techarena.in and post directly to the Microsoft
newsgroup, you will benefit from threads not getting broken.

You can either use a NNTP News Reader (Example Outlook Express), and set it
up with:
NewsServer: news.microsoft.com

The choose a relevant newsgroup below (there are much more - this is just a
representative of some of the groups and the name format)
newsgroup: microsoft.public.windows.server.networking
newsgroup: microsoft.public.windows.server.general
newsgroup: microsoft.public.windows.server.active_directory
newsgroup: microsoft.public.windows.server.dns
newsgroup: microsoft.public.windows.server.sbs

or By Clicking one of the links below (there are much more - this is just a
representative of some of the groups and the name format)
news://msnews.microsoft.com/microsof...ows.server.sbs
news://msnews.microsoft.com/microsof...server.general
vnews://msnews.microsoft.com/microsoft.public.windows.server.networking
news://msnews.microsoft.com/microsof...tive_directory
news://msnews.microsoft.com/microsof...ows.server.dns

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit among
responding engineers, and to help others benefit from your resolution.

Ace Fekay, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA
2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer

For urgent issues, please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.