4 ms·

The problem with opaque records like "029845yn0sidng0345randomnyosndgf03548yn" is that you have zero clue what it's authorizing, making it impossible to audit y

by agwa 3y ago

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.

tallanvor 3y ago
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 3y ago
  No, domain validation should be frequent, so that revoking authorization can take effect quickly, which is particularly important if the domain changes ownership.
- 3c6bYDXLMj 3y ago
  That’s insane. Domains are not owned by the same entity forever.
- leni536 3y ago
  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 https://datatracker.ietf.org/doc/html/rfc8555#page-67
gray_-_wolf 3y ago
> 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.
- singron 3y ago
  The service could also MitM you. They give you a code that validates their account against a second service.
  - remram 3y ago
    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 3y ago
      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 3y ago
        You could use your DNSSEC signing key to sign a validation message (offline, because that doesn't work over DNS).
        agwa 3y ago
        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 3y ago
derefr 3y ago
> 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 3y ago
  > 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.
snowwrestler 3y ago
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.
c4mpute 3y ago
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 3y ago
  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 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 3y ago
    Ah, now I get it. Yes, that is a possible problem.

by agwa 3y ago

tallanvor 3y ago

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 3y ago
No, domain validation should be frequent, so that revoking authorization can take effect quickly, which is particularly important if the domain changes ownership.
3c6bYDXLMj 3y ago
That’s insane. Domains are not owned by the same entity forever.
leni536 3y ago
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 https://datatracker.ietf.org/doc/html/rfc8555#page-67

gray_-_wolf 3y ago

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

singron 3y ago
The service could also MitM you. They give you a code that validates their account against a second service.
- remram 3y ago
  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 3y ago
    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 3y ago
      You could use your DNSSEC signing key to sign a validation message (offline, because that doesn't work over DNS).
      - agwa 3y ago
        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 3y ago

derefr 3y ago

> 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 3y ago
> 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.

snowwrestler 3y ago

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.

c4mpute 3y ago

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 3y ago
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 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 3y ago
  Ah, now I get it. Yes, that is a possible problem.