I've recently come across a new behavior from getaddrinfo() that I'm curious if anyone else has seen. Namely, I have a Microsoft Azure virtual machine (IPv4, Windows Server), with a dedicated name (foobar.centralus.cloudapp.azure.com, as a fake example) and dynamically allocated/assigned IP address. When this machine is running, a getaddrinfo() query from a different (Win10) machine returns the expected public IP address. Previously, when this machine was stopped and deallocated, getaddrinfo() would return an error as expected. However, recently I've seen the case be that getaddrinfo() will return success, but with the address being the broadcast address (255.255.255.255). There are no other records returned.

This would appear to be a (new) quirk of Microsoft Azure's VM DNS/IP management, basically saying “I know that DNS name, but there is no IP address allocated for it”. My expectation (and the previous behavior) would be for the DNS lookup to simply fail.

Has anyone seen this kind of behavior in this or any other context? Is there even a scenario where one could validly expect to get the broadcast address from getaddrinfo()?

For the time being it's enough for me to simply treat getting the broadcast address back as failure, but I'd be curious to hear anyone else's experience with this particular behavior.

You may want to check how the function is defined, and compare observed behavior against the definition.

@Alberth, thanks for the reply. I've been scouring the documentation and the internet in general, but I've yet to find any mention of this particular result. I've applied particular scrutiny to the hints flags and behaviors, but nothing jumps out at me there. None of the Microsoft samples have anything that deals with this case.

https://learn.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-getaddrinfo

As far as observed behavior goes, when it previously properly failed, it returned error 11001 (WSAHOST_NOT_FOUND / EAI_NONAME). Now, with the stopped/deallocated Azure VM in question, it returns 0 (success) but with an address of 255.255.255.255.

Worth noting that the code on my side hadn't changed in quite some time, but the Azure VM setup is new-ish (but had been working as expected for a while). Of course, the Azure infrastructure itself is obviously always evolving, so I expect that's the origin of this quirk.

This sounds very much like a specification … stretch … to me.

I would expect the returned address to actually be reachable for the machine when it's found.

But I guess the behavior in practice will be reasonable – you get the address for the name, you know the name exists, you try to connect to the given address, and you will get an error back from connect() because they machine isn't actually reachable…

Also note that the function getaddrinfo() behaves as specifies – it simply talks to a name server, and returns to your program the answer it gets from the server. It's the Azure DNS server that's in question here. E g, you'll get the same server answer from “dig” or “hostname” or “ping” or whatever tool and library you use, as long as it talks to the same server.

There's also a question of whether this answer will be visible outside the Azure datacenter (e g, through public DNS servers like 1.1.1.1 or 8.8.8.8) or only within the Azure network.

Just to clarify, the machine I am issuing the getaddrinfo() query from is not within the Azure datacenter, it's my local home machine.

Somewhat curiously, issuing a ping on windows returns a “could not find host” error (it doesn't report trying to ping 255.255.255.255 for the given host name).

This has an added wrinkle that I also have the same server application I'm trying to reach on the VM running locally as well, so it was a fun hour trying to figure out why I was getting duplicate responses from my local address (which was what the broadcast was sending to) as well as the expected loopback address. So I can't rely on not being able to connect, as this can validly also be running locally.

In any case, filtering out broadcast address results should work fine. Just a curious result I had never come across before.