From nobody Wed Oct 7 12:27:12 2020 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 9334D3A00F7 for ; Wed, 7 Oct 2020 12:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 do6yG-dzI2uh for ; Wed, 7 Oct 2020 12:27:09 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD5D3A005E for ; Wed, 7 Oct 2020 12:27:08 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id k6so3680026ior.2 for ; Wed, 07 Oct 2020 12:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nTLg7ME3ty+NN0XAFwBDz8VMtj4in5nBKOnkIWjaPYo=; b=FgXNsEj+wIexvP8H6G7HndZjkKI0BkiAMFpdb5t985h0eeIJsmQheG6AHJRPbOHPPU 3XDMzEB1w7ZC16BWoXpGOCTkVGB2KQam9fnYm1HpKk5wEGpPyD7cChGbl5nV4XICgOeM 8CVVlj1CksZhJdH8w7tDgRN0cmZPajfrblyEzTcUXiC8ELpbaBstI6eXWm0TCl5NltJ2 tT5dbsQUseNkg8pUuQU87VfHU0JFrnhYmtTLjoBJeVKkSa9bkbrc0r8AbdnPOcL+i0Rt f5Pt96J5WTHJlbCSJOph6LsRXeIReo+nB1ggyoLeX3yUCKkPB7OddGzr5e86OaO8C/OC a5TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nTLg7ME3ty+NN0XAFwBDz8VMtj4in5nBKOnkIWjaPYo=; b=nblNzM3NezGZVRa+l2oK0FJfznUsnSPJQkTl2SgOkwJget9YtFn6PazSXM1piemPCv p88olbU2r9mAE8TctbMvy192kC686k/oAqbP85zeY0lnPXy9oAmLUMkeNMKaCbYkmvBo 6bPZ1GVG6eahGjfPwnitY+7P+27qe+KYTl3VSKKrIQfeAKKzkm6J+qn38/XBb47JH2/j yDJLzjeGY7MQcwfL9RRLh/Idbgf/p3pqysDUHhnSNkvkXx8NF7nHuYrmkdK1cv9ytgGi h1dXmPJrORbsElaVxTvxDG/uzqFTu8r0P1Ns3E7+dqkVhIwVbqILzrga+FKosTKfqOm0 FwrA== X-Gm-Message-State: AOAM532JEA5XvUQY5FY2rd/ZJkDv02xRm969BlCOfsspzZzO5ZYjg14U WnxhCaVtt2WBAgaNx082w93bFwFm0rEzJcWWBT3EHw== X-Google-Smtp-Source: ABdhPJzfvtKMs0V1t+9k0RvYWn9nFc0CCm6NgM9zPvj5PBl5RGEwK7nrucwQa6teFS/fAFuCirNMhGHgSOfCI0Ua4m4= X-Received: by 2002:a5d:8787:: with SMTP id f7mr3474618ion.79.1602098827795; Wed, 07 Oct 2020 12:27:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Wed, 7 Oct 2020 15:26:56 -0400 Message-ID: To: Brian Dickson Cc: dnsop Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000008e606505b119b3be" Archived-At: Subject: Re: [DNSOP] SVCB and the specialness of _ 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: Wed, 07 Oct 2020 19:27:11 -0000 --0000000000008e606505b119b3be Content-Type: multipart/alternative; boundary="00000000000086fede05b119b344" --00000000000086fede05b119b344 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 7, 2020 at 3:20 PM Brian Dickson wrote: > > > On Tue, Oct 6, 2020 at 6:10 PM Ben Schwartz wrote: > >> On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson < >> brian.peter.dickson@gmail.com> wrote: >> >>> >>> Other than the syntactic brevity, is there any functional difference to >>> the client between a TargetName of "." versus a TargetName of "$HOSTNAME" >>> in the description above? >>> >> >> Currently, "." means $HOSTNAME for the HTTPS record (when no prefixes are >> applied). With the proposed change, "." would always mean $HOSTNAME when a >> ServiceMode record is returned directly for the original query. However, >> if the ServiceMode record is reached via a CNAME or AliasMode record, then >> "." does not correspond to (the original) $HOSTNAME. >> > > This presents two significant problems. > > First, this (what you write above) means that "." will not be guaranteed > 100% of the time to result in the "correct" value, if I understand > correctly. > I'm not sure what you mean by "correct". With or without this proposal, the expanded name for "." is well-defined. Second, the use of "." by whoever creates the ServiceMode record may not be > aware of how it is reached (e.g. by CNAME or AliasMode records not under > their control or that they are aware of or which may be added later). > The expanded name does not depend on how the record was reached. I'm merely trying to point out that, after an alias has been followed, any information about "$HOSTNAME" has been lost. ... > As you note below, "@" is available, and while perhaps not as elegant, is > handled in the authority server's loading of zone files, and never results > in dynamic processing or additional handling requirements. I.e. it achieves > maybe 90% of the intended "happy" result, but does so with 100% > interoperability after the zone itself is constructed and loaded. > My impression is that "@" is always, or nearly always, a zone apex. I expect that the majority of HTTPS and SVCB records will not be for the zone apex. Setting a ServiceMode TargetName of @ would instruct those records to use the A/AAAA records for the apex name. This strikes me as an unlikely configuration. > >> >> First, is the use of the standard zone file construct of "@", which only >>> exists within the zone master file, and gets substituted on import with >>> whatever $ORIGIN is. >>> >> >> Yes, the syntax already supports "@" and relative names when writing out >> a TargetName in the zone file. This is useful, but I don't think it has >> the effect of guiding users toward a good configuration. >> > > Brian > --00000000000086fede05b119b344 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 7, 2020 at 3:20 PM Brian = Dickson <brian.peter.di= ckson@gmail.com> wrote:


On Tue, Oct 6, 2020 = at 6:10 PM Ben Schwartz <bemasc@google.com> wrote:
On Tue, Oct 6, 2= 020 at 8:51 PM Brian Dickson <brian.peter.dickson@gmail.com> wrote:

Other= than the syntactic brevity, is there any functional difference to the clie= nt between a TargetName of "." versus a TargetName of "$HOST= NAME" in the description above?
Currently, "." means $HOSTNAME for the HTTPS record (= when no prefixes are applied).=C2=A0 With the proposed change, "."= ; would always mean $HOSTNAME when a ServiceMode record is returned directl= y for the original query.=C2=A0 However, if the ServiceMode record is reach= ed via a CNAME or AliasMode record, then "." does not correspond = to (the original) $HOSTNAME.

<= div>This presents two significant problems.

First,= this (what you write above) means that "." will not be guarantee= d 100% of the time to result in the "correct" value, if I underst= and correctly.

I'm no= t sure what you mean by "correct".=C2=A0 With or without this pro= posal, the expanded name for "." is well-defined.

<= /div>
Second, the use of "." by whoever cr= eates the ServiceMode record may not be aware of how it is reached (e.g. by= CNAME or AliasMode records not under their control or that they are aware = of or which may be added later).

The expanded name does not depend on how the record was reached.=C2= =A0 I'm merely trying to point out that, after an alias has been follow= ed, any information about "$HOSTNAME" has been lost.
...
As you note below, "@&qu= ot; is available, and while perhaps not as elegant, is handled in the autho= rity server's loading of zone files, and never results in dynamic proce= ssing or additional handling requirements. I.e. it achieves maybe 90% of th= e intended "happy" result, but does so with 100% interoperability= after the zone itself is constructed and loaded.

My impression is that "@" is always,= or nearly always, a zone apex.=C2=A0 I expect that the majority of HTTPS a= nd SVCB records will not be for the zone apex.=C2=A0 Setting a ServiceMode = TargetName of=C2=A0@ would instruct those records to use the A/AAAA records= for the apex name.=C2=A0 This strikes me as an unlikely configuration.

=C2=A0

First, is the use of the sta= ndard zone file construct of "@", which only exists within the zo= ne master file, and gets substituted on import with whatever $ORIGIN is.

Yes, the syntax already sup= ports "@" and relative names when writing out a TargetName in the= zone file.=C2=A0 This is useful, but I don't think it has the effect o= f guiding users toward a good configuration.
=

Brian=C2=A0
--00000000000086fede05b119b344-- --0000000000008e606505b119b3be Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAE/JGAv3XK3SRaKvGds QSwwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMDA5MDgy MzQzNTNaFw0yMTAzMDcyMzQzNTNaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7rjWsiqQSnXGFTvs/2JDygQFtWsgF+Ce W2I/wmwCuWH2eNUBYslyudWmJsUMi7IbeSsKHrvBI2P7k6sk5p6o3uFlomiFaDMqXcn76t5GNGym CmHm5KBWxc3LfyvR4C2/wg9oUwbL2xxXc6QQpWWE4ONn9NMHwNC396Ih5u7tcrH5eF49HbVarP5i TindWAOzz++JA3VC/1lIkqWvOt2BcBtxQDUnYp8sr8UnMF/6UqtCd0aHJnKkvYi4o8Qo5Qf3YgiJ DzADzBTf54o3NAI3hiIVKPvz1l0g78IcR29Bt9jUrE33qGzGB6HoY7Z8quhA/ngW2XjuLkIY1ZKX AwTXBQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUu687mSaB85ui VgNNFSUhtTljkxEwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAG9R1/y5PatVOc8xLrAmGgNO /Q4+lbJuHNwX3aIpOkM72Ot4r6r5/IFOSx1pMpmzvrECyy5YQzUGkHV4atuNq5YPPNMGa+XlaKSg oU2dA6RCD40dtwmrPxrKiGAfHPNvfmRvgnx9qxBKFPbKF/Tn8BwKSZCSvx33TnQRfqLUTcgrAarQ dF9Oc45moJrn4nVF0VTTPI6LVminvjg3tLgF2bny1N6CitQnb1t67vpYjeNpcXNIGQzEDaYI3WnK rVeZMcLSY+Z2dQH8HvVsA95vFCTywgiWKq5KxFqz/GdB6JhDWcIJIKCJVUyqD/Bjx47+e4Ye/FuD NDSYc+613Ozl3TkxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAE/ JGAv3XK3SRaKvGdsQSwwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIGWy9Fkwf3Vk no5iPKHSg3PDylcCTm0rDNGw0o6KwolRMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIwMTAwNzE5MjcwOFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQAlSpLVvVD6Na90xf5V/1cY5QSDtQVm kN2qJx7en4Se7BVXPiIQtci7s3+NIjdNFNUJNPyO7GdF8A5+rq7s5FLlup3QGs8Qnlg2FsOXLeRd oRtgh9gAJweQ4Ivm06z1oWrUUBtyYPoE3Vo86LF+7R+baexhAvVKYhDTarcc0WRzRTsQGGsRxwOK wPQEfK80SkMYVfOOcTjzdjf+5XmARYqUnEX7mFXLI+fQZi2WBFz4kuY2K2NYbrvSS92IO2IjZ1Lj V6Vtlxdu+TgwzVUGj37lMN+0hmpilpKmFmGm4fmYEhW2Xc1HLasqJylUQXTOA/2BPQTCK1FGW1oG LWCucn1N --0000000000008e606505b119b3be--