Lack of overview on the level of spec support by the DNS provider

[pawel-kow]

The spec has several optional features, also several versions with added functionality.
Right now it's hard for Service Provider to figure out what level of support a DNS provider offers.

[kerolasa]

The issue feels similar with 'how to find DNS provider contact info'
question recently. Perhaps the DNS provider json should have a link to
documentation, something like this:

{
    "providerId": "cloudflare.com",
    "providerName": "cloudflare",
    "providerDisplayName": "Cloudflare",
    "urlSyncUX": "https://dash.cloudflare.com/domainconnect",
    "urlAPI": "https://api.cloudflare.com/dns/domainconnect",
    "documentation": "https://developers.cloudflare.com/dns/reference/domain-connect/"
}

And the spec should instruct the DNS provider docs need to tell 1) how to
contact the provider and 2) what is the level of feature support, with all
the nitty-gritty details what a service provider can and should expect.

For example. Cloudflare will require "syncPubKeyDomain". And Cloudflare
will ask "logoUrl" content, that is copied to our data storage to ensure all
the data served by our UI is security reviewed (or to put that differently
extreme paranoia about cross-site scripting is in use).

[pawel-kow]

Interesting aspects.

For the discoverability of the supported features, maybe we should have those elements machine readible.
/settings end point kind of serves this purpose already. Example from OpenID Connect (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) shows that such an approach might be helpful.

It would be great to hear from more DNS providers whether the best way to go would be to go over the end-point:

• benefits: it's decentralised, can be even maintained without anyone knowing or having to manage
• downsides: for some "process related" information like contact email it is typically not the best idea to bury it in the technical service

An alternative, which was raised as an idea in the past (by Google if I remind well), was:
a) to create a DNS provider profile JSON definition
b) maintain a repository in GitHub with such metainformation

• benefits: it would be possible to render the website with DNS providers automatically
• downsides: it's centralised and can get outdated the same way as the website today