domain-connect / spec Goto Github PK
View Code? Open in Web Editor NEWDomain Connect Specification
License: MIT License
Domain Connect Specification
License: MIT License
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.
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
A use-case of setting up multiple domains in one call (verification, domain parking).
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:
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.
@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
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:
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").
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
Add CAA support?
Generic way to add any RR type?
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:
With this is mind and after reading the Domain Connect spec, I have the following questions/concerns:
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.
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?
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!
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:
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).
Is it already the right time to talk about standard API for template onboarding/management by the Service Provider?
GroupId section in table from 4.2 (Sync ApplyTemplate) is duplicated
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.
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: +1.4806242505
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.
https://[email protected]
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):
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:
To be decided: recommendation on what to do when two service's DMARC tags do conflict with each other.
Some corner cases to consider:
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.
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.
use-case: avoid template redundancy or very bloated templates with many group variants
> https:// [[email protected]](mailto:[email protected])
Originally posted by @keto334 in #95 (comment)
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?
Currently, the Domain Connect protocol has no method of confirming if changes were successful to the Service Provider.
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.
Double part of string in Digitally Sign Requests
NCDfnRHut5nG0S3U4cq4DuGrMDFVBwxH1duTsqDNgIOOfNTsFcWSVXoSSTqCCMGbj8Vt51umDhWQAj06lf5
The records would be of the form:
end of 2 and start of 3
Just to name few I came across in feedback from implementers on service provider side (some of them indeed optional in the spec):
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.
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
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!
> https:// [[email protected]](mailto:[email protected])
Originally posted by @keto334 in #95 (comment)
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.
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
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.
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.
The process is described in the RFC.
Not sure whether it will pass expert review without any organisation formally respoinsible for the spec
Not a spec issue, but a general one - txtConflictMatchingPolicy is needed for DMARC deployment, but seems not to be widely implemented
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.