In an ideal world, we could avoid it. With what we have, which includes things like process controllers running NFS using ip address for authentication, we are stuck with it for now. If we control the DNS, then names are equivalent to ip address. With ingress filtering, we can ensure that at least a source is onsite. True, we could have onsite spoofing, or MAC spoofing come to that, and certificate-based authentication could be used on modern equipment, plus we can firewall the old stuff to be more secure. But even implementing client-side certificates in HTTP is painful, at least in end-user training if nothing else, so we still use netblock/rDNS access control to semi-private web resources. Tor has a very small membership compared to the total user base. Facebook users seem quite willing to sacrifice privacy to run apps like "what kind of animal are you?". But I digress. If users are on our network and want our help debugging their network problems, they'd better be using an identifiable endpoint. DNS may not be secure, but it's convenient, widely deployed, and well-understood. Perhaps a bad example. But we whitelist some partners, on the basis that most people would rather get 50 spams than lose one important email. and some of that is based on the resolved domain name of the last relay. Not all our partners (or ourselves) have implemented DKIM yet. Which I understand is the default state in Windows >= Vista Thank you for the comments and information, which are at least thought-provoking and useful.