Actually, the function name safer_gethostbyaddr is a bit of an exaggeration. This extra check gives you a little bit of added confidence in the host name you've found. But DNS has a bunch of other problems that may allow attackers to inject bogus information. For instance, DNS queries are identified by a 16 bit value. Responses received for a DNS query are accepted as valid if they contain the same ID, and are ``consistent'' with the query.
Now consider the function above. What happens is that the intended victim (the host running the network service) sends a DNS query trying to resolve the client's IP address, which winds up at a DNS server controlled by the attacker. This provides the attacker with a lot of information: the UDP port from which the victim process is sending its DNS queries, and the 16 bit ID used in the query. In many implementations, this will have a close relation to the UDP port and ID used in the next DNS query by that process (the forward query). For instance, in many implementations the next query will simply reuse the same UDP port, and increment the ID by 1. This is all the attacker needs in order to assemble a fake response to the next DNS query - the forward lookup intended to check the validity of the DNS name returned by the attacker.
Let's walk through this step by step. The attacker connects to our network service from 192.168.4.4. Our network service performs a reverse lookup via the DNS, asking for the host name corresponding to this address. This opens a UDP socket bound to port 1234 on the victim host, and uses an ID of 5678 in the DNS packet. The query winds up at the DNS server controlled by the attacker, who responds saying that the address corresponds to scrooge.mcduck.com. He knows that our very next DNS query will be for addresses associated with the name scrooge.mcduck.com. So the attacker assembles a DNS response claiming that the IP address for scrooge.mcduck.com is 192.168.4.4, using an ID of 5679, and sends it to UDP port 1234 on the victim host. He sends the packet several times over an interval of several seconds to allow for variations induced by the network latency. Now the victim server formulates its query using the ID 5679, transmits it, and whap receives a UDP packet that looks like a valid response by all means and purposes. The packet says that scrooge.mcduck.com is indeed 192.168.4.4, so reverse and forward lookup match and the victim considers the name trustworthy.
This attack, which is called DNS Spoofing is obviously related to the fact that the relevant information can be predicted very easily. But make no mistake! Even if you design a clever algorithm that picks a random ID every time (as the OpenBSD developers did), you still don't buy yourself more than a little head start. With a network connection of 2 Mbps an attacker can easily send 65536 packets covering all possible IDs in half a minute, which is well within the timeout range of a DNS query.
There is an implicit assumption to this scenario, which is that the victim's forward query will actually go out as a DNS query to the world. This is not necessarily true, for instance if it finds scrooge.mcduck.com in the local NIS or LDAP directory. Likewise, if the local DNS proxy is authoritative for the mcduck.com domain, the forward query will not result in an external DNS query either, so the spoofed DNS responses will not have any effect either.