spec out dnslink

[jbenet]

No description provided.

[da2x]

Some notes for discussion that may lead to a spec:

1. _dnslink. is a very bad and redundant name to hold the records. Yes, it’s a “link between IPFS and DNS” but no other service auto-discovery mechanism built on DNS include “DNS” in their record names. The final name should be based on the RFC 6763: DNS-Based Service Discovery standard instead (for a slew of very good technical and compatibility reasons). I suggest using _ipfs._udp.example.com (UDP in RFC 6763 means “any protocol” and not literally “UDP”).

2. The record consists of a one or more TXT records in this format: [<priority>] cid=/ipfs/<cid>, or exactly one TXT record of this format name=/ipns/<hash>. The existence of a name means any CIDs will be ignored. While multiple names is discouraged, clients should still handle this by selecting one at random. The selection decision must be cached for the duration of the DNS answer’s TTL.

3. The use of service discovery records outside the dedicated subdomain name is deprecated. There should only be one lookup required to reduce redundant lookups with the costs and performance penalties that comes from that. A subdomain can be delegated to another name server to allow segregating permission and stronger security of the DNS zone. A subdomain can also be forwarded to another record set sing a CNAME (as explored below). See RFC 6763 for a long list of reasons to do it this way

4. Recursive DNS-based IPNS name resolution is allowed but limited to one hop, but it is strongly discouraged. Avoid name=/ipns/b.example.com and use CNAMEs instead: e.g. CNAME _ipfs._udp.@ 1000 _ipfs._udp.b.example.com. CNAMEs are not limited in the number of hops as all the tedious work is handled by the user’s recursive DNS servers who’ll return (and cache the resolution chain correctly) the final canonical answer without the need for multiple DNS lookup requests.

5. It should be possible to specify multiple CIDs with separate TXT records for redundancy with a defined behavior. This is especially important when you update a record with a new CID and that CID isn’t yet assumed to be well-distributed in the network. TXT records don’t have a priority field in DNS, so an integer number in the record itself is used. E.g. 10 cid=/ipfs/<cid>. A record may optionally not have a number and will default to a priority of 10 (this allow another record to be created later with a lower score). The TXT record with the highest priority (lowest number; following existing DNS conventions) should be considered the highest priority. This allows for informed selection by clients and it allows clients to fallback to a previous version of a resource (if so desired by the domain holder). Records with the same priority score are equivalent and one should be chosen at random. Clients should try to obtain the top priority CID first and fallback to lower priority CIDs second. Clients may use concurrent requests for up to three top CIDs (using the previously defined sorting) and return whichever resource they can obtain first (like RFC 8305: Happy Eyeballs v2). Clients may abort retrieval attempts for higher priority CIDs when they’ve successfully obtain a lower priority CID, or they may continue to attempt to fetch it and return it on subsequent request; allowing for timely resource retrieval and graceful upgrades of resource.

6. IPFS clients should generally not cache DNS responses (with a few exceptions) but leave that up to dedicated software. Most users will already have well-behaved layers caching DNS responders provide by default by their operating system, edge network gateway, and recursive DNS service provider. IPFS clients may choose to cache negative DNS answers (failed lookups) with their own timeouts but no more than 24 hours. Clients must cache their random selection decision when encountering multiple names in TXT records.

7. Clients must only perform DNS service discovery on fully qualified domain names. See go-ipfs/pull/5950.

8. The use of DNSSEC is strongly encouraged.

[Stebalien]

Thanks for writing these up! A DNSLink spec would be awesome.

I suggest using _ipfs._udp.example.com (UDP in RFC 6763 means “any protocol” and not literally “UDP”).

I don't think DNS-SD is a fit here. It was designed for finding machines providing services and specifies a PTR+SRV+TXT triple that requires an IP and port (A/AAAA record and an SRV record). We don't want any of that; we're just using a separate subdomain to avoid cluttering up the main domain with TXT records.

We do use DNS-SD for advertising ipfs nodes on the local network. Even there it's annoying to work with as everything we do is multiaddr based but this spec assumes that every service is running on an IP/port.

The record consists of a one or more TXT records in this format: [] cid=/ipfs/, or exactly one TXT record of this format name=/ipns/. The existence of a name means any CIDs will be ignored. While multiple names is discouraged, clients should still handle this by selecting one at random. The selection decision must be cached for the duration of the DNS answer’s TTL.

Are you trying to handle the issue described here: ipld/specs#19? Yeah, I'm not sure what the right solution is.

Note: I wouldn't use cid as _dnslink should work with arbitrary paths (recursively). I'm also not sure if fixing this is in-scope for DNSLink.

The use of service discovery records outside the dedicated subdomain name is deprecated. There should only be one lookup required to reduce redundant lookups with the costs and performance penalties that comes from that.

I like the idea but some users may not be able to create sub-domains.

Recursive DNS-based IPNS name resolution is allowed but limited to one hop, but it is strongly discouraged.

I'd just discourage it and set an overall recursion limit. I'm wary of one-off semi-arbitrary rules like this.

On this topic, does DNSLink even support CNAMEs right now? It should.

[da2x]

(Typed on mobile. Please excuse any mistakes.)

we're just using a separate subdomain to avoid cluttering up the main domain with TXT records.

No, you're not. The only documentation for DNSLink on a subdomain specifically mentioned many of the same reasons and motivations as the DNS-SD RFC. (Subname zone delegation, zone security, etc.) Additionally, it allows you to use CNAMEs. For example: you could have a TXT record on _ipfs.www.example.com and a CNAME pointing to that domain from _ipfs.example.com, or point both of them to _ipfs.customername.pinningservice.example.net.

Any way, I'd like to change the DNSLink zone name. If shouldn't refer to DNS (reduntant) and it really should refer to IPFS (or IPLD, IPNS, or whatever the correct addressing space is called.)

Are you trying to handle the issue described here: ipld/specs#19? Yeah, I'm not sure what the right solution is.

That wasn't really what I was going for. My own experience is that new content, meaning things that you've just published/added to an IPFS mode can be really slow to fetch. Nobody likes slow services. This proposal is supposed to allow clients to fetch precious/older versions as a fallback after you've updated the pinned IPFS CID in DNS. The new hash may take some time to become available and the old hash is more likely to be broadly distributed and more available in the network already. So it's a graceful fallback to an older version, at the domain owner's discretion. To ensure availability, I've had to first add to nothing to a couple of IPFS nodes, wait an hour, and then update DNS. Allowing for fallback to the previous version would mean I could deploy faster and some clients would get the new content as soon as possible. My IPFS nodes could all crash while they were the only nodes that hosted the new content: so allowing clients to still use the old versions from other distributed norms that may have a copy is good for availability.

I like the idea but some users may not be able to create sub-domains.

Then they're unlikely to be able to add any DNS records at all. It's not worth the performance cost for all domains forever to support two schemes. People can move their authorities DNS and there are free authorative services out there. You can even run your own authorative DNS service.

I'd just discourage it and set an overall recursion limit. I'm wary of one-off semi-arbitrary rules like this.

I'm all for discouraging it but allowing one hop (recursion limit of one) allows for some flexibility. CNAMES can have as long chains as the upstream recursive resolver wants to handle (I believe most resolve upwards to around 30 before they give up).

On this topic, does DNSLink even support CNAMEs right now? It should.

go-ipfs does. Or rather, all recursive and stub resolvers do it so go-ipfs just get the final canonical answer from the system's resolver and is happily unaware of any complexity involved with resolving the CNAMEs.

[da2x]

For clarification on what is meant with zone delegation: you can give another name server responsibility of a subdomain as a separate zone. Instead of updating the entire root zone and giving access to write to the root to a system responsible for updating IPFS records, you can use a subdomain as a separate zone with separate access controls. Platforms like Azure DNS allow the creation of sub domain/zone API keys, for example.