Follow-up: nt doesn't always resolve 15-character FQ domain names

• To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
• Subject: Follow-up: nt doesn't always resolve 15-character FQ domain names
• From: Mike Lonergan <mikeopentext.com>
• Date: Fri, 11 Dec 1998 11:12:59 -0500
• Approved-By: Russ.CooperRC.ON.CA
• Importance: Normal
• Reply-To: Mike.Lonerganopentext.com
• Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>

Hi all,

Quite a lesson in how to post to a list of this nature.  I thought I'd share
the results of the emails to me so far, so as to keep this group informed on
our progress.  Please read my previous post for the original details.

- the DNS resolution of the 16-character, double-dotted FQDN
(Fully-Qualified Domain Name) worked fine for months while I was running NTW
with SP3; all other DNS resolutions worked fine as well
- it was only after I installed SP4 that I began to notice the resolution of
the FQDN in question began to fail, and fail consistently
- all resolutions of less-than-16-character, double-dotted FQDNs still
succeed (at the DNS stage), as do those of greater-than-16-characters (in
the latter case, NetBIOS resolution isn't even attempted)
- accessing the server via its IP address works just fine (as it should)
i.e. Start, Run, "\\10.1.1.100\sharename"
- the length of the sharename doesn't matter at all, since the name-to-IP
resolution only proceeds for the host portion (between the "\\" and the "\"
portion of the UNC value)
- as you could infer from my description of the name resolution sequence, my
system is configured as an h-node (not that this should affect the way the
*DNS* resolution proceeds)
- I handn't heard of the Windows95 crashing behaviour when attempting to
resolve 16-character names, so it may well be related to the new Winsock2
code; however, NT doesn't crash - it merely truncates the last character
when performing the last stage (i.e. DNS) of the resolution process- this is
not the same issue as reported in KB article Q195611 - that article refers
to difficulties in querying all necessary DNS servers, while this is an
issue of an incomplete string being posed in the DNS question
- I won't be adding "names.server.co" to my DNS server - for reasons too
technical to explain here, it might be a little difficult to make my
nameserver authoritative for the ".co" root  ;)
- I also won't be adding it to my local HOSTS file - I won't yet accomodate
a problem that didn't exist until recently (i.e. the name resolution
services in NT *were* working up until recently, and should be again as soon
as they reinstate the missing rule to handle this one special case of name
resolution)

Yes, I *know* that NetBIOS names have a maximum of 15 characters plus one
for the 16th byte NetBIOS value - however, the NetBIOS name resolution
stages of the sequence work fine (they attempt to resolve the full
16-character string as a NetBIOS name, or at least that's what Network
Monitor reports).  That's why I finally considered this a bug, as I believe
that there has been a change in how the relevant subsystem passes off
16-character "NetBIOS names" from the NetBIOS resolution mechanism to the
DNS resolution mechanism.  I maintain that even if this is the "magic
number", the name resolution subsystem should be able to manage to hand off
this variable (the unresolved string = FQDN) from one subroutine to the next
without truncating.

I count 5 others who report exactly the same problem so far.

Thanks everyone!

Mike Lonergan, MCP
Systems Administrator
Mike.Lonerganopentext.com
Open Text Corporation

• Prev by Date: Excel vulnerability?
• Next by Date: Strange Account Lockouts
• Prev by thread: Re: Excel vulnerability?
• Next by thread: Strange Account Lockouts
• Index(es):
  • Date
  • Thread