The specification currently says:

"To deactivate the DID document, the domain is deleted."

It would probably be better to have a way of deactivating the DID without necessarily deleting the domain name. Perhaps the following is better:

"the respective URI records are removed from the domain"

Or alternatively we could also introduce a special RR pattern that marks the domain name as a "deactivate DID".

I think if keys are stored in DNS based on a digest of the key which then also becomes part of the verification method id it would solve #3 as well. In signed documents you would include that key id and fetch exactly the single DNS record you need. I guess the key id could be supplied as extra metadata to the DID resolver which essentially resolves to a subset of the complete DID doc. It's an optimization but an important one I think.

Is this because DNSSEC isn't universally available yet?

I find this resolver very interesting,
I m wondering if it is still active ?
Regards

DNS queries have to be made for a specific RR, rather than retrieving "all" RRs in a zone and then filter them.

Therefore steps 3 and 5 in https://danubetech.github.io/did-method-dns/#resolve are a bit imprecise, and it may not be possible to just "retrieve all keys" with a single query.

Also, we have to make sure we have to be compliant with how the URI RR works (and we should reference RFC 7553 - https://datatracker.ietf.org/doc/html/rfc7553).

Compare to how section 3.1 on "Owner Name" is written here: https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/

The specification currently uses URI RRs.

• DNSSEC uses DNSKEY and other RR types.
• DKIM uses TXT RR types.
• URI RRs may not be widely supported (e.g. Gandi doesn't support them). OTOH this should probably be not the main concern when choosing which RR type is most appropriate; semantics and functionality should matter more than implementation support.

Zone files are an implementation detail of some DNS servers, but other DNS servers use databases instead of files.

The specification should therefore use generic terminology for this, e.g. "public resource records (on the authoritative servers for the domain)".

The specification currently says:

"All other RRs MUST be ignored during the DID document construction step."

This language may not be ideal, because wo don't really want to "ignore" other RRs (such as DNSSEC). Instead maybe something like the following is better:

"only URI RRTypes matching the above requirements must be used for construction..."

DNS supports multiple RRs with the same name, e.g. multiple _key1._did.danubetech.com. RRs.

The specification needs to define in such a case (possibly using "order" and "preference" fields).

The specification currently defines RR patterns for storing public keys, but it doesn't specify their verification relationships (authentication, assertionMethod, etc.).

Should there be an explicit pattern for specifying this, or should a default set of verification relationships be assumed (like e.g. in did:key)?

I.e. why is it needed, and who would use it in which situations.

Maybe also explain better what are its pros/cons as compared to did:web