Alexander Færøy:
Hey,
On 2020/05/15 16:36, Jeremy Rand wrote:
The Prop279 spec text is ambiguous about whether the target is required to be a .onion domain, but the implementations (TorNS and StemNS) do not have that restriction. TorNS and StemNS allow a Prop279 plugin to advertise acceptance of any domain suffix (haven't explicitly tried the root zone as an suffix, but if that doesn't work, it's a bug that should be easy to fix) and can resolve them to any result (e.g. an IP address, a .onion domain, or another DNS name a la CNAME).
In proposal #279 the subprocess passes the `RESOLVED` message to Tor once it is has completed a name look up. The `RESOLVED` message is defined as follows:
``When the name plugin completes the name resolution, it prints the following line in its stdout: RESOLVED <QUERY_ID> <STATUS_CODE> <RESULT> where QUERY_ID is the corresponding query ID and STATUS_CODE is an integer status code. RESULT is the resolution result (an onion address) or an error message if the resolution was not succesful.''Here the `<RESULT>` must be an onion address. We would have to change that, such that an IP address can be returned as well :-)
Hi Alex,
The ambiguity I was referring to is that while the section you quote does require that the result be a .onion domain, below it is this note:
Tor MUST validate that the resolution result is a valid .onion name. XXX should we also accept IPs and regular domain results???
Prop279 is clearly labeled as a draft, so this makes it appear that no decision was reached on whether the result should be required to be a .onion domain.
My opinion is that accepting non-.onion addresses as results is desirable (both because it's useful for the Namecoin use case and because it's useful for the DNSSEC use case that we're discussing).
Cheers,