From nobody Thu Jan 13 16:47:09 2022 Return-Path: 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 451183A1197 for ; Thu, 13 Jan 2022 16:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HK_RANDOM_ENVFROM=0.781, HK_RANDOM_FROM=0.999, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 Gcy2B5gDZ7jz for ; Thu, 13 Jan 2022 16:47:00 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp34.apple.com (rn-mailsvcp-ppex-lapp34.rno.apple.com [17.179.253.43]) (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 E15E53A119B for ; Thu, 13 Jan 2022 16:47:00 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp34.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp34.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 20E0jc68023370 for ; Thu, 13 Jan 2022 16:47:00 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : content-transfer-encoding : mime-version : subject : message-id : date : to; s=20180706; bh=Lm2kRy6EsgYhzJakZQJYrNEWIAVDGQKMqfNLFLDd3Uc=; b=O8SY/uSI/E05VtyIwM/BmSsyBUDJCJBf9QHAYjcInB+It42ATPb8kwcn33F2oR5loiRr xLKJx7YCqdl3b7KXpwtQp3aC+vrnj56IqitysXT60R8pS4pQUcEX4c6A1rkS0hc68GAh 3RcLOMz2XLX8/NuUmOJIFbp5FoSo6hS77Nrx094Hv4oVocuF/vYWIopWmaMjEk1MDb/v tZIYQ1zMcxxePGi6vOo/dqJ6qlGsxH2KbNmtVDaNNhfaz2W3v87ts7SkpBP7Gxtphf2K H6SJIh783at8qPV3w/1FifWN4jPvshSRUoi5I2PACVDs9SOg+DbpLdUW9QYzgUBy1eor lA== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp34.rno.apple.com with ESMTP id 3dj44sacef-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 13 Jan 2022 16:47:00 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R5O00HT0CUC77J0@rn-mailsvcp-mta-lapp02.rno.apple.com> for dnsop@ietf.org; Thu, 13 Jan 2022 16:47:00 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R5O00700CRCPT00@rn-mailsvcp-mmp-lapp01.rno.apple.com> for dnsop@ietf.org; Thu, 13 Jan 2022 16:47:00 -0800 (PST) X-Va-A: X-Va-T-CD: f4439a1f3baad66c778bad7f442511f1 X-Va-E-CD: aa911e14551703a66c80061605208de3 X-Va-R-CD: d04ec9567f93fce21f84d80cd9d800ca X-Va-CD: 0 X-Va-ID: af265f9d-ef3b-4e69-a8b7-f31850ce161e X-V-A: X-V-T-CD: f4439a1f3baad66c778bad7f442511f1 X-V-E-CD: aa911e14551703a66c80061605208de3 X-V-R-CD: d04ec9567f93fce21f84d80cd9d800ca X-V-CD: 0 X-V-ID: 12ee2aff-3df9-4412-9ff6-16d40e0939ef X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-13_08:2022-01-12, 2022-01-13 signatures=0 Received: from smtpclient.apple (unknown [17.192.170.224]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R5O006N0CUCAE00@rn-mailsvcp-mmp-lapp01.rno.apple.com> for dnsop@ietf.org; Thu, 13 Jan 2022 16:47:00 -0800 (PST) From: Joey Deng Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.0.1.1.13\)) Message-id: Date: Thu, 13 Jan 2022 16:46:59 -0800 To: dnsop@ietf.org X-Mailer: Apple Mail (2.3693.0.1.1.13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-13_08:2022-01-12, 2022-01-13 signatures=0 Archived-At: Subject: [DNSOP] Why does RFC 4035 allows a security-aware authoritative name server to not send RRSIG RRs that a security-aware resolver can use to authenticate the RRsets in the response? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 00:47:03 -0000 Hello, In RFC 4035 3.1.1. Including RRSIG RRs in a Response, it says: > When responding to a query that has the DO bit set, a = security-aware > authoritative name server SHOULD attempt to send RRSIG RRs that a > security-aware resolver can use to authenticate the RRsets in the > response. A name server SHOULD make every attempt to keep the = RRset > and its associated RRSIG(s) together in a response. Inclusion of > RRSIG RRs in a response is subject to the following rules: All the statements above use SHOULD, which means RECOMMENDED, which = means that there exists valid reasons in particular circumstances to NOT = SEND RRSIG RRs with the RRSet in the response. However, the paragraph below it uses MUST: > o When placing a signed RRset in the Answer section, the name = server > MUST also place its RRSIG RRs in the Answer section. The RRSIG > RRs have a higher priority for inclusion than any other RRsets > that may have to be included. If space does not permit = inclusion > of these RRSIG RRs, the name server MUST set the TC bit. It would be very helpful if someone could help me understand this = SHOULD/MUST behavior difference 1. What are the particular circumstances in which a name server is = allowed to do that? 2. One case I can think of is truncation, is truncation the only = situation allowed to not include RRSIG? 3. If the name server is allowed to only include the RRSet, how could = the security-aware resolver fetch the missing RRSIG separately (A = specific RFC would be very helpful!)?=20 (I tried to use dig to send query for RRSIG explicitly, but it seems = that the name server will only return partial result or no result for = the RRSIG query, so I guess the result of RRSIG query is similar to the = result of type ANY query?). Thanks. -- Joey Deng