Domain Connect for self-hosted services

[anderspitman]

Hi @arnoldblinn, I just finished reading your article and the spec. I was very excited to discover Domain Connect this morning. It is in spirit almost exactly what I've been looking for for over a year. I've even spent some time recently implementing what is essentially the synchronous flow. I have a few questions.

My primary goal is to make data ownership and self-hosting accessible to more people. I don't think the average person should need to understand things like TLS certs and DNS records in order to securely self-host a service on a domain they control. LetsEncrypt mostly solves the TLS cert issue. I think something like Domain Connect is the solution to DNS complexity. Here's a concrete use case.

I have an open source project, boringproxy, which is essentially a combination of a reverse proxy with SSH tunneling (think ngrok or CloudFlare Tunnel. I maintain a list of similar services here) and auto TLS built-in. Once running, it presents the user with a simple web UI that lets them map domain names to ports running on specific machines, even if those machines are behind NATs etc, and tunnels requests. This works quite well, but the main missing piece is DNS. Currently the user has to set DNS records manually. Typically this would involve setting a wildcard record *.example.com pointing to the public IP of their boringproxy server. When they start the server they choose a subdomain such as admin.example.com which is used for the UI, and when they create new tunnels they name them things like tunnel1.example.com, etc.

What I want to be able to do is integrate boringproxy with DNS providers to automate this process. In my mind the ideal flow would be:

1. User starts boringproxy server
2. The server detects its public IP and asks the user if they want to integrate with a DNS provider
3. If yes, a list of supported DNS providers is shown
4. The user selects their provider
5. A link is printed which takes the user to a consent page which lets them select a domain/subdomain/wildcard domain to use
6. If the user consents, DNS records are set
7. The user is redirected to the public IP address with the selected domain in the URL
8. The boringproxy server uses the selected domain to perform a LetsEncrypt flow and redirects the user to the HTTPS admin page.
9. The user is able to create tunnels. If a wildcard was selected in the initial flow, they can use that. Or they can perform more DNS flows to add additional domains/subdomains.

With this is mind and after reading the Domain Connect spec, I have the following questions/concerns:

1. Requiring template publishing seems overly burdensome for this use case. Would every single user of boringproxy have to integrate with DNS providers? Or is there a way I as the project maintainer can register a template usable by anyone running a boringproxy server? In my implementation I simply allow anonymous requests, with the requested records URL-encoded in the request. It's then up to the DNS provider to warn the user of the implications of the suggested changes, and to provide them with the "phishing warning" etc.

2. It would be nice if the DNS provider allowed the user to select a domain/subdomain on the consent page. So the service provider would simply present a list of supported DNS providers, and the user would select the one they use, and it could then be passed back to the service in the URL on redirect. This way the user doesn't have to type in the domain/subdomain. Is this possible with Domain Connect?

3. Specifically for the functionality of boringproxy where users create tunnels on demand, is it possible to use a single template to facilitate changing an arbitrary number of hosts? I feel like this has to be possible, but it was a little unclear after reading this section.

Thank you for answering any of these questions that you can, and sorry it's so long!

[arnoldblinn]

Couple of things on this. First, I'm not super active on Domain Connect anymore. I created this standard while I was Chief Architect at GoDaddy, but I left this company 18 months ago and am working in a different area of tech now. Pavel (who believe gets these mails) might have more to say. You can also join the Domain Connect Slack (instructions at domainconnect.org) and have a dialog about this there. This being said, I can answer most if not all the questions below. The protocol is optimized for a Service Provider that wants to enable a specific service for a customer. The Service Provider creates a template once, and onboards it with the DNS Providers. End users do not deal with templates. The Service Provider collects the domain name. There is not an option to ask for the domain name at the DNS Provider. This isn't fundamental to the protocol; but is fundamental to the user flow. Why do I say that? The domain name selected is passed to the DNS Provider in the URL when linking from the Service Provider. In theory you could hit a page at a DNS Provider and ask them to select a domain they own there after logging in. But for most use cases the Service Provider also needs to know this domain name, and passing this back isn't the most reliable thing to do in loosely coupled web flows. As for "arbitrary number of hosts". This is a complicated subject that confuses some people. In fact, I'll back track. The Service Provider typically collects the domain name and <optional> sub-domain name. This is used when applying the template. Say you have a website for shopping. I own the domain example.com, and want to run my store on shop.example.com. I call the DNS Provider with domain=example.com&host=shop. The template would set the A record to the appropriate IP for shop.example.com. If you want to allow the user to apply the template to shop, foo, bar, or even * you would simply pass in domain=example.com&host=<the right value>. I believe * works. I can't remember. But you WOULD need to call the DNS Provider for each sub-domain (host) you want to configure. Some providers have asked to setup their template to allow for a variable in the host name. In general the DNS Providers don't like this. Especially with the asynchronous flow. Because it would allow the Service Provider to overwrite arbitrary host names in DNS. And this makes telling the user about conflicts difficult (for synchronous flows) or impossible (for asynchronous flows). The section you refer to has to do with this. Long story short, you smell like a simple Service Provider. They visit you, type a domain name, type a host name, and you do the standard protocol. You discover the provider and link to them. Your template sounds simple. Oh; thanks for fixing the typos in the spec. From: Anders Pitman ***@***.***> Sent: Thursday, December 16, 2021 11:18 AM To: Domain-Connect/spec ***@***.***> Cc: arnoldblinn ***@***.***>; Mention ***@***.***> Subject: [Domain-Connect/spec] Domain Connect for self-hosted services (Issue #64) Hi @arnoldblinn<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farnoldblinn&data=04%7C01%7C%7Cb029141f46ad479bbe2008d9c0c8ba63%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752790616942598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=XdIn7dSIEnfLZ4L%2FC4%2Fp9kPeKz%2FvvJPAaeCLSer3Bv0%3D&reserved=0>, I just finished reading your article<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.godaddy.com%2Fengineering%2F2019%2F04%2F25%2Fdomain-connect%2F&data=04%7C01%7C%7Cb029141f46ad479bbe2008d9c0c8ba63%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752790616952546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lFBl7q7DRzB4ZkJ%2FGMhNKQ3jGmj%2F1dD0jLZz68%2FdcG8%3D&reserved=0> and the spec. I was very excited to discover Domain Connect this morning. It is in spirit almost exactly what I've been looking for<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnews.ycombinator.com%2Fitem%3Fid%3D23761788&data=04%7C01%7C%7Cb029141f46ad479bbe2008d9c0c8ba63%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752790616952546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LAkS9Bi8fTyCNbOeb9vYyyJIFesfJB3kovPIEPm1zQE%3D&reserved=0> for over a year. I've even spent some time recently implementing what is essentially the synchronous flow. I have a few questions. My primary goal is to make data ownership and self-hosting accessible to more people. I don't think the average person should need to understand things like TLS certs and DNS records in order to securely self-host a service on a domain they control. LetsEncrypt mostly solves the TLS cert issue. I think something like Domain Connect is the solution to DNS complexity. Here's a concrete use case. I have an open source project, boringproxy<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fboringproxy.io%2F&data=04%7C01%7C%7Cb029141f46ad479bbe2008d9c0c8ba63%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752790616962502%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KCj9RTbdWdTAe5widFkNTFsHoEUMYHeNxSt3ZeRxi%2Fg%3D&reserved=0>, which is essentially a combination of a reverse proxy with SSH tunneling (think ngrok or CloudFlare Tunnel. I maintain a list of similar services here<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fanderspitman%2Fawesome-tunneling&data=04%7C01%7C%7Cb029141f46ad479bbe2008d9c0c8ba63%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752790616962502%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=U9I512bcFq4Y97tBmBoRDN6bloRJIDmt1grytxQrMZQ%3D&reserved=0>) and auto TLS built-in. Once running, it presents the user with a simple web UI that lets them map domain names to ports running on specific machines, even if those machines are behind NATs etc, and tunnels requests. This works quite well, but the main missing piece is DNS. Currently the user has to set DNS records manually. Typically this would involve setting a wildcard record *.example.com pointing to the public IP of their boringproxy server. When they start the server they choose a subdomain such as admin.example.com which is used for the UI, and when they create new tunnels they name them things like tunnel1.example.com, etc. What I want to be able to do is integrate boringproxy with DNS providers to automate this process. In my mind the ideal flow would be: 1. User starts boringproxy server 2. The server detects its public IP and asks the user if they want to integrate with a DNS provider 3. If yes, a list of supported DNS providers is shown 4. The user selects their provider 5. A link is printed which takes the user to a consent page which lets them select a domain/subdomain/wildcard domain to use 6. If the user consents, DNS records are set 7. The user is redirected to the public IP address with the selected domain in the URL 8. The boringproxy server uses the selected domain to perform a LetsEncrypt flow and redirects the user to the HTTPS admin page. 9. The user is able to create tunnels. If a wildcard was selected in the initial flow, they can use that. Or they can perform more DNS flows to add additional domains/subdomains. With this is mind and after reading the Domain Connect spec, I have the following questions/concerns: 1. Requiring template publishing seems overly burdensome for this use case. Would every single user of boringproxy have to integrate with DNS providers? Or is there a way I as the project maintainer can register a template usable by anyone running a boringproxy server? In my implementation I simply allow anonymous requests, with the requested records URL-encoded in the request. It's then up to the DNS provider to warn the user of the implications of the suggested changes, and to provide them with the "phishing warning" etc. 2. It would be nice if the DNS provider allowed the user to select a domain/subdomain on the consent page. So the service provider would simply present a list of supported DNS providers, and the user would select the one they use, and it could then be passed back to the service in the URL on redirect. This way the user doesn't have to type in the domain/subdomain. Is this possible with Domain Connect? 3. Specifically for the functionality of boringproxy where users create tunnels on demand, is it possible to use a single template to facilitate changing an arbitrary number of hosts? I feel like this has to be possible, but it was a little unclear after reading this section<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDomain-Connect%2Fspec%2Fblob%2Fmaster%2FDomain%2520Connect%2520Spec%2520Draft.adoc%23691-variables-and-hostname-in-template&data=04%7C01%7C%7Cb029141f46ad479bbe2008d9c0c8ba63%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752790616962502%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wbIVnN4zyH6PQwLgD%2BHLmYlJVQEGyqCnbD2yRWgLj0A%3D&reserved=0>. Thank you for answering any of these questions that you can, and sorry it's so long! - Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDomain-Connect%2Fspec%2Fissues%2F64&data=04%7C01%7C%7Cb029141f46ad479bbe2008d9c0c8ba63%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752790616972450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C1szxkcuqmOkpH7%2B5hVAyrLPnaRukg2RlO%2B4KAS0QEk%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACGGDPFVMWBW73JY23VJ6O3URI3NHANCNFSM5KHDDE5A&data=04%7C01%7C%7Cb029141f46ad479bbe2008d9c0c8ba63%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752790616972450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nAmP%2BL450pl7hpGGrA7JZY1dVE0p8AdJLk8Bplm0Bto%3D&reserved=0>. Triage notifications on the go with GitHub Mobile for iOS<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7C%7Cb029141f46ad479bbe2008d9c0c8ba63%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752790616982406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yx9sOESyTeVGIzGqvRHy6pE2Kgj36SaDE3jz57aJxSA%3D&reserved=0> or Android<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7C%7Cb029141f46ad479bbe2008d9c0c8ba63%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752790616982406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=biOM0SnktJuIp8woQq%2FYdVVdwz0k62qHxjFoC5jtax0%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[anderspitman]

@arnoldblinn, thank you for the detailed answers! I think my concerns are reduced to 2 questions:

1. Sounds like I can create a single template for boringproxy, and anyone who hosts their own boringproxy server can use the synchronous flow (assuming async would require OAuth credentials which I can't share)?

2. Why is there no provision for anonymous synchronous requests, ie without template required or even some "universal" templates for simple actions such as setting a single A Record? It seems like tying everything to templates with specific provider IDs could actually make phishing worse, because when people see the name and/or logo of the provider they assume it's valid. I understand the phishing warnings and that signing requests solves this but in that case why not support fully anonymous requests with phishing warnings? You can't trust anything in the request so it seems like you shouldn't be showing them the logo or provider ID anyway, at which point why is a template necessary?

[arnoldblinn]

Didn't realize you were an installed application and not a service. Yes, you would need to use the synchronous flow for this. Async is out of the question, as there are shared secrets between the DNS and Service Providers. You can create a single template for your service and mark it as "shared". This allows also allows the actual provider to pass in their name for display on the confirmation page. Phising is a huge concern for sure. There are two mitigations. You can use digital signatures. On the surface this is tricky with a shared template and multiple providers. But you could provide a central service with an API to do the signing. It would require you to trust your providers though. This is what resellers of O365 and GSuite do. You could set warnPhising. Could there be a universal template that sets an A Record? I suppose. The DNS Provider would have a hard time setting telling the user the "what" is being enabled. You could pass this in on the query string. But this is a massive slippery slope. Is an A record enough? How about a cname for www for websites? Where do you stop? Plus having templates that set random IP addresses are prone to phising on their own. And what about mail providers? The DNS Providers are more comfortable having templates narrow in scope; not general purpose. From: Anders Pitman ***@***.***> Sent: Thursday, December 16, 2021 1:19 PM To: Domain-Connect/spec ***@***.***> Cc: arnoldblinn ***@***.***>; Mention ***@***.***> Subject: Re: [Domain-Connect/spec] Domain Connect for self-hosted services (Issue #64) @arnoldblinn<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farnoldblinn&data=04%7C01%7C%7Cd77a3594771b4739ff8708d9c0d9b16c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752863489845650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EnJeUweW0bFuH%2BwftTzpoEO0xhCXwaLBdZwgehMGmcM%3D&reserved=0>, thank you for the detailed answers! I think my concerns are reduced to 2 questions: 1. Sounds like I can create a single template for boringproxy, and anyone who hosts their own boringproxy server can use the synchronous flow (assuming async would require OAuth credentials which I can't share)? 2. Why is there no provision for anonymous synchronous requests, ie without template required or even some "universal" templates for simple actions such as setting a single A Record? It seems like tying everything to templates with specific provider IDs could actually make phishing worse, because when people see the name and/or logo of the provider they assume it's valid. I understand the phishing warnings and that signing requests solves this but in that case why not support fully anonymous requests with phishing warnings? - Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDomain-Connect%2Fspec%2Fissues%2F64%23issuecomment-996201614&data=04%7C01%7C%7Cd77a3594771b4739ff8708d9c0d9b16c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752863489855611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hEMptwMBFPH6CtBXOYho2nuAEjRNxAF%2BW4rjKQKa0y8%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACGGDPERJ2BVQIRGBTRXLDLURJJUTANCNFSM5KHDDE5A&data=04%7C01%7C%7Cd77a3594771b4739ff8708d9c0d9b16c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752863489865568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=idAlQgjeNjD2DCebHeFpc5JFAV5jIpd%2BDRKl9G0rp1Y%3D&reserved=0>. Triage notifications on the go with GitHub Mobile for iOS<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7C%7Cd77a3594771b4739ff8708d9c0d9b16c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752863489865568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yfYRjdbK2%2Biw95855RSpgXzDp%2BOF3th3P7U%2BTRp6TMM%3D&reserved=0> or Android<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7C%7Cd77a3594771b4739ff8708d9c0d9b16c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752863489875512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=76egPerK7aAsZbbqIgWuFSQzj04I7QKvgMKEzKOanUc%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[pawel-kow]

Worth considering, although not perfect, is the approach we took with DynDNS client.
So it's in fact async flow, with confidential client and known predefined secret.
Public client with PKCE would have been better, but this was easier to do at a time as no upgrades needed to the auth servers.

More details:
https://github.com/Domain-Connect/DomainConnectDDNS-Windows

There is also a Python client
https://github.com/Domain-Connect/DomainConnectDDNS-Python

In fact if only A/AAAA records are needed one could piggyback on the same template... it's just OAuth in the end of the day.

[arnoldblinn]

Good catch. I'm rusty. From: Pawel Kowalik ***@***.***> Sent: Thursday, December 16, 2021 1:42 PM To: Domain-Connect/spec ***@***.***> Cc: arnoldblinn ***@***.***>; Mention ***@***.***> Subject: Re: [Domain-Connect/spec] Domain Connect for self-hosted services (Issue #64) Worth considering, although not perfect, is the approach we took with DynDNS client. So it's in fact async flow, with confidential client and known predefined secret. Public client with PKCE would have been better, but this was easier to do at a time as no upgrades needed to the auth servers. More details: https://github.com/Domain-Connect/DomainConnectDDNS-Windows<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDomain-Connect%2FDomainConnectDDNS-Windows&data=04%7C01%7C%7C328b6b1aedb54881611808d9c0dcdae4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752877058621478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=h6OJooH40uAnBm53NXSOHX%2FxHmO%2FPSGyoPm87PosOYU%3D&reserved=0> There is also a Python client https://github.com/Domain-Connect/DomainConnectDDNS-Python<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDomain-Connect%2FDomainConnectDDNS-Python&data=04%7C01%7C%7C328b6b1aedb54881611808d9c0dcdae4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752877058631452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ROxUz9CyNwUT%2FpKT08%2FnK0Brmr2ot1D0242G%2FuZtcxg%3D&reserved=0> In fact if only A/AAAA records are needed one could piggyback on the same template... it's just OAuth in the end of the day. - Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDomain-Connect%2Fspec%2Fissues%2F64%23issuecomment-996215488&data=04%7C01%7C%7C328b6b1aedb54881611808d9c0dcdae4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752877058631452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Q7ftCpSXZMBLuCl3dUUA5ENEqWgTFNTfYEzoLQT%2FSjI%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACGGDPHWREHSJTQ3XFY36FLURJMJPANCNFSM5KHDDE5A&data=04%7C01%7C%7C328b6b1aedb54881611808d9c0dcdae4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752877058641404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SdBemD%2BuFkLoWqM3EKqd%2F7cnPC7GSoEqBKLBJC6eyLY%3D&reserved=0>. Triage notifications on the go with GitHub Mobile for iOS<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7C%7C328b6b1aedb54881611808d9c0dcdae4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752877058641404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pFJecLxRWuhOHBVptVBhPEMR2wQ%2F8kjEwOTTvzu2qfc%3D&reserved=0> or Android<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7C%7C328b6b1aedb54881611808d9c0dcdae4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752877058651352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=65TrcBn2sQXbNVDBnxb%2BEpgbO%2FhGCb3MqB14YBXGhi0%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[anderspitman]

@arnoldblinn thanks again. I guess I just don't see the difference between showing a phishing warning with a pre-defined template, and showing a phishing warning with a template you pass in the query itself (anonymously). You can't trust the request in either case. And I would argue that showing the service provider name and/or logo in this case is actually worse for security.

Requiring that all templates be predefined and onboarded seems like it would slow adoption and make it much more difficult for small players and open source projects to get involved. I would try implementing Domain Connect today but knowing that I have to get at least one DNS provider to onboard my template makes me wonder if it would take weeks of back-and-forth with me trying to debug my template. And there's no guarantee any of them would choose to onboard it at all.

@pawel-kow thanks for the suggestion. I'm not sure I see the advantage. The synchronous flow should be fine for my project. It looks like the phishing warning is required either way since the secret is public. I feel like your suggestion that I piggyback on the DynDNS template further illustrates my point. If it doesn't matter that I impersonate someone else's service, why are predefined templates required in the first place?

I'm not trying to be contrary. There's a good chance I'm just missing something here, and I want to understand.

[anderspitman]

@arnoldblinn I appreciate your participation so far but recognize that you've mostly moved on from this project. I would value your thoughts moving forward, but please don't feel any obligation.

As a followup, I just bought a domain from Godaddy and built a simple Domain Connect URL using the example template1.

It works as intended (kudos on making an elegant API), but this is what I see:

It really seems to me that the use of a predefined template is mostly detrimental as implemented here. Even though warnPhishing is set true in the template, I don't see any indication that there's anything for the user to be concerned about here. What's even more concerning, the inclusion of "Stateless Hosting Primary" and "Example Domain Connect Service" show that the user could easily be mislead into believing they are using a completely different service than indicated.

To be clear, I'm not saying that service provider registration is a bad idea. But I'm advocating two things:

1. Service provider registration should be optional. Anonymous requests with inline templates should be possible, but clearly marked as untrustworthy.
2. Any flow that displays information from a template to a user must be signed.

Thoughts?

Also @arnoldblinn, it appears that host=* does not work, for Godaddy at least.

[arnoldblinn]

GoDaddy's implementation fell short on the "warnPhishing" front. This likely fell off their bucket as I left the company. I'm copying someone there that could address this. As for the names of the templates; the ones for the example service are sort of lame. But they are examples. As for "all templates should require signing"; in general most do sign. However, if a template is fully scoped, this isn't necessary. If my template is simply "set my A record to a fixed IP", someone that visits the DNS Provider really couldn't be misled. They apply the template, it would point to the service behind the template. Signatures are tricky to get right, so for some providers we don't burden them. From: Anders Pitman ***@***.***> Sent: Thursday, December 16, 2021 3:31 PM To: Domain-Connect/spec ***@***.***> Cc: arnoldblinn ***@***.***>; Mention ***@***.***> Subject: Re: [Domain-Connect/spec] Domain Connect for self-hosted services (Issue #64) @arnoldblinn<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farnoldblinn&data=04%7C01%7C%7C14d6c0414212430ad84c08d9c0ec0dde%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752942345668841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=D1ODfE2V5Y5NyskRBwBw5406Y8%2FOAE0QNgrGKkcLVxY%3D&reserved=0> I appreciate your participation so far but recognize that you've mostly moved on from this project. I would value your thoughts moving forward, but please don't feel any obligation. As a followup, I just bought a domain from Godaddy and built a simple Domain Connect URL using the example template1<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDomain-Connect%2FTemplates%2Fblob%2Fmaster%2Fexampleservice.domainconnect.org.template1.json&data=04%7C01%7C%7C14d6c0414212430ad84c08d9c0ec0dde%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752942345678787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Sxl08ElmNTbDQPpHR1%2BN%2FLOCO%2FKWeW%2F3ew6WudLlPaU%3D&reserved=0>. It works as intended (kudos on making an elegant API), but this is what I see: <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuser-images.githubusercontent.com%2F7820200%2F146462843-c23ae7e8-939f-4e09-ba2a-cc3c30d3d3fc.png&data=04%7C01%7C%7C14d6c0414212430ad84c08d9c0ec0dde%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752942345688741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8jNru4pHr3zo9aZpwnMewcyG5Ra%2FlvOnNcXj%2BUOlniA%3D&reserved=0> It really seems to me that the use of a predefined template is mostly detrimental as implemented here. Even though warnPhishing is set true in the template, I don't see any indication that there's anything for the user to be concerned about here. What's even more concerning, the inclusion of "Stateless Hosting Primary" and "Example Domain Connect Service" show that the user could easily be mislead into believing they are using a completely different service than indicated. To be clear, I'm not saying that service provider registration is a bad idea. But I'm advocating two things: 1. Service provider registration should be optional. Anonymous requests with inline templates should be possible, but clearly marked as untrustworthy. 2. Any flow that displays information from a template to a user must be signed. Thoughts? Also @arnoldblinn<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farnoldblinn&data=04%7C01%7C%7C14d6c0414212430ad84c08d9c0ec0dde%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752942345698700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8pWym5sYTAJ2Crez9Deq3tvFd7HNbYVtj0MIfpSeU6E%3D&reserved=0>, it appears that host=* does not appear to work, for Godaddy at least. - Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDomain-Connect%2Fspec%2Fissues%2F64%23issuecomment-996274130&data=04%7C01%7C%7C14d6c0414212430ad84c08d9c0ec0dde%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752942345708655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=f1y62cfvqOhFE7f30fll%2BOUhp3C3EQyQy0x8Zds8Mxo%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACGGDPGGPC5OYBD6R57TMSTURJZBPANCNFSM5KHDDE5A&data=04%7C01%7C%7C14d6c0414212430ad84c08d9c0ec0dde%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752942345708655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gW642MesXTW9z9Hi2koGQmq1TGItABtUt5YyvUERfkc%3D&reserved=0>. Triage notifications on the go with GitHub Mobile for iOS<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7C%7C14d6c0414212430ad84c08d9c0ec0dde%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752942345718598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aGE2ZOiBgvrz8xB2av6ccYXsoVy1Gea53bzUxWnO4z4%3D&reserved=0> or Android<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7C%7C14d6c0414212430ad84c08d9c0ec0dde%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752942345728572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ODrpEhrelXBhdrv8tEutp1r6VJIoEVZTfPdncf49NAg%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[pawel-kow]

@anderspitman public template repositiry and the review process in there is happening to save the work for the community.
One important factor for the review is in fact to minimize attack surface for phishing, especially by minimizing possibilities of unintended use of a template or applying additional measures (require signing, warnPhishing, minimize variable parts etc.).
We are not yet that far to have a fully automated rule-set that would allow for such verification on the fly and automated.

The template is in the end of the day an API contract between DNS provider and Service provider (in some cases backed by a read legal agreement). Each time it's a distinct decision of a DNS provider whether to onboard the template and whether to trust the community review process. I can tell most of DNS providers have also own review process before onboarding and most are also onboarding templates out-of-band, for internal usage or for confidential partners.

What we never wanted Domain Connect to be was a generic CRUD-like API for any DNS record, which would eventually keep the doors wide open for any kind of misuse. Domain Connect keeps the scope of user consent as narrow as possible to minimize the risk. And I think it's working very fine for the use-cases it was designed for.

The use-case of standalone tools is a bit difficult as many of the security measures don't work, but as dyndns case shows it's possible and can be very successful.
So I think you can still give it a try with a template for your service. If sync flow works out for you then you should have even easier way to get it rolling.

[anderspitman]

Thanks again both of you.

I will consider implementing Domain Connect for my projects and trying to get DNS providers to accept my templates.

But ultimately I don't think Domain Connect in its current form is really a good fit for self-hosted software. Requiring every open source project to onboard a template with every DNS provider they want to support is simply too much friction. I really think there needs to be support for anonymous requests. Obviously not all DNS providers would have to support them, but I think it should be an option.

Who should I talk to about trying to get this added to Domain Connect? I need this functionality for my projects, but I don't think it makes sense for me to make a completely separate spec that would work basically the same way on a technical level, only with more open/loosely coupled integration policies.

[pawel-kow]

@anderspitman as mentioned, there are DNS providers that accept templates from the public repo without any review (let' name them group 1). There are ones who do an internal review and accept (group 2) and finally ones which only accept with additional legal agreement (group 3).
I would assume that groups 2&3 won't accept such "template with request" anyways, same as they don't accept templates out of the repository as-is.

No matter if self-hosted or not, the process of making the template public increases the trust and security for the whole community. For the group 1 it actually is functionally equal to passing a template with the request and even opens the door to the group 2 of providers who would accept your template after review. For group 3 you also get a chance, maybe with a little bit more effort and communication, but eventually as examples of DynDNS, ID4me or Plesk (also self-hosted!) show, this is doable and in many cases very successful.

The bottom line - with template approach you can likely reach all 3 groups. With full dynamic - you likely reach only the group 1.

BUT... this is an open community and healthy community lives from active participants, exchange of ideas and open discussions. You are welcome to join the Slack channel and see whether you gain interest from your proposal. I would argue such extension to be a separate specification (similar like "dynamic registration" specifications to OAuth2 or OIDC are separate to the core) but then if few parties are interested to spec it and eventually implement, let it be so.

[anderspitman]

Sorry for the delay. Thanks for the explanation. I still think things are too tightly coupled and the friction is too high for small projects to integrate, but I understand the design decisions based on the problems you're trying to solve. Thanks @arnoldblinn and @pawel-kow!

Hope you have a happy new year!