domain-connect/spec

Domain Connect Specification

spec's Issues

Multi domain application

A use-case of setting up multiple domains in one call (verification, domain parking).

New record types (CAA)

Add CAA support?
Generic way to add any RR type?

Content type not specified to get access_token

https://github.com/Domain-Connect/spec/blob/master/Domain%20Connect%20Spec%20Draft.adoc#433-oauth-flow-requesting-an-access-token

The following table describes the POST parameters to be included in the request for the access token. The parameters should be accepted via the query string or the body of the post. This is again particularly important for the client_secret, as passing secrets via a query string is generally frowned upon given that various systems often log URLs.

Here we shall say more about accepted encoding (both input and output).

So far we assumed we only need "application/json", but one of providers requested "application/x-www-form-urlencoded" as well.

Remove domain record

Good afternoon, I can not delete the record created through domainconnect, as a result of the ns server the cloudflare is given WRONG ip addresses

The entries were changed 2 days ago, all ns servers, except for the cloudflare, are given correctly

966559068865

https://[email protected]

Why using multiple TXT records for the public key

In section 4.2.3. Security Considerations, the spec says:

Since the public key may be greater than 255 characters, multiple TXT records may exist for the DNS TXT query.

Instead of entering multiple, enumerated TXT records, wouldn't it be better to use multiple strings inside one TXT record, like used in DKIM and SPF records?

While a single string inside a TXT record is limited to 255 chars, a singe record may consist of multiple strings.

This would save some bytes, the record for the example could look like this:

_dcpubkeyv1 IN TXT "a=RS256,t=x509,d=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1dCqv7JEzUOfbhWKB9mTRsv3O9Vzy1Tz3UQlIDGpnVrTPBJDQTXUhxUMREEOBKo+rOjHZqfYnSmlkgu1dnBEO8bsELQL8GjS4zsjdA53gRk2SDxuzcB4fK+NCDfnRHut5nG0S3U4cq4DuGrMDFVBwxH1duTsqDNgIOOfNTsFcWSVXoSSTqCCMGbj8Vt51umDhW" "QAj06lf5NCDfnRHut5nG0S3U4cq4DuGrMDFVBwxH1duTsqDNgIOOfNTsFcWSVXoSSTqCCMGbj8Vt51umDhWQAj06lf50qP2/jMNs2G+KTlk3dBHx3wtqYLvdcop1Tk5xBD64BPJ9uwm8KlDNHe+8O+cC9j04Ji8B2K0/PzAj90xnb8XJy/EM124hpT9lMgpHKBUvdeurJYweC6oP41gsTf5LrpjnyIy9j5FHPCQIDAQAB"

The p= parameter would not be required anymore, the other parameters appear only once.

Concatenation as described in RFC7208 (SPF) section 3.3:
https://tools.ietf.org/html/rfc7208#section-3.3

Add success state to redirect_uri to validate changes

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.)

Using variables in port for SRV records

Hey,
I am working for a webhosting company and we are currently integration DomainConnect to improove UX.
In addition to traditional webspaces or virtual servers, we are offering game servers. These do not have a dedicated IP address, but rather run on different ports on the same host system.
We need to set a SRV record for this to work. The problem now is, that according to the DomanConnect specification, variables in SRV ports are not allowed. Is there any plan to make this possible?

Here is a small example of what i want to do:

{
  ...
  "records": [
    {
      "type": "A",
      "host": "@",
      "pointsTo": "%ip%"
    }, {
      "type": "SRV",
      "host": "@",
      "pointsTo": "%ip%",
      "port": "%port%",
      ...
    }
  ]
}

best regards
Luca

Register _domainconnect TXT record with IANA as per RFC8552

The process is described in the RFC.
Not sure whether it will pass expert review without any organisation formally respoinsible for the spec

Domain Connect for self-hosted services

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!

Multiple instances of the same record

Some templates allow to setup multiple records of the same type (for the same host).
Right now one template record = one DNS record, forcing a very complex template with multiple variables and groups to make the selection possible.

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

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.

> https:// [[email protected]](mailto:[email protected])

          > https:// [[email protected]](mailto:[email protected])

Originally posted by @keto334 in #95 (comment)

Double part of string in Digitally Sign Requests

Double part of string in Digitally Sign Requests
NCDfnRHut5nG0S3U4cq4DuGrMDFVBwxH1duTsqDNgIOOfNTsFcWSVXoSSTqCCMGbj8Vt51umDhWQAj06lf5
The records would be of the form:
end of 2 and start of 3

General acceptance of txtConflictMatchingPolicy

Not a spec issue, but a general one - txtConflictMatchingPolicy is needed for DMARC deployment, but seems not to be widely implemented

Template onboarding automation

Is it already the right time to talk about standard API for template onboarding/management by the Service Provider?

mergeable DMARC record

Problem

Imagine a domain with multiple different services, who'd each like to have a word on the contents of the domain's DMARC record (_dmarc TXT):

• a general email service
• a DMARC-reporting service like fraudmarc.com,…
• a email service provider like mailjet,… for sending out one's newsletter.

 The general email service recommends its users to configure DMARC with a policy to quarantine or rejecting any unauthorized mail, setting DMARC's policy to a default of p=quarantine, but also allowing the user to switch to "p=reject" or "p=none".
 
The DMARC-reporting service doesn't care about the exact policy but would like to have its reporting email address listed in the "rua" or "ruf", as their primary purpose is to analyze any incoming reports.
So the service would like to add a "rua=mailto:[email protected]" to the DMARC record. When one address already exists at that tag, the new one should be appended.
 
DKIM requires alignment of "From"-header and "MailFrom"-envelope. As the newsletter is using a custom subdomain during the SMTP dialogue to receive bounces, the corresponding alignment policy must be "relaxed". While this is the default value for DMARC, the email service provider wants to ensure an "apsf=r" tag.
 
Suggestion:

• provide an "SPFM"-like "DMARCM" tag, which merges any non-conflicting DMARC tags.

To be decided: recommendation on what to do when two service's DMARC tags do conflict with each other.

• choose the "weaker", more compatible one: prefer "relaxed" over "strict" mode, prefer "quarantine" over "reject", "none" over quarantine or reject.
The user is told whose tags have been overridden during this merge operation.
• choose the "tighter", more secure one: prefer "strict" over "relaxed" mode, prefer "reject" over "quarantine" over "none".
The user is told whose tags have been overridden during this merge operation.
• let the user decide.

Some corner cases to consider:

• an email service provider knows their specific configuration to be incompatible with DMARC (e.g. due to misalignment of Envelope-From and Header-From). They do prefer no DMARC record at all, but could also live with p=none.
• how many email reporting addresses are being honored is up to the reporting server. So an "early" email address in a rua tag may be "more important" than a "late" email address. And after all, users are recommended not to use more than 3 email addresses in each tag, as the later added are unlikely to be honored by most DMARC reporting mail servers.

Why is this needed:

Today, the DMARC-record is a simple TXT record and at best, a Domain Connect template states a conflict if the record starts with "v=DMARC1".
We currently don't run into this issue, as barely anyone is deploying DMARC records by default. However, DMARC is a promising technology and so this issue may arise.

Today, any service may decide to use a CNAME instead of a TXT record to bring the entire DMARC record under the full administrative control of the specific service. This does prevent any manual misconfiguration by the user but also prevents any other service from configuring DMARC. A mergeable DMARC record could "fix" this issue, by allowing services to merge their specific DMARC requirements.

URL format for `_domainconnect` TXT record is not specified

The specification mention that _domainconnect must return the URL prefix for the REST endpoint.

4.4.  DNS Provider Discovery

   In order to facilitate discovery of the DNS Provider given a domain
   name, a domain will contain a record in DNS.

   This record will be a simple TXT record containing a URL used as a
   prefix for calling a discovery API.  This record will be named
   domainconnect.

   An example of this record would contain:

   https://domainconnect.godaddy.com

But the URL format is not specified.

For example, the current implementation in godaddy returns domainconnect.api.godaddy.com, which does not include the protocol.

This is problematic because if we want service provider to implement this in a generic matter, the provider needs to know in advance the URL format and how to validate the value in the TXT record.

Template compatibility test

Right now the template cannot be really tested by onboarding by the DNS provider, because the DNS provider does not have any test data of variables and also not the expected output.
If this infomation would be present in the template, the template onboarding could be better automated including testing of the expected output.

Possible extension for full domain and zone transfer

https://docs.google.com/document/u/0/d/1SQqGYKAEfAQM6pr7NDr4TcI0dRJiLJq_FX-8ts2KBbI/mobilebasic?resourcekey=0-g_MUSFl9xzO-UKuzMzjmyA

Merge of SPF-record

Imagine there are 2 services configured for one domain, which both can send E-mail from the accounts assigned to the domain name.

Typical setup:

1. Mail service: template with MX and SPF records
2. Newletter service: template with SPF and DKIM configuration

Current conflict resolution in the spec advises to remove service (1) in case service (2) is configured.
This is probably not the intended usage by the customer.

Other option, not to detect conflict will result in 2 SPF records -> broken setup, not conform to RFC (https://tools.ietf.org/html/rfc4408#section-3.1.2)
Similar, if SPF records would be marked as not-essential (see PR #9) it will not brake service (1) but will also only make one of 2 services not failing on SPF-checks.

I think the only viable solution is to define SPF-merge into the standard and define the strategy.

My proposal would be:
Merge everything between "v=spf1" and "all". Chose the highest value for "all" (so from ~all and -all the merged version would show -all).

Issue with Domain Connect CNAME Flattening

Description
When adding a CNAME record with the host @ using Domain Connect, all existing TXT and MX records with the host @ are removed, even though they do not conflict with the CNAME record. This behavior leads to unintended disruption of mail and other services relying on TXT and MX records.

Steps to Reproduce

1. Add a CNAME record with the host @ using Domain Connect.
2. Observe that any existing TXT and MX records with the host @ are removed.

Expected Behavior
Adding a CNAME record with the host @ should not affect existing TXT and MX records with the host @, as there is no conflict between these record types.

Actual Behavior
When a CNAME record with the host @ is added, all TXT and MX records with the host @ are removed.

Impact
This issue disrupts email and other services that rely on TXT and MX records, causing significant problems for users who need to maintain these records.

Suggested Fix
Review the logic for handling CNAME flattening to ensure that non-conflicting records (such as TXT and MX) are preserved when a CNAME record is added.

Screenshots/Logs

Please let me know if you need any further details to address this issue.

Thank you!

Multi-template application

use-case: avoid template redundancy or very bloated templates with many group variants

> https:// [[email protected]](mailto:[email protected])

          > https:// [[email protected]](mailto:[email protected])

Originally posted by @keto334 in #95 (comment)

Validation of _domainconnect TXT record contents

https://github.com/Domain-Connect/spec/blob/master/Domain%20Connect%20Spec%20Draft.adoc#3-dns-provider-discovery basically says "get the _domainconnect TXT record, and if you have one, treat it as a hostname and send a request."

That's probably "fine", but can lead to ugly problems when that TXT record contains other garbage -- such as when people misconfigure their DNS. For instance I found in our logs that we queried _domainconnect.usechatterly.com, and received what looks like a paddle verification record:

$ dig _domainconnect.usechatterly.com TXT +short
"paddle-verification=9b0880ce"

Bit of guessing, but what actually happened here is probably a user trying to verify a wildcard:

$ dig foobarbazquux.usechatterly.com TXT +short
"paddle-verification=9b0880ce"

I was wondering: Could the _domainconnect TXT record use a structured format instead (think like SPF records v=spf1 [stuff]), so that we can statically check that that TXT we got has at least a fighting chance of being a domain connect-related thing?

Templates definition should include contactEmail key

The definitions in https://github.com/Domain-Connect/spec/blob/master/Domain%20Connect%20Spec%20Draft.adoc#52-template-definition should include contactEmail that is a string and expected to be an email address. Ideally the email should be a maillist or group that will reach people who can comment about the template, or be requested to make updates if/when there is an issue with a template. An issue could be minor syntax error such as TTL written as a string, or unreachable logo url.

The contactEmail needs to be an optional field to avoid backwards compatibility issues.

Concerns regarding "-all" as a default policy on SPF

Default SPF policy of "fail"

6.10.3 advises always to use a fixed modifier of "-" (fail) for any messages from other sources not specified in SPF rules. When two services with different policies are being merged via SPFM, they do result in having "-all" as a default policy.

6.10.3 also states "it" (merged SPF record or just the default policy?) can always be modified by the user after the merge operation is completed.

After years of experience with SPF, this advisory is quite worrying, as it puts a troublesome default into place.

Issues with forwarding (SPF, SRS, DMARC)

Mails may be forwarded by generic mail forwarding services and mailing lists, who don't rewrite rfc5321.MailFrom. As the sender's SPF record doesn't list those forwarding hosts, the final receiving host will apply the default policy: to reject those forwarded messages.

The experimental SRS (Sender Rewriting Scheme) is a method to rewrite the address in rfc5321.MailFrom. An SRS-compliant forwarding host will encode the original address in the localpart and append a SRS-specific, SPF-whitelisted domain to it. From the receiving host's point of view, the sender address meets the SPF record of the (SRS-specific) domain and so the message is to be accepted.

In real life, SRS has a very low adoption rate due to complexity and further issues.

SRS is also incompatible with DMARC's requirement on the identifier alignment: in DMARC's "strict" mode, both domains from rfc5321.MailFrom and rfc5322.From need to match exactly; in DMARC's relaxed mode, the rfc5321.MailFrom domain must be at least a subdomain of the domain from rfc5322.From.

Many mail servers do evaluate SPF records during the SMTP dialogue and reject after "MAIL FROM" commands, while DMARC is evaluated after the message has been received later during the SMTP dialogue. A "fail" default policy can result in situations where a forwarded message won't have a chance of being accepted by the receiving mail server:

• If rfc5321.MailFrom has been rewritten by SRS, it'll pass the initial SPF check during the SMTP dialogue but won't meet the DMARC requirement of identifier alignment.
• If rfc5321.MailFrom has not been rewritten, it won't pass the initial SPF check during the SMTP dialogue, even though it could've met sufficient requirements from DMARC (by having correct identifier alignment and a valid DKIM signature).

Using a less restrictive default policy like softfail (~all) or neutral (?all), the un-rewritten message could've passed the initial SPF check.

One might also argue to prefer "neutral": RFC7208 specifies the lack of an "all" mechanism to be interpreted as "neutral":

If none of the mechanisms match and there is no "redirect" modifier,
then the check_host() returns a result of "neutral", just as if
"?all" were specified as the last directive.

Contradicting example

6.10.2 gives an example where multiple SPF records with different default policies (~all and -all) are manually being merged. The result uses the "least restrictive all modifier" as a new default policy of the SPF record and advocates "-all" to be more appropriate when no other services are being used.

This merge strategy makes much more sense to me, as it does prefer the "more compatible" default policy rather than the "most strict" policy.

Other antispam engines

From perspective of different spam filtering engines like SpamAssassin, there's not much difference between a softfail and a fail default policy, yet there is often a strong difference if SPF is being evaluated by an MTA.
So after all, a softfail (~all) default policy seems to be a much more reasonable default for most users, as it does avoid forwarded messages from being rejected at "MAIL FROM" time without risking compliance on other standards like DMARC. When SPF and DMARC are being evaluated at the same time, an enforced DMARC policy (p=quarantine, p=reject) overrides any SPF default policies, so having a strict SPF-encoded default policy is even less required.

Suggestions

I do see a few points to address this topic.

• have a default policy of "~all" to address potential problems with forwarded mails and DMARC.

• when multiple records with different default policies are being merged, the least-restrictive modifier aside of "pass" is to be preferred: neutral is to be preferred over softfail, softfail is to be preferred over fail: ?all > ~all > -all

• Due to the negative consequences when mail is being forwarded, a policy of fail (-fail) is only to be used when the user is aware of its effect. Accordingly, it MUST NOT be a silent default option by SPFM merges, unless the user did actively select this option.

• When DMARC is in place using a policy of p=quarantine or p=reject, do at most use an SPF default policy of ~all (softfail). Together with "least-restrictive merging", a DMARC-template could simply apply an empty SPFM record or SPFM-merge "~all" into what else is left.

Also noteworthy: RFC7208 in appendix A.4 contains an example making use of "+all" (pass) for a restrictive policy (by negating other records, including a deprecated "ptr" method). I do have serious doubt such a record could be successfully merged with any "more common" SPF record. I haven't seen such an SPF record in real life, but I've seen quite a few "+all" or "all" records, which result in an insecure configuration.

It's probably reasonable to reject merging any SPFM record mentioning the "all" mechanism with either an explicitly or implicitly passing modifier ("+all,"all").

GroupId section in table from 4.2 (Sync ApplyTemplate) is duplicated

GroupId section in table from 4.2 (Sync ApplyTemplate) is duplicated

the shared provider and service name usage is not clear

The sharedServiceName has explanation:

"This flag indicates that the template allows the caller to pass in additional information for the serviceName. This information should augment the display of the serviceName from the template."

Does that mean the value of serviceName can be a template when sharedServiceName is true? And the opposite way around, value is false the serviceName must not use template. Or am I completely mistaking what is meant with allows the caller to pass in additional information.

Inconsistencies in the implementations from DNS providers and/or signalling of implemented features set

Just to name few I came across in feedback from implementers on service provider side (some of them indeed optional in the spec):

• txtConflictMatchingMode (see #86 as well)
• redirect signalling for sync flows

Specify better mixed APEX/subdomain template kind

In many cases a template variant would require host for certain groups (like CNAME for subdomain variant) where other groups won't require it (A records setup).
hostRequired does not have granularity on the group level.

IETF submission

It seems there is potential support for adoption within REGEXT WG (which is a great progress compared to first attempt in 2016).

Now the questions:

• Informational or Standards Track?
• who can support the process from the Domain Connect community?

Add Cloudflare to list of DNS providers supporting Domain Connect

@pawel-kow didn't know how else to raise this, but would you be able to help getting Cloudflare added as DNS provider on https://www.domainconnect.org/dns-providers/ ?

Feel free to reach out via email at hannes[at]cloudflare[.]com

DNS query for TXT record type does not return domain connect info at GoDaddy

The current draft spec (https://github.com/Domain-Connect/spec/blob/master/Domain%20Connect%20Spec%20Draft.adoc#spf-record-merging) says that the discovery record for _domainconnect.mydomain.com should be a TXT record in the mydomain.com zone. However, my domains have a CNAME record instead at GoDaddy. Either the draft spec is wrong or GoDaddy's implementation is non-compliant.

Here is an example using databaseguy.com that shows that there is not a TXT record for _domainconnect but there is a CNAME record for it.

domainconnect.org domain redirects to phishing sites

From the WHOIS info, looks like GoDaddy still has control over the domain, but it's redirecting to phishing sites as of Sept 7.

# whois.godaddy.com

Domain Name: domainconnect.org
Registry Domain ID: D182513481-LROR
Registrar WHOIS Server: whois.godaddy.com
Registrar URL: http://www.godaddy.com
Updated Date: 2019-12-17T23:49:46Z
Creation Date: 2016-02-02T18:35:58Z
Registrar Registration Expiration Date: 2021-02-02T18:35:58Z
Registrar: GoDaddy.com, LLC
Registrar IANA ID: 146
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: [phone]
Domain Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited http://www.icann.org/epp#clientUpdateProhibited
Domain Status: clientRenewProhibited http://www.icann.org/epp#clientRenewProhibited
Domain Status: clientDeleteProhibited http://www.icann.org/epp#clientDeleteProhibited
Registrant Organization: Go Daddy Operating Company, LLC
Registrant State/Province: Arizona
Registrant Country: US
Registrant Email: Select Contact Domain Holder link at https://www.godaddy.com/whois/results.aspx?domain=domainconnect.org
Admin Email: Select Contact Domain Holder link at https://www.godaddy.com/whois/results.aspx?domain=domainconnect.org
Tech Email: Select Contact Domain Holder link at https://www.godaddy.com/whois/results.aspx?domain=domainconnect.org
Name Server: NS53.DOMAINCONTROL.COM
Name Server: NS54.DOMAINCONTROL.COM
DNSSEC: unsigned

And

$ host domainconnect.org
domainconnect.org has address 160.153.138.176
domainconnect.org mail is handled by 10 mailstore1.secureserver.net.
domainconnect.org mail is handled by 0 smtp.secureserver.net.