How do people feel about the following wording?
Application Service Providers MUST use a trusted DNSSEC validating resolver
> to verify Validation Records they have requested to be deployed. When the
> AD bit ({{RFC4035}} Section 3.2.3) is not set in DNS responses for
> Validation Records, Application Service Providers SHOULD take additional
> steps to reduce an attacker's ability to complete a challenge by spoofing
> DNS:
> * Application Service Prociders SHOULD attempt to query and confirm the
> Validation Record by matching responses from multiple DNS resolvers on
> unpredictable geographically diverse IP addresses
> * Application Service Providers MAY perform multiple queries spread out
> over a longer time period to reduce the chance of receiving spoofed DNS
> answers.
This:
1) shifts ASPs using a validating DNSSEC resolver from "SHOULD" to "MUST"
2) specifies that the resolver here should be "trusted" (do we need to
define this and clarify that a secure channel to it must be used?)
3) is more specific that absence of the AD bit in the response is the
reason to take additional steps (vs the current less specific text of "If
no DNSSEC support is detected for the domain being validated, or if DNSSEC
validation cannot be performed")
(Also as a proposal in
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/188
)
Since this is in Security Considerations, it's also possible we should add
a sentence here explaining *why* ASPs MUST use a validating resolver (ie,
as otherwise an attacker could tamper with the response in a signed zone).
DNSSEC signing of zones remains a SHOULD.
Erik
On Mon, Jul 21, 2025 at 1:59 PM Paul Wouters <[email protected]> wrote:
> On Jul 8, 2025, at 21:52, Tim Wicinski <[email protected]> wrote:
>
>
>
> Current:
>
> DNSSEC validation SHOULD be performed by Application Service Providers
> that verify Validation Records they have requested to be deployed.
>
>
> To me this means “use a dns resolver that supports DNSSEC”. Which is good.
> It could be extended to say “look at the dns results for AD bit and if
> missing do some countermeasure like multiple queries spread out over some
> time and from distinct IPs/ASes”.
>
>
>
>
> Suggested:
>
> DNSSEC validation MUST be performed by Application Service Providers that
> verify Validation Records they have requested to be deployed. A "Bogus" or
> "Indeterminate" result (as defined in [[RFC4033]]) MUST NOT be accepted. A
> "Secure" or "Insecure" result SHOULD be accepted.
>
>
> The reason I believe this is wrong is that this is modifying how
> applications use DNS. I’m not dns resolvers are aware of indetermine or
> bogus. DNSSEC resolvers withhold answers from the application already in
> these cases.
>
> Applications should not know or care. They should at most check for the AD
> bit and change behaviour based on that. The current text with something I
> proposed above completely covers that.
>
> Paul
>
>
>
>
>
> https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/182
>
>
> Thoughts?
>
> tim
>
>
> On Mon, Jul 7, 2025 at 3:28 PM <[email protected]> wrote:
>
>> Internet-Draft draft-ietf-dnsop-domain-verification-techniques-09.txt is
>> now
>> available. It is a work item of the Domain Name System Operations (DNSOP)
>> WG
>> of the IETF.
>>
>> Title: Domain Control Validation using DNS
>> Authors: Shivan Sahib
>> Shumon Huque
>> Paul Wouters
>> Erik Nygren
>> Tim Wicinski
>> Name: draft-ietf-dnsop-domain-verification-techniques-09.txt
>> Pages: 18
>> Dates: 2025-07-07
>>
>> Abstract:
>>
>> Many application services on the Internet need to verify ownership or
>> control of a domain in the Domain Name System (DNS). The general
>> term for this process is "Domain Control Validation", and can be done
>> using a variety of methods such as email, HTTP/HTTPS, or the DNS
>> itself. This document focuses only on DNS-based methods, which
>> typically involve the Application Service Provider requesting a DNS
>> record with a specific format and content to be visible in the domain
>> to be verified. There is wide variation in the details of these
>> methods today. This document provides some best practices to avoid
>> known problems.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/
>>
>> There is also an HTML version available at:
>>
>> https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-09.html
>>
>> A diff from the previous version is available at:
>>
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-domain-verification-techniques-09
>>
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>>
>>
>> _______________________________________________
>> DNSOP mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>>
> _______________________________________________
> DNSOP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
