[agwa]

The problem with opaque records like "029845yn0sidng0345randomnyosndgf03548yn" is that you have zero clue what it's authorizing, making it impossible to audit your DNS records to ensure that you're only authorizing what you want to be authorizing.

And what do opaque records gain you anyways? Security by obscurity is not real security, and it's often possible to determine a domain's service providers by other means, such as CNAME/MX records, or by scanning the website for <script> tags.

Ideally, domain validation records would be of the form ACCOUNT_ID@SERVICEPROVIDER so you can know exactly what the record is authorizing.

[snowwrestler]

To make this explicit: maintaining accurate DNS configuration is extremely important to enterprise security and availability.

Allowing outdated DNS entries to persist can open up all sorts of horrible opportunities for impersonation, phishing, etc.

At the same time, removing a DNS entry that you still need can cause massive downtime.

So anything that makes it easier for ops teams to observe and maintain DNS (in whatever ugly way available) is probably a security win in the long run.

[gray_-_wolf]

> The problem with opaque records like "029845yn0sidng0345randomnyosndgf03548yn" is that you have zero clue what it's authorizing,

I would have hoped the DNS management is automated and IaC-ed, so you just check the relevant commit message.

[icedchai]

Keep hoping. Most orgs are updating their DNS through some awful web interface that often doesn't even have the ability to add a comment.

[singron]

The service could also MitM you. They give you a code that validates their account against a second service.

[remram]

Interesting point. I guess it would be possible to mask them, e.g. they give you the string "gitlab-123token123" and you set the TXT to hash("gitlab-123token123").

[agwa]

In a perfect world there would be a special DNS record type for this. The DNS server would store the full token value, but would return the hash when someone queries it. I think this would provide both maximum security and maximum privacy.

[c4mpute]

You could use your DNSSEC signing key to sign a validation message (offline, because that doesn't work over DNS).

[agwa]

As discussed elsewhere in this thread, domain validation needs to be frequently rechecked. Therefore, it's far more convenient to publish a DNS record than to manually sign messages out-of-band.

[remram]

DNSSEC already provides attestation, why add another layer within the same system?

[bawolff]

In real life,lots of companies infrastructure is an undocumented non-version controlled mess

[derefr]

> making it impossible to audit your DNS records

Every DNS provider I've used in recent memory, has offered a non-authoritative / non-DNS-exposed "comment" or "description" field for each record. Even if you aren't doing "DNS infrastructure as code" but just editing DNS records in a UI dashboard, you can just use these fields to describe the motivation behind each record at creation time.

[jorams]

> Every DNS provider I've used in recent memory, has offered a non-authoritative / non-DNS-exposed "comment" or "description" field for each record.

In my experience this is not at all common. I think I know of 3 that do, and I've used many more that don't.

[c4mpute]

Even stupid age-old BIND zone files can be version controlled and commented. Anything inferior to that level of documentability should be an instant no-no.

[agwa]

That can help with the ongoing maintenance of your records, but doesn't help you when you're adding the record in the first place.

As pointed out by singron at https://news.ycombinator.com/item?id=38069760 a malicious service provider (SP1) could give you a DNS record that was really issued by a different service provider (SP2). When you publish the DNS record, you're actually authorizing SP1's account at SP2 to use your domain.

With non-opaque records, you can be sure of what you're publishing.

[c4mpute]

Ah, now I get it. Yes, that is a possible problem.

[tallanvor]

Domain verification should typically be a one-time or at least rare event. You shouldn't have to keep the txt records after the verification is completed.

[agwa]

No, domain validation should be frequent, so that revoking authorization can take effect quickly, which is particularly important if the domain changes ownership.

[leni536]

It should be one-time, yes. Maybe it shouldn't be rare though. But your point still stands as the TXT records should be ephemeral. So I don't think this deserves the downvotes.

At least ACME's DNS challenge protocol is designed this way.

> The client SHOULD de-provision the resource record(s) provisioned for this challenge once the challenge is complete, i.e., once the "status" field of the challenge has the value "valid" or "invalid".

https://datatracker.ietf.org/doc/html/rfc8555#page-67

[3c6bYDXLMj]

That’s insane. Domains are not owned by the same entity forever.