[DNSOP] Re: I-D Action: draft-ietf-dnsop-domain-verification-techniques-09.txt

Paul Wouters <paul@nohats.ca> Mon, 21 July 2025 11:58 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id C6522475FACB; Mon, 21 Jul 2025 04:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Level:
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep20WzmNK2mz; Mon, 21 Jul 2025 04:58:38 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2D400475FAC1; Mon, 21 Jul 2025 04:58:38 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4blzSX4F8qz9hv; Mon, 21 Jul 2025 13:58:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1753099116; bh=7MVaryQKTfRO5fvg5/N1W1ErniAPxNhdSkTz4GucRVI=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=tdlexPnULLwmqOnHUDpbbKO79pl82OmS/oM+bA12SY2jPV7OntwkZrgn3C3UzDWnx Ft4wuWWMiE4IWWTpBYrMLzEPPHk+OU4tUhg1LMYDRW9xRC4R0FLms7fpTRqKnaeE0z MQOc7l1aCnuqDXK/tVB28K+ZgoGQ99hceW8ei1MU=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id gYicnj9jTyTL; Mon, 21 Jul 2025 13:58:35 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 21 Jul 2025 13:58:35 +0200 (CEST)
Received: from smtpclient.apple (rtr-guestwired.meeting.ietf.org [31.133.144.1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 48E63162A211; Mon, 21 Jul 2025 07:58:34 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-5E79351E-C6AF-4575-8512-B62C10738D5F"
Content-Transfer-Encoding: 7bit
From: Paul Wouters <paul@nohats.ca>
Mime-Version: 1.0 (1.0)
Date: Mon, 21 Jul 2025 13:58:21 +0200
Message-Id: <0C10FDA2-F19A-474D-A533-91D1455EA1D7@nohats.ca>
References: <CADyWQ+GpGz9rAo29qf=j0QLOSybn+jaAMu3d+SY75LjRTFB-AA@mail.gmail.com>
In-Reply-To: <CADyWQ+GpGz9rAo29qf=j0QLOSybn+jaAMu3d+SY75LjRTFB-AA@mail.gmail.com>
To: Tim Wicinski <tjw.ietf@gmail.com>
X-Mailer: iPhone Mail (22F76)
Message-ID-Hash: OF2OLJNMOYAVEVC5I37XH3RSDMJ2ONS2
X-Message-ID-Hash: OF2OLJNMOYAVEVC5I37XH3RSDMJ2ONS2
X-MailFrom: paul@nohats.ca
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org, i-d-announce@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: I-D Action: draft-ietf-dnsop-domain-verification-techniques-09.txt
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zyFeiGNZ5CO7Yt-hFX_t14CoyRI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

On Jul 8, 2025, at 21:52, Tim Wicinski <tjw.ietf@gmail.com> 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




On Mon, Jul 7, 2025 at 3:28 PM <internet-drafts@ietf.org> 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/" rel="noreferrer nofollow" target="_blank">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" rel="noreferrer nofollow" target="_blank">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" rel="noreferrer nofollow" target="_blank">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 -- dnsop@ietf.org
To unsubscribe send an email to dnsop-leave@ietf.org