Re: [DNSOP] SVCB without A/AAAA records at the service name

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 26 January 2021 12:52 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F44A3A0927 for <dnsop@ietfa.amsl.com>; Tue, 26 Jan 2021 04:52:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkLJJhiZT5xY for <dnsop@ietfa.amsl.com>; Tue, 26 Jan 2021 04:52:25 -0800 (PST)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17AE3A0ADD for <dnsop@ietf.org>; Tue, 26 Jan 2021 04:52:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=12650; q=dns/txt; s=VRSN; t=1611665545; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=UtqG8XAusvUwjLOQimE51xIqVbSXqRf3Xj0Cr2hdMTI=; b=FwTLWqHN9GHjx5PCB9QgeIg7vajsjNiCeUWAxone7DICHY/6ygMG9P8l hL7YSUeavfv27/ZNcY7GD47G64XSoluYS3IbVuR6pohU7+ln5/RBpRH32 io6IY0eP3I/HHR1xujjjWurzYgZhubKR1xvL1VengmsBbQXi3Vy6VZHxN g1BDMcrAiol736xQ86kgnowH2KrL9B1iIF2raxmJnE2bPunxCeYoetjGA 6q1GNhjBsoi7IYPXWatFNFyBIlgdrwqkGK1qSiCyEwKzzTRV9vmU4YAKE 3NhytvTbbp/Tt47nc5MiMeWaPyUP2kkjJpLBMvYjIvvlJQM5S6l+NNgDj A==;
IronPort-SDR: CtmUA6xk/houK5C4rpTkZg/W9/w3+TgWa8qmEdsvottl5vMFOniSmqbnU4/a15LJnYM8TJpdeR jNNkbmXrNECbEbOTEAhCJL5u/BQ/yqg+SymlI8urzmUkNa1tmlm1U0gNkVlLyRiw0IcXQoR3ba SIqrmaGBMRPSw/NcVDV8ovSUxD6s4QHN2f3NO6Wcb5KlF+orrCeRAfPpT0YJZJMZb/2P5eNFYQ JQjfsVArbwANRO10WiUoEtk5Db9dA5RQ/vNdTox2h4tvdKd1uuM7gDpjNzS1w9GaD61sLv7bPx Iqg=
X-IronPort-AV: E=Sophos;i="5.79,375,1602561600"; d="scan'208,217";a="4759975"
IronPort-PHdr: 9a23:O+8RYxY2TP30rMAohiYXCy3/LSx+4OfEezUN459isYplN5qZps26Yx7h7PlgxGXEQZ/co6odzbaP4ua6BCdbvN7B6ClELMUTEUddyI0/pE8JOIa9E0r1LfrnPWQRPf9pcxtbxUy9KlVfA83kZlff8TWY5D8WHQjjZ0IufrymUoHdgN6q2O+s5pbdfxtHhCanYbN1MR66sRjdutMZjId/Lqs90AXFr3tHd+lYxW5jOFafkwrh6suq85Nv7iZdt+g9+8JcVKnxYrg1Q6FfADk6KW4++dfltQPETQuB53scVnsZnx9VCAXb7x/0Q4n8vDLiuuVyxCeVM8v2TaspWTu59KdkVAXoiCYcODEn9mzcl9F9g7haoBKloBx/3pLUbYSIP/dwYq/RYdUXTndHU81MVSJOH5m8YpMPAeQfIOhYs4fzqVgArRS8BAmjGOzgxyRSiXPq3603yfgtHR3E0QEmAtkAsG7UrNLwNKoKX+y7zq7IzTHHb/xI3zfy85bHfQwiof2UQLl+bNbeyU4zFwPZgFmbtIvoPyiV1uQKt2ib6/RvVeS0hGE5tw5xoSOixtkyhYnTh4IV0VHE9Sp/wIovOdK4T0t7bMeiHZBNuC6UK5F4Tdk+Q2F0pik60LsGtIalcSUW1ZgpyR3SZv6bf4WJ/h7uVuifLzh6iX9mdr+yiQq//FS+xuD8UsS631dHoyVFn9TRuH4ByhPd5MeFR/Zg+EqqxDWB1xjL5+1ZPUw4j7fXJpwvz7Iqi5YesUrOEjX5lUj1lKOaa1ko9vK15+nlfrnqvIKQOoB3hw3kL6gjmcqyCvkiPAcURWiU4+G82aXm/U3+XbpFkOU7krLcsJDGPcQbobO5AxNN3oYj9Rm/CzCm3cwFkHcbNFxJZRKIgZDmNV7PPPz0EO2zg0qwnzds3fDGJqftDY/QIXTZjrfhZ61960hGxAUvytBf4opYCrAHIP3tRk/8rMHUAgMjPwCpwevqBs9x2p4eVG+BGKOUP6DfvUeN5u01IumMYIEVuCz6K/gg//Puln85mVgZfamtw5QXbmu3Eep6LEWaenfsnMkOEX0LvgolTezqh1uCXSRPaHa1WqIw/is7B56+DYffWoCth6SM0zylEZ1TfG9GEUyDHG/neomYVPcMbyWSIsBlkjMaT7SuV4gh1RS1uQDnzrpoNPDU9TECuZLiytd1++PTmQs19TxuAMSXy3uNQH1snmMUWz8227hyoUlhylqY1ah4hPJZGsJV5/NVSAc6MobczuxgB9D0RA3BYs+DSEy6TdW+HTExUtUxzscTbEZ7ANWiiQjD0jGrA7ALi7yLCoY48qXG33j+dI5BzCOM3qQkhkItF5cXOmqhiapysQPUAqbFlkyDnOCreLgSminX+y3LmWCDuUhDW1ssCarCWn8baw3dqtHR6kbLVbToCLk7PE1G08HUeYVQbdi8x3VBQPPuPt7TaGH101y7AgqUjPvYd4rtf2EQ2i/QA0ssjQ0J/G2HOg54DSCk9TGNRAdyHE7iNhu/udJ1r2m2Gxc5
X-IPAS-Result: A2G2CgC+DxBg/zCZrQpiHQEBAQEJARIBBQUBgg+BI1MrgQCBOQqENpFXA5xBCwEBAQEBAQEBAQgBLwQBAYRKAheBYyY4EwIDAQELAQEBBQEBAQEBBgMBAQEChk8Lgjgig3YBAQEBAyMKTBACAQgRBAEBKAMCAgIwFAkIAgQOBQiDH4F+slt2gTKFWYR9gTiGewGGQkGBQj6BEYMZPoJdBIITgmOCYASBVIIqImRXDgEcKoswhGUrgnqHNSudUAMHgneVWoYMK6J4jyWEeZ0EhFICBAIEBQIWgW2Be3CDOVAXAg2OWI4SdAI1AgYBCQEBAwmLBDFgAQE
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 26 Jan 2021 07:52:23 -0500
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.2106.006; Tue, 26 Jan 2021 07:52:23 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "bemasc=40google.com@dmarc.ietf.org" <bemasc=40google.com@dmarc.ietf.org>
CC: "mt@lowentropy.net" <mt@lowentropy.net>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] Re: Re: Re: [DNSOP] SVCB without A/AAAA records at the service name
Thread-Index: AQHW82YJnbSbRisPREuTWoRaQw885qo520Qg
Date: Tue, 26 Jan 2021 12:52:23 +0000
Message-ID: <337dca34a82641e68d55a1640dceed4b@verisign.com>
References: <2e1054a0-5a7a-4d62-92a1-095217af82bb@www.fastmail.com> <CAHbrMsCaVER+xDjznjRK4cSjqc+g855GNV2QCfewvCqh=E1FMw@mail.gmail.com> <87098be5-765c-4481-b990-bdb2c936173d@www.fastmail.com> <CAHbrMsCu1bYcEuT2R3g5M9aUBQguVeWhiyZpDH=JzSEPpc=iqg@mail.gmail.com> <45895deb-7432-4ad7-bede-107bf6e1973e@www.fastmail.com> <CAHbrMsDFuKNMrvi03VjK_eSio5N1w6eAtRpOMx3NdSYu-f_5Yg@mail.gmail.com> <4b59e60b-f8b0-493b-97b2-210d5541a19d@www.fastmail.com> <CAHbrMsD0ZAXX034b952rPM=3M6D2Ea_m373OmJQeOqqkTPvBPg@mail.gmail.com> <5e619af2c4834afb8ec687e13b8f042e@verisign.com> <CAHbrMsCaCOrqXqBYx3iEbXsSXSJFdiHWw+pDNz7YS_Ahb_-UyA@mail.gmail.com> <3e819f32679c403489b4b01968159acf@verisign.com> <CAHbrMsAt1usc0MFAgL+p7bLb2e3nScyMyoy35T1NAWaumEH_RQ@mail.gmail.com>
In-Reply-To: <CAHbrMsAt1usc0MFAgL+p7bLb2e3nScyMyoy35T1NAWaumEH_RQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_337dca34a82641e68d55a1640dceed4bverisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Jd3BmST8LXf4B0PgucKr_3R1YyA>
Subject: Re: [DNSOP] SVCB without A/AAAA records at the service name
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2021 12:52:29 -0000

From: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Sent: Monday, January 25, 2021 5:04 PM
To: Hollenbeck, Scott <shollenbeck@verisign.com>
Cc: mt@lowentropy.net; dnsop@ietf.org
Subject: [EXTERNAL] Re: Re: Re: [DNSOP] SVCB without A/AAAA records at the service name







On Mon, Jan 25, 2021 at 8:06 AM Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org<mailto:40verisign.com@dmarc.ietf.org>> wrote:

      [SAH] We need to think about the impact on the servers that have to respond to those queries, too. Sending unnecessary queries to the root and TLD servers puts a load on those servers that can have an impact on every client/resolver that needs to be able to reach them.



   This is important, but I don't think it's applicable here.  The various options under consideration all impose the same amount of load on root and TLD servers.

   [SAH] So if some number if queries X and some number of queries Y are processed in parallel, the value of X + Y will be the same as if those queries are processed serially?



   Yes, if the SVCB record uses the hostname as the TargetName, as suggested in section 10.2, then there are no additional queries; they are merely issued in parallel rather than sequentially.



   Regardless of whether the speculative queries are wasted, your question was whether they would impose more load on TLD or root servers.  If the domain's NS record is cached at the resolver, then they certainly will not.  (All queries will go to the authoritative nameserver.)  If QNAME minimization is applied, they also should not.  (They will all trigger the same qname-minimized query to the root and TLD, and a reasonably intelligent resolver shouldn't emit duplicate queries when one is already in flight.)



   If the NS record is not cached, and the resolver does not implement qname minimization, then perhaps it is possible that the additional queries could leak to the TLD, or to the root if the TLD NS record is not cached.  The behavior would be similar to speculative AAAA queries today.  (I'm not aware of these being a cause for alarm among root or TLD operators.)



   Note that this conversation only concerns hypothetical future non-HTTP protocols that rely exclusively on SVCB.  We are a very long way from any such protocol (1) existing and (2) having enough usage to concern the root or TLD operators.

   [SAH] Thanks for the clarification, but I have to disagree that it’s not a concern for operators. We would be wise to pay attention to such things long before use causes measurable impact on those servers.



   Scott