Add success state to redirect_uri to validate changes

[MrExcitingDigits]

Problem:

Currently, the Domain Connect protocol has no method of confirming if changes were successful to the Service Provider.

Possible Solution

One solution (for the sync flow using redirect_uri) could be to have the DNS Provider append a success_state query parameter and a sig parameter that is asymmetrically signed. This way, a Service provider can confirm that the changes were made successfully and trust that it was the DNS Provider who appended the parameter by checking the sig with a public key.

Benefits

• Service Providers won't have to wait for DNS checks, but instead can trust the DNS provider using the query parameters of the redirect_uri
• DNS Providers won't have to answer redundant DNS queries by the Service Provider after they have just applied the template
• End users can skip wait times and manual checks for DNS. This depends on how Service Providers want to treat the response. (They could either trust that propagation will happen soon and verify it later during regular checks, or force users to wait for propagation.)

[pawel-kow]

Current state of things:

• for the async flow the request is n/a -> here the low returns with a code, which is being exchanged for a token. The actual DNS apply calls are backend-to-backend so the success is known by return code
• for the sync flow:
  • it there is an error the flow returns to redirect_uri with an error parameter and an optional error description (like in OAuth)
  • if there is no error the flow returns to redirect_uri without an error parameter which shall indicate a success
  • in both cases there is a state parameter which links the request with the return request. So service provider with this parameter can also assure the call returned from a valid request

So for me the requirement is pretty much good covered, but if there are some wrong implementations by DNS providers please mention them @MrExcitingDigits, because this seems to me not to be a spec issue.

Also to the last part with signature. In my eyes there is enough of mechanism in place to assure the flow response comes in a context of a valid request.

• if even more assurance is needed - async flow can be an option
• but I would discourage using Domain Connect response for a more assured signal rather than that the particular flow was successful. Please note that _domainconnect record may be configured to a server, which is maybe not yet delegated, which means that use-cases as proof-of-dns-control cannot be done just based on domain connect response. DNS must be checked all times.

[MrExcitingDigits]

The problem with relying on the state parameter is that it is visible even before going through the UI flow (the state parameter is part of the link to initiate the flow). This means a user could simply copy the state parameter from the link, then skip straight to the redirect_uri and paste the state param. Even the spec says Service Providers can not assume success from this. This is why I saw the need for a sig similar to how the Service Providers provide a sig.

The main goal we're trying to achieve is to get our users to be able to go from their DNS provider straight to the domain dashboard. However, we cannot let them through without some kind of confirmation that the operation actually succeeded and the user didn't simply paste the state param with the redirect. Currently, we have to bring users back to Manual DNS so they can keep attempting DNS check since the DNS Provider takes time to apply the records after the redirect. Hopefully, we can find some way to trust the redirect_uri so we can skip this check.

[alinconstantin]

DNS providers will add the records (internally) and call your redirect Uri, that doesn't mean the records are actually visible on the Internet and the config applied is actually usable, it may take 10-15 min for that - you still need to make DNS queries to verify it. Don't just trust the redirect Uris...

[MrExcitingDigits]

The bigger problem here is that there is really no way to let the user know whether the flow was successful or not. Because of this, we have no choice but to redirect customers straight to manual configuration and say "if it worked, then it should show up after a little bit, if not, then it probably didn't work". To me, this destroys part of the beauty of Domain Connect.

If we had some way of receiving confirmation from the DNS Provider that the flow was successful, then we can at least reassure the customer that everything went well and they just have to wait for the DNS check to pass. Without getting feedback from the DNS Provider, we can't say this to users and it's really a mystery to both the user and the Service Provider until the DNS fully propagates (which can take hours).