CNAME responses for RFC8553?

[Ian Williams]

Hello, PSL community,

In the PSL guidelines. there's talk of how to perform DNS verification for new submissions to the PSL. I'd imagine we're all familiar with the content there, but here's the content as-written:

RFC8553 DNS Authentication

For each suffix included in the patch, add a corresponding DNS TXT record called _psl that contains the link to the PR.

For example, if you submit the following patch:

+// Company : http://www.example.com +// Submitted by John Doe <jo...@example.com> +alphaexample.com +foo.betaexample.com +*.gammaexample.com

Then we expect to find the following DNS records (assuming the pull request ID is 100):

$ dig TXT _psl.alphaexample.com https://github.com/publicsuffix/list/pull/100 $ dig TXT _psl.foo.betaexample.com https://github.com/publicsuffix/list/pull/100 $ dig TXT _psl.gammaexample.com https://github.com/publicsuffix/list/pull/100

If that DNS query were instead to respond with a CNAME record (which, in turn, responds with a TXT record), would this be appropriate as well? I didn't see anything in RFC8553 that forbids the use of CNAMEs for this purpose, but the Guidelines say "TXT record" specifically.

Internally, this would help distributed organizations (like our own) with assisting our teams in onboarding to the PSL. By permitting CNAMEs in this fashion, our product teams can defer control over the PSL verification process to our team, who do not otherwise have ownership/access over their DNS infrastructure.

---

Here's an example of how this might look in practice in a DNS verification artifact:

Direct TXT:

$ dig +short -t TXT _psl.example.com "https://github.com/publicsuffix/list/pull/100"

CNAME to TXT:

$ dig +short -t TXT _psl.example.com
cname-target.example2.net. "https://github.com/publicsuffix/list/pull/100"

[dnsguru]

Hi Ian-

I believe it would be appropriate but I would seek to do a proof of concept before you'd develop any forms of automation or treat that guidance as being reliable guidance.

The lookup to validate is entirely abstracted and focused on the resulting TXT leaf being available and matching the pull request, and being possible from any public resolver.  If there is any CNAME or other stuff happening under the hood in that process, my understanding is that it is irrelevant to the outcome of fail/pass, but it would be subject to the library(ies) used for any automation of the DNS validation and how that is procesed.

-Jothan

[Peter Thomassen | SSE]

Hi,

On 7/8/24 21:57, dnsguru wrote:
> I believe it would be appropriate

Ack.

Peter

[Ian Williams]

Jothan,

Fair enough, a PoC would be appropriate. I've created some example DNS records to demonstrate this. For my PoC, consider that I'd like to include widgets.cool-service.iwillamz.people.amazon.dev on the PSL, in #1954. (We wouldn't, this is for demonstration purposes only.)

For DNS validation, a query would be made for a TXT record at _psl.widgets.cool-service.iwillamz.people.amazon.dev. This currently responds with a CNAME to widgets.cool-service.iwillamz.people.amazon.dev.for.psl.security.aws.dev. A TXT query for this domain will respond with "https://github.com/publicsuffix/list/pull/1954".

These are real domains, and can be queried right now from your choice of public DNS resolver. Testing in a recent-ish version of dig (9.11.4), and via Google DNS, handling of the CNAME always looks to happen transparently to the client.

A few notes:

• The intermediate/CNAME-target domain (widgets.cool-service.iwillamz.people.amazon.dev.for.psl.security.aws.dev) could be anything.
  In this case, I've included the exact name of the suffix, as it clarifies the linkage between the two.
• The intermediate domain intentionally does not start with a _psl label - this way, the intermediate domain couldn't accidentally be onboarded to the PSL, as it's not actually a usable public suffix (nor would it make sense to be).
• The intermediate domain is within a very-different registration domain (amazon.dev vs. aws.dev), and is similar to how we might use it. Trust is established between the two by the domain owner onboarding to the PSL when they create the CNAME record to said target.

$ dig @8.8.8.8 -t TXT _psl.widgets.cool-service.iwillamz.people.amazon.dev

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.13.5 <<>> @8.8.8.8 -t TXT _psl.widgets.cool-service.iwillamz.people.amazon.dev
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35690
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_psl.widgets.cool-service.iwillamz.people.amazon.dev. IN TXT

;; ANSWER SECTION:
_psl.widgets.cool-service.iwillamz.people.amazon.dev. 300 IN CNAME widgets.cool-service.iwillamz.people.amazon.dev.for.psl.security.aws.dev.
widgets.cool-service.iwillamz.people.amazon.dev.for.psl.security.aws.dev. 300 IN TXT "https://github.com/publicsuffix/list/pull/1954"

;; Query time: 79 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jul 08 21:54:53 UTC 2024
;; MSG SIZE  rcvd: 223

Hopefully this helps clarify things?

[dnsguru]

Hi Ian-

I saw the matching txt record returned correctly for  _psl.widgets.cool-service.iwillamz.people.amazon.dev. FWIW, so the example worked for the purposes, whatever they are, of determining if this CNAME method might succeed.

Can we plant a success flag for whatever this exercise is.

-J

[Simon Friedberger]

This seems fine to me and I can update the docs.

Ian, could you explain why this simplifies things for you, please. It seems the same people still need to add a DNS entry but now it's a CNAME instead of a TXT.

BR

Simon

[dnsguru]

Simon no change. this all will be opaque to us and we will do the eval no differently - we still would validate the _psl TXT on the requested string(s), business as usual

Behind the scenes, the CNAME method just makes their process for aligning a large quantity of names at once, as they can maintain a single TXT record and then use CNAME to alias multiple names to it.

Kind of a genius way to manage multiple entries.