Odd behavior when clicking on internal link that is using a non-FQDN

[Smith, William E. (Bill), Jr.]

I will try one or both of your suggestions when I get a chance since the
issue still seems reproducible from my PC at least.  Hopefully, one will
shed some light on what's going on.

- Bill 

-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
Behalf Of Kevin Darcy
Sent: Friday, December 02, 2005 5:59 PM
To: bind-users at isc.org
Subject: Re: Odd behavior when clicking on internal link that is using a
non-FQDN

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    
>>
>>
>>
>>
>>
>> 
>>
>>    
>>
>
>
>
>
>
>
>  
>