Hello QSIDeveloper,
Yes, 10.10.60.221 is a IPv4 address. My last reply was based on my analysis
of Dns's source code and I found that IPv6 is a very possible cause of the
issue, thus I posted the finding to you. Now that we are using IPv4
address, I'd answer your question (1), (2) by analyzing the code path of
IPv4 in Dns:
==========================================
Both Dns.GetHostByAddress and Dns.GetHostEntry first demand Dns permissions
by calling:
s_DnsPermission.Demand();
After then, they call InternalGetHostByAddress.
In InternalGetHostByAddress, they first detect whether it's related to
IPv6. Because our address is a IPv4 one, the code path of both
Dns.GetHostByAddress and Dns.GetHostEntry go to this piece of code:
************************************************** ********
// Use gethostbyaddr() to try to resolve the IP address
//
// End IPv6 Changes
//
int addressAsInt = unchecked((int)address.m_Address);
#if BIGENDIAN
addressAsInt = (int)( ((uint)addressAsInt << 24) |
(((uint)addressAsInt & 0x0000FF00) << 8) |
(((uint)addressAsInt >8) & 0x0000FF00) |
((uint)addressAsInt >24) );
#endif
IntPtr nativePointer =
UnsafeNclNativeMethods.OSSOCK.gethostbyaddr(
ref addressAsInt,
Marshal.SizeOf(typeof(int)),
ProtocolFamily.InterNetwork);
if (nativePointer != IntPtr.Zero) {
return NativeToHostEntry(nativePointer);
}
exception = new SocketException();
}
if(throwOnFailure){
throw exception;
}
IPHostEntry ipHostEntry = new IPHostEntry();
try{
ipHostEntry.HostName = address.ToString();
ipHostEntry.Aliases = new string[0];
ipHostEntry.AddressList = new IPAddress[] { address };
}
catch{
throw exception; //throw the original exception
}
return ipHostEntry;
} // InternalGetHostByAddress
************************************************** ********
The code above first call the native function
UnsafeNclNativeMethods.OSSOCK.gethostbyaddr to get the host info. If it
succeeds, it call NativeToHostEntry to translate the native result to a
IPHostEntry object, otherwise, it throws an exception if throwOnFailture =
true, or sets the hostEntry's hostname property as the IP address.
In my opinion, there are two possible reasons for our symptom:
******* POSSIBLE REASON 1. *******
The native call UnsafeNclNativeMethods.OSSOCK.gethostbyaddr fails, and the
code path goes to:
try{
ipHostEntry.HostName = address.ToString();
ipHostEntry.Aliases = new string[0];
ipHostEntry.AddressList = new IPAddress[] { address };
}
,where the host name is set to the IP address.
This is a very possible reason, however, this assumption cannot explain why
GetHostByAddress is able to retrieve the host name info. GetHostByAddress
sets the parameter throwOnFailure = true. Thus, if GetHostByAddress also
fails at UnsafeNclNativeMethods.OSSOCK.gethostbyaddr, it would throw an
exception:
if(throwOnFailure){
throw exception;
}
******* POSSIBLE REASON 2. *********
The native call UnsafeNclNativeMethods.OSSOCK.gethostbyaddr succeeds, and
it calls
if (nativePointer != IntPtr.Zero) {
return NativeToHostEntry(nativePointer);
}
In the function NativeToHostEntry, the host name property is set at the
beginning:
hostent Host = (hostent)Marshal.PtrToStructure(nativePointer,
typeof(hostent));
IPHostEntry HostEntry = new IPHostEntry();
if (Host.h_name != IntPtr.Zero) {
HostEntry.HostName = Marshal.PtrToStringAnsi(Host.h_name);
GlobalLog.Print("HostEntry.HostName: " +
HostEntry.HostName);
}
In other words, UnsafeNclNativeMethods.OSSOCK.gethostbyaddr seems
successful, but it failed to get the correct host name.
The native function gethostbyaddr is introduced at:
http://msdn.microsoft.com/en-us/libr...21(VS.85).aspx
Currently, I cannot tell why the native call may return the ip address in
hostent.h_name because I'm not an expert on DNS and network, but I would
like to help you consult the product group, to see whether they have any
ideas.
==========================================
My Suggestions for you:
Debug into the source code of Dns, and compare the code path of
GetHostEntry and GetHostByAddress. In this way, we can tell which reason
above causes the problem.
(P.S. If I could reproduce the symptom in my lab, I would have debugged
into the issue for you.)
==========================================
For your question (3) If System.Net.Dns.Resolve and
System.Net.Dns.GetHostByAddress are
obsolete when will they stop working in the 2.0 framework?
The two functions are obsolete majorly because they cannot handle IPv6. For
IPv4, they will continue working.
Regards,
Jialiang Ge (ji****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
