Re: [dnssd] SRP: name conflict while not knowing which name conflicts
Ted Lemon <mellon@fugue.com> Wed, 12 October 2022 13:43 UTC
Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DD8C14F6E7 for <dnssd@ietfa.amsl.com>; Wed, 12 Oct 2022 06:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_eCY3EgaD85 for <dnssd@ietfa.amsl.com>; Wed, 12 Oct 2022 06:43:06 -0700 (PDT)
Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A49AC14F607 for <dnssd@ietf.org>; Wed, 12 Oct 2022 06:43:06 -0700 (PDT)
Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-35ad0584879so155607887b3.7 for <dnssd@ietf.org>; Wed, 12 Oct 2022 06:43:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GoC9qktBsPAvorXDzrbk3u7d8HtSYobF0cLUESNf0so=; b=CdZaXUWvkQ4ul34gqiOhcbgpdysweMOOg8OLXXXN6PGFP4b2S7FO2nJEGwnpnlOHYA IBjkHl/NmjLyPcz0JYHVn2YIlpCRDCS8zfQ6UlHYOdOoWYtzQGMqbZikYEtRr6aV1RUu bkBva6TlXC0Njbvp8mWUojrXYLxaM47wW2PTCoU3++Wgidmw5R8vRC9zLZWiHLKl8x6l hteuNYFVkq/LGobs5JlccFVOQ5KvHxVp6DiAMw7KIE20doFlU4gxFbk4Vg423aR8XGEk 7ca/2Olju2dQeDSGeW0i7Pb1/mrG9D2MZocxcR12F6i49W5JVmUNLxbdYMSp4evrnhwK H6tA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GoC9qktBsPAvorXDzrbk3u7d8HtSYobF0cLUESNf0so=; b=3Aw7YxxY/NTH3toSpvsZG14SIJeX/dc6ldg2T30ObPvoArpFt2OOvSL77nGYQhYJqt rp5FV029R+YJiihD3mh3jUNErdD8OjkZaLo6CcO2PC7hvjf7p2rN4qplWfAjBsx+H65p v3e9C1g9xHUtBHGR+58XhBCguSKG8Z/1Iv12IIDRly0Z6whGyYHRiG22lklGATaFBwF+ XbpvaNAqoTNqbJClQR9C7TQskHpjKsv2rnOtUl+perOu5TNFj+4OLnm/8x3WQ18hZmyN S4REL5KwZcMgo3kZ6A0gkVE3BkhIttBMxAOe1VWCjiQ+K7jRUgTTzEN1IJYtMYoiAaMP VGAw==
X-Gm-Message-State: ACrzQf2ez7ij89wKXjWG3ZvcTf19U3/YzdZpH/k8yOP2PmzNJ8+GM5bh 6sLIOkBPOnqoAQyO9rqU5o21zmDNdokZXWyYyXiSWeeYdzxwAA==
X-Google-Smtp-Source: AMsMyM50gGNr7KGVutLFwZtI8rD+eOfhs3U+nF82Yt6Vf/mh0aY0HgKbFnG2OKVgtlMU5Lpo5Nq72X1xdHxiaiHK0oE=
X-Received: by 2002:a81:a087:0:b0:357:3a80:1fca with SMTP id x129-20020a81a087000000b003573a801fcamr26280563ywg.481.1665582184747; Wed, 12 Oct 2022 06:43:04 -0700 (PDT)
MIME-Version: 1.0
References: <DU0P190MB19780211A2F50F5E66BCE005FD519@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAJ5Rr7Ys+bmFiP9j3ebptBEZHXX+6rzkTRaFHr7_mmgVZb9sZQ@mail.gmail.com> <DU0P190MB1978E63F6C69807759C10FD0FD519@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CADyWQ+EMf3XTLuZWupLNeGwQ8Gaqd-A7BvyAs4wK-fT7M5zk6Q@mail.gmail.com> <DU0P190MB19786D6BDA466AC9667087C9FD519@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1k0si52gnCHz_A-coitbVG8AHovLaWpJXBaWiN3to0j+w@mail.gmail.com> <DU0P190MB19782E66596D8C646D5A3F89FD519@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1kOLHnKkarjfuOeqRgS0Rz8n219Av37xbLxbakwHhS5-g@mail.gmail.com> <CADyWQ+Hzg44nbJ49PwwMsK9cPVXtao2aFeiDr7n0UyCt7JXj2A@mail.gmail.com> <CAPt1N1kUPKkSdfZj2P23fJ_2OQmRR3nQyE+O+Q90aV7qKDcHbw@mail.gmail.com> <DU0P190MB1978522CFB7784B2BA16C1F0FD519@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1mUYCyjakENUb460kEf07f0UdXoAtsLn1weHBKvaMWfOQ@mail.gmail.com> <DU0P190MB1978C9983DA1982AC70B2874FD519@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1=gLgMp17qBNgxpj02Eiu5Yc7ye55aFE-FhbF0E95yRvA@mail.gmail.com> <DU0P190MB1978983616C9CB8DE1EF2ACEFD529@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1ngszRzbfM8_r51vhCg=wUxA0nk=cOheXp=A6H204DvYA@mail.gmail.com> <CAPt1N1k8wc7BdvoBN7kvfLDzDmr5j528cUJs2pwquXeUf69-fw@mail.gmail.com> <DU0P190MB1978701466950B540AAD2326FD5B9@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1mWZO6FJq5zt7V+tCiO-JYdEH_xjYDaW+aTHZsaUPqu3w@mail.gmail.com> <DU0P190MB1978847FFCB4FF63AC6BB0F8FD229@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <DU0P190MB1978847FFCB4FF63AC6BB0F8FD229@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 12 Oct 2022 09:42:28 -0400
Message-ID: <CAPt1N1kCZSN5Kjmxqm-TJw5VT=xDR=COumUpdFVN=9YCUWsXEg@mail.gmail.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: "dnssd@ietf.org" <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000776f1c05ead69213"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/KvkkRxEcRZWScZNfTs0xJPxJkTo>
Subject: Re: [dnssd] SRP: name conflict while not knowing which name conflicts
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Oct 2022 13:43:10 -0000
That's great! Thanks for the timely review! On Wed, Oct 12, 2022 at 9:35 AM Esko Dijk <esko.dijk@iotconsultancy.nl> wrote: > Agree with the proposed text and the -16 updates. This should now resolve > all the review comments I made. > > > > Esko > > > > *From:* Ted Lemon <mellon@fugue.com> > *Sent:* Thursday, October 6, 2022 16:48 > *To:* Esko Dijk <esko.dijk@iotconsultancy.nl> > *Cc:* dnssd@ietf.org > *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name > conflicts > > > > I've updated section 2.3.5 as follows: > > > > <t> > - The status that is returned depends on the result of > processing the update, and can be either NoError or ServFail: all > + The status that is returned depends on the result of > processing the update, and can be either NoError, ServFail, Refused or > YXDomain: all > other possible outcomes should already have been accounted for > when applying the constraints that qualify the update > - as an SRP Update.</t> > + as an SRP Update. The meanings of these responses are > explained in <xref target="RFC2136" section="2.2"/>.</t> > + <t> > + In the case of a response other than NoError, <xref > target="RFC2136" section="3.8"/> specifies that the server is permitted > + to respond either with no RRs or to copy the RRs sent by the > client into the response. The SRP Requestor MUST NOT attempt > + to validate any RRs that are included in the response. It is > possible that a future SRP extension may include per-RR > + indications as to why the update failed, but at present this > is not specified, so if a client were to attempt to validate > + the RRs in the response, it might reject such a response, > since it would contain RRs, but probably a set of RRs > + identical to what was sent in the SRP Update.</t> > </section> > > > > (The text indicating that the only possible error was ServFail was of > course incorrect. I think the text was originally intended to talk about > RCODEs other than those mentioned earlier, but the text was pretty > confusing when I read it, hence the update.) > > > > On Mon, Oct 3, 2022 at 10:02 AM Esko Dijk <esko.dijk@iotconsultancy.nl> > wrote: > > Yes, would agree to adding a sentence on that. Best places in the document > for this are: > > > > 2.2.5.2 “Name Conflict Handling” (close to the YXDomain response > explanation) , or > > 2.3.5 “SRP Update response” (covers SRP-specific aspects of the > response, in general) > > > > Regards > > Esko > > > > *From:* Ted Lemon <mellon@fugue.com> > *Sent:* Monday, September 26, 2022 16:59 > *To:* Esko Dijk <esko.dijk@iotconsultancy.nl> > *Cc:* dnssd@ietf.org > *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name > conflicts > > > > RFC 2136 has some specific language here, so we can mostly refer to that, > but I think to address your concern we should explicitly say that any > records sent in the response should be silently ignored. We can specify > some additional behavior in a follow-on document if it makes sense. > > > > Op ma 26 sep. 2022 om 10:50 schreef Ted Lemon <mellon@fugue.com> > > Maybe we should write some conformance tests that send unknown options. :) > > > > But yes, I think you’re right. > > > > Op ma 26 sep. 2022 om 10:49 schreef Esko Dijk <esko.dijk@iotconsultancy.nl > > > > Hi Ted, > > > > I would still be in favor to insert a sentence about the possible use of > the answer records (in case of an error) in the future. > > > > > But right now we have no text at all about how the client interprets rrs > in the response, so I think even this is unnecessary. If it does something > with them, it’s out of spec. > > > > In my years of experience with how software development works, an > implementer somewhere is bound to check incoming messages very precisely > against what the implementer thinks it should be -- never mind the spec. > The robustness principle isn’t automatically applied, now in times of > security breaches everywhere. It’s rather becoming “if the input looks > slightly different from the usual, it must be wrong” and extra checks are > coded in everywhere without thinking about extendibility. I have seen > implementations where nice TLVs are defined for extendability, and then > Version 1 implementations discard any message received with an unknown TLV > type, such that the future Version 2 implementations could never use a new > TLV type anymore, i.e. the extendibility that was defined doesn’t exist > anymore in practice. > > > > Especially in our case since the base spec DNS Update precisely tells > what the response fields can be, we have to say here that SRP deviates: > that it can contain something else. (Which is then defined in the future, > maybe, or maybe not.) > > > > But if the rest disagrees for good reasons then we should not add any > text. This additional text would have zero code impact. > > > > Esko > > > > *From:* Ted Lemon <mellon@fugue.com> > *Sent:* Friday, September 23, 2022 18:47 > *To:* Esko Dijk <esko.dijk@iotconsultancy.nl> > *Cc:* Kangping Dong <wgtdkp@google.com>; Tim Wicinski <tjw.ietf@gmail.com>; > dnssd@ietf.org > *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name > conflicts > > > > I just have no idea what problem you are solving here. And no, we do not > know how to represent this in the response. > > > > I get that you have some ideas about how this could be used, but that’s > not what I’m asking. What I’m asking is, what /problem/ does this solve? > What bad thing happens if we don’t do this, and how does doing this make it > better? And to be clear, by “problem” I mean “what bad experience will the > user have that will be less bad if we do this?” Having to rename at all is > a catastrophe. We might make that catastrophe trivially smaller. How does > that materially benefit the end user? > > > > As for representation, right now the response can contain the update, > verbatim. We need to specify in detail a response format that the client > can unambiguously interpret as listing names that were in conflict. I’m not > saying this is hard, just that we have to write it up, implement it, test > it, feel confident it works. > > > > What we have in the document now describes what we have implemented and > extensively interop tested. To meet that standard for this proposed update > is at least a year of work. > > > > So if we want to do this in this document, we need a really, REALLY, good > reason, not some ideas about how it could be used. > > > > But the bottom line is that this is harmless. If it’s useful to do this > year’s work, let’s just do it in a follow-on document. But I really > strongly urge you not to insist on doing it in this document. It’s not as > small a change as you are imagining. > > > > Regarding preparing the client for this, the new spec would say how the > client should handle this, so I don’t think that’s necessary. An existing > client can be expected to ignore whatever is sent by a new implementation. > > > > I guess we could say that the client MUST ignore any RRs in the response. > But right now we have no text at all about how the client interprets rrs in > the response, so I think even this is unnecessary. If it does something > with them, it’s out of spec. > > > > Op vr 23 sep. 2022 om 11:42 schreef Esko Dijk <esko.dijk@iotconsultancy.nl > > > > > It took you ten paragraphs to explain what the client would do with this > information > > That was just explaining the benefits. Hence the more, the better. It’s > just a perfect solution if you just want to be prepared for all possible > futures with a minimum of effort and no nasty dependencies. It’s the > equivalent of our local high school recommending yesterday for pupils to > take the “STEM” profile in case they don’t know yet what future job to do > because it leaves a maximum of options still open. Only, less difficult to > execute ;-) > > > > But we can also do without solving this particular issue and avoid another > WGLC – because we do have simple name-change solutions for the SRP client > that work already (as you also indicated). So if we foresee potential > issues/complexity here maybe better leave it for a later time. > > > > About the format definition: we already know how to include records into a > DNS response so don’t agree to your point there. But true, it will take > more than 1 sentence to explain such a new feature – maybe an entire > subsection to do it right. > > > > Can’t we just say the SRP client MUST be prepared to receive something in > Additional records of YXDomain, whatever it is? Just to pave the way for > our potential future new draft. (Otherwise the SRP client may ignore the > response as “invalid” and not heed it.) > > That would only be one sentence and requires no code. > > > > Regards > > Esko > > > > *From:* Ted Lemon <mellon@fugue.com> > *Sent:* Friday, September 23, 2022 17:14 > *To:* Esko Dijk <esko.dijk@iotconsultancy.nl> > *Cc:* Kangping Dong <wgtdkp@google.com>; Tim Wicinski <tjw.ietf@gmail.com>; > dnssd@ietf.org > *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name > conflicts > > > > Eskimo, I beg to differ on the idea that this change is simple. It took > you ten paragraphs to explain what the client would do with this > information. We don’t know how to encode it in the response, so we have to > invent that. We don’t have any implementations of it. So its a really big > deal to suggest this change now, after WGLC. If this is important, I think > someone who is interested should write up a draft proposing a solution and > ask the WG to adopt it. > > > > Adding this to SRP now will mean that SRP standardization will take about > an additional year, if we move very fast. I don’t think this is remotely > worth it. > > > > Op vr 23 sep. 2022 om 10:24 schreef Esso Dijk <esko.dijk@iotconsultancy.nl > > > > Fully agree that we should not do the “renaming by the registrar” part. > There’s some additional complexity implied by this and things that may > break interoperability. > > > > > the leftmost label in the service instance name is the same as the > leftmost label in the hostname > > This is how some implementations may work, but there’s many others that > don’t. So we can’t make generic assumptions on naming choices. > > In any case a smart SRP client that picks its names like this will simply > rename both – no additional complexity for the client then. > > > > Despite this, it is fairly simple if we say the SRP registrar SHOULD > insert any conflicting record(s) that it knows about into the response. As > I argued before, this doesn’t change any of the procedures we have defined > in SRP so far. > > > > And it leaves a great amount of freedom to implementations without > apparent disadvantages, and without interop problems: > > - A SRP client that doesn’t want to bother parsing the SRP Update > response, can just ignore the Additional records in the YXDomain response. > It can apply its strategy of “change both names” for example as discussed > above. > - An SRP registrar that is on a constrained device, or just doesn’t > want to bother, can include 0 Additional records (equivalent to saying “I > don’t know what the conflict is”) which is acceptable too. > - An SRP registrar that is an existing implementation that people > don’t want to change, is still compliant. > - An SRP client that is an existing implementation that people don’t > want to change, is still compliant. (Maybe it takes some more retries to > get registered – but that’s no big problem.) > - If in the future an SRP client gets upgraded to a “smarter” client > that can detect the conflicts enlisted in the YXDomain response, it may > become more efficient. This upgrading is independent of servers’ upgrading > or not. > - If in the future an SRP server gets upgraded to a “smarter” server > that can returns conflicts in the YXDomain response, things may become more > efficient. This upgrading is independent from clients’ upgrading or not. > - If the Matter approach to names wins and conflicts hardly occur for > this reason, and hence no-one implements the conflicting-records feature, > then nothing is lost – we just have a small bit of junk-DNA like text in > the SRP RFC. > > > > So the idea is to recommend returning known-conflict records FYI to the > client and leaving the client free to pursue any naming strategy. > > > > Esko > > > > > > > > *From:* Ted Lemon <mellon@fugue.com> > *Sent:* Friday, September 23, 2022 15:59 > *To:* Tim Wicinski <tjw.ietf@gmail.com> > *Cc:* Esko Dijk <esko.dijk@iotconsultancy.nl>; Kangping Dong < > wgtdkp@google.com>; dnssd@ietf.org > *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name > conflicts > > > > Okay, as I dig deeper into this, I'm realizing that things have changed /a > lot/ since we had this conversation. First of all, for Matter accessories, > name changes by the server are simply unacceptable. So the idea that we're > going to signal back to the SRP client that we changed the name is no > longer really necessary, because we aren't going to change the name. The > current Apple Advertising Proxy implementation never does renaming. > > > > If there is a name conflict, we report it, but we have done a /lot/ of > work to avoid gratuitous name conflicts, and I think that that work is > actually what we should be relying on here. Effectively what we've done is > to make the advertising proxy look more like an authoritative name server, > and as we agreed in the discussion Kangping found, we are never going to do > this when the SRP server is an authoritative name server. > > > > What we've done here is the TSR draft and the SRP replication draft. The > TSR draft prevents gratuitous name conflicts when two advertising proxies > are not doing SRP replication. The SRP replication protocol provides a way > for multiple advertising proxies to sustain a consensus, so that conflicts > don't occur. Between these two drafts (really, between their > implementations) we no longer see renaming happening with our advertising > proxies. > > > > As we move more toward unicast DNSSD as the baseline, with mDNS as the > exception, I think that the likelihood of conflicts will drop further. > > > > My point is, do we really want to add this complexity in SRP? What is the > problem we are trying to solve here? Most of the time, the way names are > chosen is deterministic—the leftmost label in the service instance name is > the same as the leftmost label in the hostname. And so if there is a name > conflict on one, it's going to be on the other as well. > > > > So what I think we should actually do is leave the document the way it is. > Doing what we're talking about here will create a great deal of complexity > in the client and in the server, at a very late stage in the development of > the protocol, with no obvious benefit. > > > > Thoughts? > > > > On Fri, Sep 23, 2022 at 9:27 AM Tim Wicinski <tjw.ietf@gmail.com> wrote: > > How about just the name(s) attempted to register with that request > which are in conflict? > > > > I vote for being explicit on the minimum the SRP registar needs to do. > > > > also, not a chair but write up all the text changes and make sure the WG > has no issues with that. > > > > On Fri, Sep 23, 2022 at 9:14 AM Ted Lemon <mellon@fugue.com> wrote: > > Okay. I ask because we should be explicit. > > > > Chairs, how do you want to approach this? I think this is a WG consensus > that I failed to put into the document, but we didn't last call on it, so I > don't know that it's _actually_ consensus. Do we need a new WGLC? > > > > On Fri, Sep 23, 2022 at 9:12 AM Esko Dijk <esko.dijk@iotconsultancy.nl> > wrote: > > > So it can certainly respond with a list of the names on which it found > conflicts, but the list might not be able to be made complete > > > > I think it should respond at least with the names that it knows are in > conflict (based on its internal database of SRP registrations for example). > So, 0 or more records in the response. Zero records is our current > specified baseline. > > An SRP registrar implementation that wants to put in more work can > certainly do so – we don’t need to standardize here exactly what it should > do for that. > > > > Esko > > > > *From:* Ted Lemon <mellon@fugue.com> > *Sent:* Friday, September 23, 2022 14:56 > *To:* Esko Dijk <esko.dijk@iotconsultancy.nl> > *Cc:* Kangping Dong <wgtdkp@google.com>; Tim Wicinski <tjw.ietf@gmail.com>; > dnssd@ietf.org > *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name > conflicts > > > > Aargh. Thanks for catching this Eskimo, and thanks Kangping for > remembering the conversation. I had completely forgotten, although I recall > it now of course. > > > > One problem with this approach is that it will not be the case that the > SRP server necessarily knows all of the names that are in conflict. So it > can certainly respond with a list of the names on which it found conflicts, > but the list might not be able to be made complete without more work. Do we > want to require it to do that work? > > > > Op vr 23 sep. 2022 om 08:07 schreef Esko Dijk <esko.dijk@iotconsultancy.nl > > > > Hi Tim, > > > > > I don't think an update to 2136 is needed here, as section 2.2.3.1 > describes the differences with an SRP registrations and 2136 Updates, > > but this response should be tested against a DNS update response. > > > > Clear, we can just add a bullet in 2.2.3.1 then as plain DNS Update isn’t > updated by this draft. What’s important then is that the server, when > receiving a DNS Update that is not an SRP Update, will not use the new > mechanism of including the conflicting record(s). Only do this for an SRP > Update. > > And for testing: do you mean sending the “new” type of YXDomain response > to a plain DNS Update client and see what happens? That seems not > necessary if the SRP registrar is careful in using the “new” response > format only for SRP clients. > > > > Esko > > > > > > *From:* Tim Wicinski <tjw.ietf@gmail.com> > *Sent:* Friday, September 23, 2022 12:28 > *To:* Esko Dijk <esko.dijk@iotconsultancy.nl> > *Cc:* Kangping Dong <wgtdkp@google.com>; dnssd@ietf.org; Ted Lemon < > mellon@fugue.com> > *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name > conflicts > > > > > > > > On Fri, Sep 23, 2022 at 4:32 AM Esko Dijk <esko.dijk@iotconsultancy.nl> > wrote: > > Thanks Kangping, > > > > It looks like including the conflicting name records in the Additional > section is a good base solution and also easy to describe in the SRP draft, > which does not impact the states & procedures of registrar and client. > > It’s just additional helpful information the client may use to compose the > retry Update. The part about renaming by the registrar, on behalf of the > client, seems more tricky and may impact states & procedures which were > just WGLC-reviewed now. > > > > If we use the Additional section for a YXDomain response, this may require > a formal update of RFC 2136 (3.8) since DNS Update only allows a server to > repeat all records in the (error) response or to exclude all records. > > > > Esko > > > > > > Esko, > > > > I don't think an update to 2136 is needed here, as section 2.2.3.1 > describes the differences with an SRP registrations and 2136 Updates, > > but this response should be tested against a DNS update response. > > > > Kangping, I believe this is your workflow description - I pasted it here > to assist in my readings. > > > > 1. If a name has already been registered on the SRP server or a > name conflict error is returned by the Advertising Proxy: > > the SRP server responds with the RR that includes the conflicted name. > > If the client sees such records, it knows the conflicts on the SRP > server and will retry with a new name. > > > > 2. If a name conflict is reported to the SRP server after the SRP > update transaction has been committed: > > The next time the SRP client registers, the SRP server responds with a > CNAME record which includes the new name. > > If the client sees such records, it knows the conflict on the > multicast link and will accept the name or retry with another name. > > > > https://mailarchive.ietf.org/arch/msg/dnssd/cUJBXN9WXBguPKtTYgPYq4bo4pQ/ > > > > Tim > >
- [dnssd] SRP: name conflict while not knowing whic… Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Kangping Dong
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Tim Wicinski
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Tim Wicinski
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Nathan Dyck
- Re: [dnssd] SRP: name conflict while not knowing … Chris Box
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Michael Richardson
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon