[dconn] Re: Handling of identical records

Pawel Kowalik <kowalik@denic.de> Tue, 07 July 2026 14:48 UTC

Return-Path: <kowalik@denic.de>
X-Original-To: dconn@mail2.ietf.org
Delivered-To: dconn@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id CB3E41120676D for <dconn@mail2.ietf.org>; Tue, 7 Jul 2026 07:48:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783435688; bh=UaCM9Zo27RkF1WOu3/vVg5W7vIK2xaDsxy3iGXLUR9I=; h=Date:From:Subject:To:Cc:References:In-Reply-To; b=utONWo7D45PZkJp5bl2PYnm9qYoiTC5uKwrEGMBZHtSojFCNEDwXGJ0d9c5mJ5SGA KHnmC/rGgrQ6Z4/6j8exN9Vb2ShkuzGZmxxrx0p/LehL5oxzx6OhHlewqKREa+6cTs ecfiuPg3bRZIJ3OSHC9F9O5Ao24HhvP3MXdS67hY=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=denic.de
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 iQaqOOoLLcaO for <dconn@mail2.ietf.org>; Tue, 7 Jul 2026 07:48:07 -0700 (PDT)
Received: from mout-b-112.mailbox.org (mout-b-112.mailbox.org [195.10.208.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8884311206765 for <dconn@ietf.org>; Tue, 7 Jul 2026 07:48:07 -0700 (PDT)
Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-b-112.mailbox.org (Postfix) with ESMTPS id 4gvkbx42W6zDvG9; Tue, 7 Jul 2026 16:47:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1783435677; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UaCM9Zo27RkF1WOu3/vVg5W7vIK2xaDsxy3iGXLUR9I=; b=vrFgQhZa1xRqjQk8owbfOzJzICU3YrzYGpn54wdZ8JXCng/3TGEiJ0U4wWVTD41xt1l1OV 4HPm/ehy8DBR4JAAItRHVtP4LUqwDCBQrquWTEKanavtQOAcRAaBg03P/c2W6+Sd6btJ+G XJBjg2o/UZTvj2Prf3tRNlsu6/6b5sw6tZBrSgJvBaG5F8xr2i1qfamA5I16HixqGSkWdM ROKW2lEAUJSq1B5HnCftehiY92QlFuqptOYjaRgIcfX4DBVOscfHN/FkzzJgTKxKXVwDxW 4ZAqaVY0srXzPaYs/RMs8I/CyH512vVigxuhG6xUQ1WFH/CRfY9XHlE7tn+rsQ==
Message-ID: <121eda26-42aa-4938-a242-6f7d00feb611@denic.de>
Date: Tue, 07 Jul 2026 16:47:42 +0200
MIME-Version: 1.0
From: Pawel Kowalik <kowalik@denic.de>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
References: <CAN8C-_L1hWMy+CrU+yYf3c2zYY5Y+yy_o42FgC23bRno=ao4sQ@mail.gmail.com> <d7253d54-cbde-4ffd-ac88-ae1685fa0a76@desec.io> <c313eec7-ebbe-4d8c-abc8-87394de07188@denic.de> <fe1dad39-3f6e-b846-30f1-81e7ed7f9d26@iecc.com> <CAN8C-_JBped9=p-GKnevTii0aAWPuE09jj+4xyZ8FsEtZRwU=w@mail.gmail.com> <7B508CFE-9AA9-4C19-A30D-0C195FFAB8A9@proper.com> <95af0000-7bdd-4685-9a2d-093fd40f0bf7@denic.de> <87cygyeuvc.fsf@libertango.gulbrandsen.priv.no> <54dd8d33-a6c3-41eb-bc26-290200b4cf65@denic.de> <87h669d4cd.fsf@libertango.gulbrandsen.priv.no> <e286d646-ff8d-4e80-a1d7-5270700274e5@denic.de> <b31c0757-6f9e-428b-aa27-3fa8acd358ce@denic.de> <87mrw3t7xv.fsf@libertango.gulbrandsen.priv.no>
Content-Language: en-GB, de-DE
In-Reply-To: <87mrw3t7xv.fsf@libertango.gulbrandsen.priv.no>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms030103050403040007050204"
X-MBO-RS-ID: 39b9998f6085535d02d
X-MBO-RS-META: w7zcfp6dhwsob9yefwxkcwy99k4b1x65
Message-ID-Hash: BBCSRFULMGSWETGRR7HLT25VNQQOYJCM
X-Message-ID-Hash: BBCSRFULMGSWETGRR7HLT25VNQQOYJCM
X-MailFrom: kowalik@denic.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dconn@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [dconn] Re: Handling of identical records
List-Id: "Domain Connect is a protocol that makes it easy for a user to configure DNS for a domain running at a DNS provider to work with a Service running at an independent Service Provider." <dconn.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dconn/Cke7Johb_2ajqU30fsHCndmRS0g>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dconn>
List-Help: <mailto:dconn-request@ietf.org?subject=help>
List-Owner: <mailto:dconn-owner@ietf.org>
List-Post: <mailto:dconn@ietf.org>
List-Subscribe: <mailto:dconn-join@ietf.org>
List-Unsubscribe: <mailto:dconn-leave@ietf.org>

Hi Arnt,

On 07.07.26 12:23, Arnt Gulbrandsen wrote:
> Thanks!
>
> Pawel Kowalik <kowalik@denic.de> writes:
>> finally I got to draft a text which would support the issue you 
>> highlighted.
>> I propose the following text (based on current 
>> draft-ietf-dconn-domainconnect-02). 
> ...
>> Would it address your point? 
>
> Yes, I think so.
>
> However, I've forgotten the concrete case that led to it. There was 
> something concrete, this wasn't abstract what-if.
PK> this one 
https://mailarchive.ietf.org/arch/msg/art/FtU0CkWKZiVE_QOMnVvCu9hacgg/
>  So I'm unsure what happens if/when one of the two want to update the 
> records later.
> Intuitively, the sequence seems correct:
>
> 1. Someone needs a record, and gets it, and depends on it.
> 2. Someone else needs the same thing, and depends on it.
> 3. One of them want to change it a year later.

PK> Domain connect has no explicit notion of "change" of a single 
record, but rather an update to the template instance (and only for 
providers who track them).
If one provider makes an update , the reference to the existing record 
of the template would be removed but the record will stay as still 
having reference to the other one. Then the changed record with run 
against conflict resolution. If no conflict then all fine. If there is 
one, the end user has to make a call. At least this is very transparent 
what happens.

>
> Point 3 may lead to an error. However, if it does, there really is an 
> error, dns/dconn is just the bearer of bad news
PK> Not really an error. See above.
> .
>
> I'll read the draft and have a think.
>
PK> great to hear further remarks.

Kind Regards,
Pawel