Martin v. Löwis wrote:
> 
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
>> Sorry, I didn't mean how Windows constructs the result for the
>> "A" interface - I was talking about Python code being able to map
>> the result from the Unicode interface to the form used in the
>> protocol (e.g. DNS).  I believe the proposal is to use the DNS
>> name
> 
> I disagree with the proposal - it should return whatever
> name gethostname from winsock.dll returns (which I expect
> to be the netbios name).
> 
>> so since the DNS is byte oriented, I would have thought
>> that the Unicode "DNS name" result would always have a bytes
>> equivalent that the DNS resolver code would use - perhaps its
>> UTF-8 encoding?
> 
> No no no. When Microsoft calls it the DNS name, they don't actually
> mean that it has to do anything with DNS. In particular, it's not
> byte-oriented.

Just to clarify: I was proposing to use the
GetComputerNameExW() win32 API with ComputerNamePhysicalDnsHostname,
which returns Unicode without needing any roundtrip via bytes
and the issues associated with this.

I don't understand why Martin insists that the MS "DNS name"
doesn't have anything to with DNS... the fully qualified
DNS name of a machine is determined as hostname.domainname,
just like you would expect in DNS.

http://msdn.microsoft.com/en-us/library/ms724301(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms724224(v=VS.85).aspx

As I said earlier: NetBIOS is being phased out in favor of
DNS. MS is using a convention which mandates that NetBIOS names
match DNS names. The only difference between the two is that
NetBIOS names have a length limitation:

http://msdn.microsoft.com/en-us/library/ms724931(v=VS.85).aspx

Perhaps Martin could clarify why he insists on using the
ANSI WinSock interface gethostname instead.

PS: WinSock provides many other Unicode APIs for socket
module interfaces as well, so at least for that platform,
we could use those to resolve uncertainties about the
encoding used in name resolution.

On other platforms, I guess we'll just have to do some trial
and error to see what works and what not. E.g. on Linux it is
possible to set the hostname to a non-ASCII value, but then
the resolver returns an error, so it's not very practical:

# hostname l\303\266wis
# hostname
löwis
# hostname -f
hostname: Resolver Error 0 (no error)

Using the IDNA version doesn't help either:

# hostname xn--lwis-5qa
# hostname
xn--lwis-5qa
# hostname -f
hostname: Resolver Error 0 (no error)

Python2 happily returns the host name, but fails to return
a fully qualified domain name:

'l\xc3\xb6wis'
>>> socket.getfqdn()
'l\xc3\xb6wis'

and

'xn--lwis-5qa'
>>> socket.getfqdn()
'xn--lwis-5qa'

Just for comparison:

# hostname newton
# hostname
newton
# hostname -f
newton.egenix.internal

and

'newton'
>>> socket.getfqdn()
'newton.egenix.internal'

So at least on Linux, using non-ASCII hostnames doesn't really
appear to be an option at this time.