|
|
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-E29DE56888A3[ at ]microsoft.com,
Victor S. <VictorS[ at ]discussions.microsoft.com> requesting assistance, typed
the following:
[Quoted Text] > 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:
[Quoted Text] > In news:3B8E4807-0EB5-4115-803B-E29DE56888A3[ at ]microsoft.com, > Victor S. <VictorS[ at ]discussions.microsoft.com> 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-E321A10B6651[ at ]microsoft.com,
Victor S. <VictorS[ at ]discussions.microsoft.com> requesting assistance, typed
the following:
[Quoted Text] > 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:
[Quoted Text] >
> 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-25C478C2DDB9[ at ]microsoft.com,
Victor S. <VictorS[ at ]discussions.microsoft.com> requesting assistance, typed
the following:
[Quoted Text] >
> 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%23LPKJHA.5336[ at ]TK2MSFTNGP05.phx.gbl,
Ace Fekay [Microsoft Certified Trainer] <firstnamelastname[ at ]hotmail.com>
requesting assistance, typed the following:
[Quoted Text] >
> 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
|
|
|