>> The purpose of the domain name system is to name things. We have IP >> addresses and we want to refer to them using names. We do the same thing >> with mail domains, etc. > >That is not the sole purpose - we use DNS for keys, for time stamps, >for data of all kinds.
In a well designed system, names are only used to name things. >From the good old days, telnet and ftp are clear examples. After looking up the name in DNS, you don't need the name anymore. All you need are the addresses that were returned in the DNS lookup. SSH with SSHFP also has that property. Lookup the SSH fingerprint in the SSHFP record, lookup an address, connect, and verify the fingerprint. No need for the name after the lookup. (Storing other stuff in a naming system is not a problem, it is just a big distributed database). >From day one however, this principle was violated. SMTP does use the domain name after the name lookup. With the interduction of the http host header, http also violates this principle. With the introduciton of SNI, TLS violates it. However, SMTP, HTTP, and TLS have one in common, from the network point of view, the name is not used for routing. It is only later, at the application layer that the name is used again. It is here that .onion goes one step further. Onion 'names' are derived from public keys. So instead a name being independent of an address, the .onion name is the address. Unlike, TLS or SSH, where a network connection is set up and then the crypto runs on top of it, in TOR this all integrated. For good reason, however that make the .onion 'name' an address. >> In goes a name, out comes some lower level entity. >> >> In this context an onion address should have been an 'IN ONION', i.e, >> www.example.com might have an 'IN ONION' address for use with TOR. >> > >And that would also require special handling... Yes, but in a way that doesn't abuse the model. If an 'IN ONION' would be stored on the host as a 'struct sockaddr_onion' then all code can be cleanly adapted to support TOR hidden services. Instead of adding pattern matching hacks to name resolution. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
