3 ms·

From grandparent > So if you add your friend alice's PKEY in your local root as "alice", then you could resolve whatever in her zone as whatever.alice. This

by im3w1l 5y ago

From grandparent > So if you add your friend alice's PKEY in your local root as "alice", then you could resolve whatever in her zone as whatever.alice. This sounds very undesirable to me. The same address resolving to the same website for everyone is a useful property of the current system.

ascar 5y ago
Can't you do the exact same thing in DNS right now? If your configured DNS server returns a valid result you wouldn't check other DNS servers for other valid results. This is a desirable property for many companies that filter employee internet access from their internal network right on the DNS level.
immibis 5y ago
Yeah, but solving that means giving up human-readable names (like Tor) or giving up decentralization (like DNS)
southerntofu 5y ago
> The same address resolving to the same website for everyone is a useful property of the current system. That's already only guaranteed under the public root, which GNS intends to preserve: the situation would not change in this regard. I can already map "hn" to a well known HN IP address in my /etc/hosts: the only hurdles would come from my web browser sending the "hn" Host header (easily fixed) and trying to validate the remote TLS certificate for "hn" (less easily fixed). In this regard, GNS would be different in that i could delegate "HN" to a public key and not be bound to the IP suddenly changing under my feet. On a higher level, i would argue the difference is GNS by design empowers users to archive/publish records because they don't need to operate infrastructure for that. If you already have a domain name and are familiar with DNS, publishing records is not that hard: GNS would make it far easier because since the records live in the DHT you only need client UX to publish a zone, no need to configure a name server or to point your client configuration to a specific name server API.

by im3w1l 5y ago

ascar 5y ago

Can't you do the exact same thing in DNS right now? If your configured DNS server returns a valid result you wouldn't check other DNS servers for other valid results. This is a desirable property for many companies that filter employee internet access from their internal network right on the DNS level.

immibis 5y ago

Yeah, but solving that means giving up human-readable names (like Tor) or giving up decentralization (like DNS)

southerntofu 5y ago

> The same address resolving to the same website for everyone is a useful property of the current system. That's already only guaranteed under the public root, which GNS intends to preserve: the situation would not change in this regard. I can already map "hn" to a well known HN IP address in my /etc/hosts: the only hurdles would come from my web browser sending the "hn" Host header (easily fixed) and trying to validate the remote TLS certificate for "hn" (less easily fixed). In this regard, GNS would be different in that i could delegate "HN" to a public key and not be bound to the IP suddenly changing under my feet. On a higher level, i would argue the difference is GNS by design empowers users to archive/publish records because they don't need to operate infrastructure for that. If you already have a domain name and are familiar with DNS, publishing records is not that hard: GNS would make it far easier because since the records live in the DHT you only need client UX to publish a zone, no need to configure a name server or to point your client configuration to a specific name server API.