On Thu, Aug 17, 2017 at 6:28 PM, Ted Lemon <mel...@fugue.com> wrote: > El 17 ag 2017, a les 18:22, Brian Dickson <brian.peter.dick...@gmail.com> > va escriure: > > 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. > > > It's hard to see how this is going to help. What we are trying to do > here is bypass DNS; now you are asking us to go through DNS to get the name > of a local resource and contact it. So really you've just increased the > attack surface. > > If you're trying to use "localhost", that means you're using some kind of name resolution, whether it be DNS, /etc/hosts, NIS+, or anything else. I'm suggesting that by using DNS, you can take advantage of what DNS has to offer, which includes potentially DNSSEC.
There is a bootstrap problem, in that the client might have to know something about its own name... In the use case, are you trying to bypass DNS because you don't trust it? That part isn't really clear. What are the assumptions that are being made, best case vs worst case, and which are known to be "guaranteed"? Is the server doing dynamic update to whoever its DNS authority is? Is DNSSEC an option (sometimes?) or not... etc. So, here's one model that might work. Put the "localhost" at the deepest part of the namespace, *below* the host name. I.e., if my name is fully.qualified.domain.name, then I "control" my own name and things below it, and do an update for " localhost.fully.qualified.domain.name". IFF that name exists, then the server is smart enough to be assumed to be listening on whatever IP address (v4 or v6) is registered, and the client can reasonably trust that. Using SRV at that point is maybe overkill, maybe not (depending on the trust model). Add DANE stuff if you really want to do some kind of validation, etc. Or use URI for getting off the IP stack, if "file:///" makes sense. I think someone should write up the problem statement, since it is possible that what you really want has nothing to do with localhost, and having the "let localhost" kind of presumes the solution before identifying the real problem... What are you actually trying to do, and why? Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
