The discussions about localhost (and 127.0.0.1 and ::1) have ben very enlightening.
However, I wonder whether the desired use case -- reliably establishing a connection to a host, based on information in DNS -- might be more securely/reliably solved using other mechanisms? Using "localhost" is basically making unilateral assumptions (and using ::1 or 127.0.0.1 equally so). I think the reliability, and possibly the security, are better achieved with bilateral mechanisms. E.g. If the specific use case is a client trying to talk to a server, on a particular port and protocol, then a more robust method of determining that the server offers such a service, would be using SRV or URI records. When the client, resolver, authority server, and service-server may not be tightly coupled, it might require additional enhancements, such as client subnet (or similar), to ensure the appropriate answer is given. The specific value returned to the query might be 127.0.0.1, or might be some other address; the main thing is that the address is deliberately associated with a service that wants the client to use, and presumably the service knows that the client is on the same host. Sorry if this isn't as clear as I intended - basically, what I'm saying, is that the answer might not even be an IP, protocol and port, but might even be a "file:///" URI, for a named pipe, which avoids the whole IP stack. Hope this provides useful ideas which point away from localhost per se. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
