I was under the impression that .homenet is handled entirely within the
DNS resolver of the Homenet router, which combines:
- an authoritative DNS server for .homenet;
- a hybrid mDNS proxy;
- a recursive DNS resolver for the rest of the namespace.
So far so good. The problem is a (largely hypothetical at this point)
stub resolver that wants to do DNSSEC verification of the results the
router gives it.
R's,
John
On the computers I know, the stub resolver is in one shared library and
the SOCKS proxy is in another. What's the difference?
The SOCKS library uses a completely different data transport (one that is
circuit-switched and layered over TCP), with very different capabilities
from the usual packet-switched transport.
Of course, but from the point of view of a SOCKS client, either way it
gives it a name and a port, and it gets back a two-way data stream. If
you don't happen to be using a web proxy or ToR, the SOCKS library does
essentially nothing.
Adding support for mDNS to the stub resolver makes no change to the way
the actual data is pushed around.
Sure it does -- the .local queries do one thing and the others do another.
Not unlike with SOCKS the .onion opens do one thing and the others do
another. But this is utterly tangential to the argument about resolvers
that might want to do DNSSEC validation of .homenet results.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
