Odd behavior when clicking on internal link that is using a non-FQDN
Kevin Darcy
kcd at daimlerchrysler.com
Fri Dec 2 22:58:43 UTC 2005
Can you look at your query logs to see what is actually being looked up?
Put a sniffer in between a client and its nameserver?
- Kevin
Smith, William E. (Bill), Jr. wrote:
>As far as I know, the clients that initially reported the problem had
>just jhuapl.edu listed in their suffix search order. In my case, it was
>jhuapl.edu and dom1.jhuapl.edu, neither of which would apply here, thus
>piquing my interest even further about the whole scenario. Point taken
>re: fully qualifying domain names and agree with your stance as well
>there.
>
>- Bill
>
>-----Original Message-----
>From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
>Behalf Of Kevin Darcy
>Sent: Thursday, December 01, 2005 6:48 PM
>To: bind-users at isc.org
>Subject: Re: Odd behavior when clicking on internal link that is using a
>non-FQDN
>
>What do your clients have as their "suffix search order" and/or
>"connection-specific suffixes"? That's what determines how they resolve
>shortnames.
>
>If they're going through a web proxy, then you'd need to look at that
>web proxy's resolution configuration in the same way.
>
>This is one reason why shortnames are inherently evil. Just think if the
>MacBidouille site was a Trojan Horse site that looked even passingly
>like your internal "mbserv1" site: it could entice your users (at least
>some of them -- the less observant ones) to authenticate to their site
>and steal their passwords, which are likely to be the same passwords
>they use for authenticating elsewhere. That could then be used to
>leverage identity theft, unauthorized system access, etc. Using
>fully-qualified domain names everywhere mitigates these security risks
>as well as making for more efficient name resolution all around. I
>realize I'm a voice in the wilderness here...
>
>- Kevin
>
>Smith, William E. (Bill), Jr. wrote:
>
>
>
>>On one of our internal web pages, the following link is present,
>>http://mbserv1/pdp. The server known as mbserv1 was shutdown about 2
>>months ago and is no longer present on our network. Despite this, some
>>
>>
>
>
>
>>users have reported that when clicking the link, they are taken to a
>>French site. When I reproduced this problem, I was taken to the
>>following page.
>>
>>http://forum.macbidouille.com/index.php?showtopic=73116&st=90
>>
>>What exactly would be causing this? My only guess is that it's related
>>
>>
>
>
>
>>to the hostname not being fully qualified and the browser subsequently
>>trying to resolve the request by appending a myriad of other domain
>>names before it finally found a match with mbserv1.macbidouille.com,
>>which in turn takes you to the MacBidouille home page. The obvious fix
>>
>>
>
>
>
>>would be to fully qualify the domain name or better yet just remove the
>>
>>
>
>
>
>>link altogether since it's no longer valid. That said, I'm curious as
>>to what is causing this and even more curious as to why I'm taking
>>directly to the forum page when clicking on the internal link but to
>>the home page when going to http://mbserv1.macbidouille.com
>>
>>Bill Smith
>><mailto:bill.smith at jhuapl.edu>
>>ISS Server Systems Group
>>Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins
>>
>>
>
>
>
>>Road Laurel, MD 20723
>>Phone: 443-778-5523
>>Web: http://www.jhuapl.edu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
More information about the bind-users
mailing list