Sorry, but point of order: We have a solution that entails a minimal change from the current state of the art and minimal incremental security risk. Let's not re-open fundamental questions, please.
On Thu, Aug 17, 2017 at 6:22 PM, Brian Dickson < brian.peter.dick...@gmail.com> wrote: > 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 > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
