Hi Warren!
> "instead of using the DNS infrastructure, .onion names functionally
> correspond to the identity of a given service, thereby combining
> location and authentication."
> to be very confusing.
> After a while I went and looked at the diff and saw that this used to be:
> ".onion names are hashes that correspond to the identity of a given service,"
>
> I'm guessing that you changed this because of some comment? Anyway,
> this is in the introduction section, and so I think a little more, um,
> introductory text would be helpful. Perhaps saying that they are
> hashes of the key, and functionally correspond to <handwave, handwave>
> ?
That's very observant of you; the reason it was changed away from specifics of
hashing-and-truncation are because the Tor project are currently in the process
of overhauling hidden services, and it's entirely possible that the next
mechanism may be substantially different - hence wanting to keep the
description abstract and forestall arguments that the (eventual) RFC might be
invalidated by evolution of technical details - the Tor Project will drive the
implementation details, not the RFC.
> Also:
> "In this way, .onion names are "special" in the sense defined by
> [RFC6761] Section 3; they require hardware and software
> implementations to change their handling, ..."
> I'm not really sure if this is completely true -- I agree that
> software implementations would need to change, but I don't see how
> *hardware* implementations would need to change -- largely because I
> don't actually understand the concept of a hardware implementation of
> the DNS / .onion resolution stuff. Sure, some CPE runs *software* that
> does DNS, and some hardware accelerators run some DNS stuff in FPGAs,
> but I still don't see this a "hardware" implementation.
> I'd suggest just making that be: "In this way, .onion names are
> "special" in the sense defined by [RFC6761] Section 3; they require
> implementations to change their handling, ..."
That's an interesting point which I shall bounce off Richard Barnes for my
clarity; my reading of the text was any device - software (e.g.: Browser) or
hardware (e.g.: printer, IPMI, wifi router, etc...) - which wants to resolve a
".onion" name, must create ".onion" differently and eschew DNS in favour
punting the connections to a Tor (SOCKS) server. QED.
> Also:
> Throughout the document you state that thingies should return
> NXDOMAIN. Personally I think that this is a well enough known term
> that it is fine, but it isn't really defined (hoffman-terminology only
> sorta, kinda does). I'd think having a "should respond with NXDOMAIN
> (RCODE 3 - Name Error)" (or 'Non-Existent Domain') the first time it
> is used would head off future comments....
Noted. Thank you. Thank you also for the extensive help. :-)
- alec
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
