From nobody Mon Dec 2 08:26:44 2019
Return-Path:
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70418120018; Mon, 2 Dec 2019 08:26:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?=
To: "The IESG"
Cc: draft-ietf-dnsop-serve-stale@ietf.org, Suzanne Woolf , dnsop-chairs@ietf.org, suzworldwide@gmail.com, dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.111.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?=
Message-ID: <157530400244.4096.7440148624032232624.idtracker@ietfa.amsl.com>
Date: Mon, 02 Dec 2019 08:26:42 -0800
Archived-At:
Subject: [DNSOP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-dnsop-serve-stale-09=3A_=28with_COMMENT=29?=
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF DNSOP WG mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 02 Dec 2019 16:26:42 -0000
Mirja Kühlewind has entered the following ballot position for
draft-ietf-dnsop-serve-stale-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Two comments:
1) It seems to me that this sentence in section 7 should/could actually be
phrased as a normative requirement in this document: "it is not necessary that
every client request needs to
trigger a new lookup flow in the presence of stale data, but rather
that a good-faith effort has been recently made to refresh the stale
data before it is delivered to any client."
Maybe worth considering...
2) I find the Implementation Status section (8) actually quite interesting for
this document and maybe it should be considered to keep it in the document for
final publication.
From nobody Mon Dec 2 09:27:40 2019
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 A0AC91200C3 for ; Mon, 2 Dec 2019 09:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 m0RkCi5m9Zsi for ; Mon, 2 Dec 2019 09:27:36 -0800 (PST)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 80FAA120099 for ; Mon, 2 Dec 2019 09:27:36 -0800 (PST)
Received: by mail-il1-x12a.google.com with SMTP id u17so393896ilq.5 for ; Mon, 02 Dec 2019 09:27:36 -0800 (PST)
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; bh=PfCCL3ZnEXTk7HfPemP26st5xVH8NltL0P/BH/AuZG0=; b=Qe5wZAvgt9b1BBMDCT7tA1FzzpwMcGXAUzxzdialIeirZVIqpWYxBLjRlD7b23us+s WFQ3c/U4CTUCY3WK9HiMQL9fraoAq7pxqJUdon0+3lET8kg5nsWDS44LS8uf+LoChXwL n2DnB23rL8mHfDDoM1hPFeZWxEw2Dhkagym80s8vOVUpN+m7wgdjTTDhSuSVxRQ76Fl8 u50vHDFvmhtsBuaE3JF4Abl9x+PP/ZU2FnPWg8t08DuG7BFyopqASiggtf46Zd8dK32w qbLsyOhlcVonTqwfSIUiFR4D1Qc4U4fRTxI+EdnpSyZrxIOPHaPsXzIcM/A927rtC5dn ycZA==
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; bh=PfCCL3ZnEXTk7HfPemP26st5xVH8NltL0P/BH/AuZG0=; b=Jjm5fpwqtDc4CEknYOgmx9lzSP14lZjWmENquilYC/jAulQysEYLOYT/9BO35MBazQ XpS49FJ0cGx0KWew8GM7WkbZkhIqsi9ip1ujj9OopFXBk7nh9D3ucwtpZTWsnjjc6+ev zs2rW7W+AhNaZuTHNB94tSUJPFZPISYBPJX7y03GOaXF+9GspT58td8/MChthVLBZ912 koxg32tIdi7IkZjbFAcOE/WaySRMuXj2zdAV22DUIxudmx7PvBW3B03PFYQGJohR4xEf wlPU0GkKiLQ0+4pvNhIyqJVqeUpQJt8tuJbUOzA0bVK9wibSDaBO02I8goBZSWkUbaSf L8Fw==
X-Gm-Message-State: APjAAAXZx3YIEf+rqg6VIgRctCzzbvtoNZKn6EJxjf23rO5qqtu7rr4M kIhOFrBSGtXDpCuILB8VM9WIS3Yo3li2l+N7uxcDtKH5
X-Google-Smtp-Source: APXvYqxbU9y7dpGllIL4e2RdPLkThym+bSfq4iD9XnmJWRMWVghzNK+ZL1FgxTe2H7ToJ4Ih/HgJyd4GSb8kK8lhENA=
X-Received: by 2002:a92:6a07:: with SMTP id f7mr68629801ilc.41.1575307655148; Mon, 02 Dec 2019 09:27:35 -0800 (PST)
MIME-Version: 1.0
References: <9641D361-6A98-4B4B-BAAD-20327194EC4B@dukhovni.org>
In-Reply-To: <9641D361-6A98-4B4B-BAAD-20327194EC4B@dukhovni.org>
From: Ben Schwartz
Date: Mon, 2 Dec 2019 12:27:23 -0500
Message-ID:
To: dnsop
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000003aca170598bbe562"
Archived-At:
Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit
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: Mon, 02 Dec 2019 17:27:38 -0000
--0000000000003aca170598bbe562
Content-Type: multipart/alternative; boundary="00000000000032ea2a0598bbe582"
--00000000000032ea2a0598bbe582
Content-Type: text/plain; charset="UTF-8"
On Thu, Nov 21, 2019 at 3:10 AM Viktor Dukhovni
wrote:
> > On Nov 21, 2019, at 2:37 AM, Ben Schwartz wrote:
> >
> > To be clear, we are talking only about the case where a response "fits"
> until the EDE is added, after which it exceeds the limit and is truncated.
> If optimizing this situation is important, I would suggest adding a
> requirement to the EDE draft that EDE be the last option in OPT. Then as a
> client, I can easily detect this situation, because the truncation point is
> in the middle of the EDE option. The client logic then is very simple: if
> I don't care about EDE, I can ignore the TC bit.
>
> Not sure what you mean by "in the middle of the EDE option", IIRC
> truncation IIRCin DNS is never "in the middle" of an element, we
> either send the whole element or don't send it.
>
> For the OPT RR, I think that means that it includes a set of
> complete options.
>
Thanks for the correction. With that in mind, I agree that this trick
would not work.
>
> I do agree that truncation due to EDE should be rare, and therefore
> also TCP failover as a result of such truncation, so if the consensus
> is to keep it simple, so be it, but I don't see how how the client
> could figure out what was left out...
>
>
> --
> Viktor.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
--00000000000032ea2a0598bbe582
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=
> On Nov 21, 2019, at 2:37 AM, Ben Schwartz <bemasc@google.com> wrote:
>
> To be clear, we are talking only about the case where a response "=
;fits" until the EDE is added, after which it exceeds the limit and is=
truncated.=C2=A0 If optimizing this situation is important, I would sugges=
t adding a requirement to the EDE draft that EDE be the last option in OPT.=
=C2=A0 Then as a client, I can easily detect this situation, because the tr=
uncation point is in the middle of the EDE option.=C2=A0 The client logic t=
hen is very simple: if I don't care about EDE, I can ignore the TC bit.=
Not sure what you mean by "in the middle of the EDE option", IIRC=
truncation IIRCin DNS is never "in the middle" of an element, we<=
br>
either send the whole element or don't send it.
For the OPT RR, I think that means that it includes a set of
complete options.
Thanks for the correc=
tion.=C2=A0 With that in mind, I agree that this trick would not work.
=C2=A0
I do agree that truncation due to EDE should be rare, and therefore
also TCP failover as a result of such truncation, so if the consensus
is to keep it simple, so be it, but I don't see how how the client
could figure out what was left out...
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--00000000000032ea2a0598bbe582--
--0000000000003aca170598bbe562
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw
NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG
A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F
GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes
BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3
Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6
6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB
/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt
r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n
c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG
9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse
Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x
t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h
isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA
NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA
AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt
IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw
MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB
MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB
Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge
C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2
52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua
eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD
rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY
MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt
7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e
oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7
qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT
Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk
WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw
TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x
EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG
A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi
FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X
17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm
KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp
sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7
DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL
QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s
bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV
3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr
VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw
NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835
3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t
EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ
H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q
2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu
MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB
BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j
cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz
IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v
d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j
cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3
1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq
BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ
mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa
D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4
dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv
YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t
hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCqkfzKHmbpkbHOaCP6ftXB
fyvQLLfYMqxv2KmXK9AeVTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xOTEyMDIxNzI3MzVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB
FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg
hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEALgB8wSVHGTeu+4gindsPEWS/4zCFZMHkvXjLeR6r
26KPOYXF0kA95NEEftGBr6wVouetUPI8hTgLW8Ln9t0yOGv6kRaWBV0dTo1d5W8IRyACP431QgK+
Se5GeBJhU6iUUA5Ky8heClpse1f8UXOwHWIvl3ngw5jqhuyxaxw1XumWk1qhFDNjKIoULPZm8irn
VpniNeHIuE4n10YOfhUPHEtAQ9y2Ut8cMY2iZGs7FF/48SKgsWJ4eC8raZeTAgLLofeja0fzXyCl
jpbd6FDh4WsAjf0gFNktKlX2uTldS38/RwHlI3mwlxbRK0Kd07Q5XOp05SfzNb/mN6no+ruiCw==
--0000000000003aca170598bbe562--
From nobody Mon Dec 2 10:55:14 2019
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 1524F120072 for ; Mon, 2 Dec 2019 10:55:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eQBLyi7Nvmqg for ; Mon, 2 Dec 2019 10:55:11 -0800 (PST)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 25A2512003E for ; Mon, 2 Dec 2019 10:55:11 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id j42so416612wrj.12 for ; Mon, 02 Dec 2019 10:55:11 -0800 (PST)
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; bh=pHtmUUol8i+HJni/d5/jao7+Av44mrOA1wpQxiV0hC8=; b=nxmnwrmVqS2bnkNXju7OKDK6vubjM74IG+UlKlY+xTTv/lcPPL9gMWpLZ7+3xfHZWx AwE1RhleBdwwF1E7zTR5F0ZdJ91iu8f1RY0isBqXcMATX1//W7v4HscX8nln6qfKJC2E S00v7THmrWWhLJGKeTkOw5YAvempTn0dSB8KqlkwMXGBvWHADZc6guA6OvcGXbZxBMXq RawZD1L/ialbJRlRaJs7MNgZdBoR63df5/jnf+jrmvd+E77t1PGguNcoEPcAILEGuIih GxinAdvQ/68FTc1qzaYPZsIFF8p+yOf8tkAWGPXrlM0lSCPYH18jXTUnYN41rom1vm75 FJUg==
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; bh=pHtmUUol8i+HJni/d5/jao7+Av44mrOA1wpQxiV0hC8=; b=L3MZoh1nNQmGBiTHKvtuMCf0C+iV4CVoOLCsqx5mggoD+kvU2gegZAg5C5+iuv17Ve jCBVr+wFlmq1tI/6eDSdKvBpBwLE6qdoswrhSg5spPqgLUm50Rgk/Gwxvp9Vlu3/cnl7 xtsyTPH+otvMx7KCkVX7ozIROJzymu6DurbuGGMNFdfogkf2Dnrc6SCj65qLXNozss7D HysHyS9oMx/bEDpmGclnhBkVIUYoHOYfyaNLkhNO6yrPqwjpF/eU60BVIAyZfZzr6L+P sx1F80u8CJTLRpeUSEuD9u4xwu+ei1oEqciqI4He9Oov3QQaAZXfN8Hhy9ZxmU/7fuEU kmJQ==
X-Gm-Message-State: APjAAAUDOcmA4/qyHVZF1NN5v4he0ojgqZD2Iw2POMgyqtXKdQTb3Lsj +RjfFOmw7TflB/V06H9SuniPQqTQ797YtAAJrs+8BLm5ytc=
X-Google-Smtp-Source: APXvYqzTAQ/3hnonQm+LVBsLGBOxSw5y1d03xVjmptJdDmOKNPLgL525ItOgzjXZxEWeIHQw++5WC0ON72TC98zYAiU=
X-Received: by 2002:a05:6000:11c5:: with SMTP id i5mr499353wrx.102.1575312908903; Mon, 02 Dec 2019 10:55:08 -0800 (PST)
MIME-Version: 1.0
References: <81b64ed1-3b0a-e323-ab4f-b3ab89a14775@bellis.me.uk>
In-Reply-To: <81b64ed1-3b0a-e323-ab4f-b3ab89a14775@bellis.me.uk>
From: Eric Orth
Date: Mon, 2 Dec 2019 13:54:57 -0500
Message-ID:
To: dnsop
Content-Type: multipart/alternative; boundary="00000000000058d6150598bd1e53"
Archived-At:
Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit
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: Mon, 02 Dec 2019 18:55:13 -0000
--00000000000058d6150598bd1e53
Content-Type: text/plain; charset="UTF-8"
I still have a soft preference (but am definitely not going to call it a
hard blocker) for some way to avoid followup queries when the only thing
causing truncation is EDE.
My concern comes from the EXTRA-TEXT being an open-length field, and I
imagine many operators would want to create long verbose error messages.
Seems that could lead to many cases where EDE causes common excessive
truncation.
Maybe an alternate easy solution would be to add a don't-do-that note to
section 3.4 along the lines of "Long EXTRA-TEXT fields may cause truncation
and bad resolve performance, which is usually undesirable for the
supplemental nature of EDE. Operators setting the field SHOULD avoid
setting unnecessarily long contents, especially when it can be determined
that doing so will cause truncation." With something like that, I think my
concerns are enough resolved that I wouldn't worry about DP unless future
experience shows EDE truncation to be a significant problem.
But otherwise, if people don't like my suggested note, because I only have
a soft preference to do something, I agree that moving TC/DP to a separate
doc is a good idea. If EDE is otherwise consensus-ready, let's get it
published.
On Thu, Nov 21, 2019 at 12:04 PM Ray Bellis wrote:
>
>
> On 21/11/2019 15:37, Ben Schwartz wrote:
>
> > I would suggest adding a requirement to the EDE draft that EDE be
> > the last option in OPT
>
> And what if some other future option wants to lay claim to that
> requirement?
>
I agree that this would be a difficult requirement to set. Only one thing
can be last, and I would argue that EDE is not important enough to claim
that distinction and take away the flexibility from future specs.
--00000000000058d6150598bd1e53
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I still have a soft preference (but am definitely not=
going to call it a hard blocker) for some way to avoid followup queries wh=
en the only thing causing truncation is EDE.
My co=
ncern comes from the=C2=A0EXTRA-TEXT being an open-length field, and I imag=
ine many operators would want to create long verbose error messages.=C2=A0 =
Seems that could lead to many cases where EDE causes common excessive trunc=
ation.
Maybe an alternate easy solution would be t=
o add a don't-do-that note to section 3.4 along the lines of "Long=
EXTRA-TEXT fields may cause truncation and bad resolve performance, which =
is usually undesirable=C2=A0for the supplemental nature of EDE. Operators s=
etting the field SHOULD avoid setting unnecessarily long contents, especial=
ly when it can be determined that doing so will cause truncation." Wit=
h something like that, I think my concerns are enough resolved that I would=
n't worry about DP unless future experience shows EDE truncation to be =
a significant problem.
But otherwise, if people do=
n't like my suggested note, because I only have a soft preference to do=
something, I agree that moving TC/DP to a separate doc is a good idea.=C2=
=A0 If EDE is otherwise consensus-ready, let's get it published.
<=
br>
On 21/11/2019 15:37, Ben Schwartz wrote:
> I would suggest adding a requirement to the EDE draft that EDE be
> the last option in OPT
And what if some other future option wants to lay claim to that requirement=
?
=C2=A0I agree that this would be a di=
fficult requirement to set.=C2=A0 Only one thing can be last, and I would a=
rgue that EDE is not important enough to claim that distinction and take aw=
ay the flexibility from future specs.
--00000000000058d6150598bd1e53--
From nobody Mon Dec 2 11:16:05 2019
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 D147512003E for ; Mon, 2 Dec 2019 11:16:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 hJmszelSinCs for ; Mon, 2 Dec 2019 11:16:01 -0800 (PST)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 93B0B120018 for ; Mon, 2 Dec 2019 11:16:01 -0800 (PST)
Received: by mail-qk1-x735.google.com with SMTP id g15so677601qka.8 for ; Mon, 02 Dec 2019 11:16:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Lpo4WXEr3rYU9tIvebepNWsRi1+jkfK5crJz9I0GfdQ=; b=qAnS0XUn4rEroMvMDGizZuds1OrbwKADIJ5FWvtgbYZ8Z7RS2HNivs9/Hx8Ml+bkDU SSvc4d6iQPkOKadUglKUHUIeb+b/D8tSMFsSfgE08K0W9RBiweC5YsVjvy31AXCJpDl+ QCmDTCpTMh/uuOQzwnyrySM4Y+X1bm8kL64LYsDBqdAFIn3lO894U4O9wtHt1Ml9ZDby S5M1UFdsm+/meFyfvafuQJ9hFMvGLsyj+GK0MmQnmEIV8hX0uvLvswAGugLKIJ415RQ+ loAax0k0oe2nTmXW2V0uTUkkBRPgyUWmxfHP7YJi7QqZSbrHogbbSrTYKx1D8og4PTBB yi/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Lpo4WXEr3rYU9tIvebepNWsRi1+jkfK5crJz9I0GfdQ=; b=SjSJdbr4sFYTXmdj3Bd+vYbbfkYE8ung0Qktt7lxoocKjlMPSIE2u4+peR/o54APCQ ZLw5O4LkBnUmTMFriGIhVrK7i8HL3vDtT8boEmOsHd+ShUPGRXQ6jd/8TgQfPKQpT6/H V0S/36nlbOC0byD8jjTlqKXywDh6yp19FN1N0EiuKNfFfGY96MlNxIHW8zfZNTfcotGc ZXJ067TJrwuPIwfDQ+Wby0qXw12JmCOC3yOgzKnZwprUnRlXkYdWklzJQhL1OsBQXOT4 x1tViyqOkO7C4XvIH3SpYrppBtdz/EX6bWzlkXhK+rwrVkTqQps0dB4BHOBtyXChxP35 WUnA==
X-Gm-Message-State: APjAAAX2ySQ+K1nNirYggWCZOPJwaZdi6ISBg4cgbRCzwOowfz6c4fw3 irP9X/fbMW8PCzyNjz87XU0c56u/0Ek=
X-Google-Smtp-Source: APXvYqywRKPGXU5CwvUGTX3wgNaE5tutOQPGP5xkaxB6UKCVBEgQ22bQhEoqbHfSjiDriSAlXTbv/A==
X-Received: by 2002:a37:a806:: with SMTP id r6mr467161qke.400.1575314160413; Mon, 02 Dec 2019 11:16:00 -0800 (PST)
Received: from ?IPv6:2601:152:4400:437c:dd33:bee2:1b7f:de46? ([2601:152:4400:437c:dd33:bee2:1b7f:de46]) by smtp.gmail.com with ESMTPSA id 198sm272621qkn.70.2019.12.02.11.15.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2019 11:15:59 -0800 (PST)
To: dnsop@ietf.org
References:
From: Michael StJohns
Message-ID: <07cdee93-eb69-9a67-65d8-ea85e82a8761@nthpermutation.com>
Date: Mon, 2 Dec 2019 14:15:58 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To:
Content-Type: multipart/alternative; boundary="------------6ABCA2BF19529CF5F7467A71"
Content-Language: en-US
Archived-At:
Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit
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: Mon, 02 Dec 2019 19:16:04 -0000
This is a multi-part message in MIME format.
--------------6ABCA2BF19529CF5F7467A71
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
On 11/21/2019 1:53 AM, Wes Hardaker wrote:
> During the first DNSOP meeting at IETF 106 there was a discussion that
> had multiple opinions about what to do with setting the TC bit for EDE
> information, which is generally supplemental. During my presentation I
> mentioned that an associate of Viktor suggested creating a new bit, and
> during the conversation there was discrepancy about whether or not that
> was a good idea. Brian Dickson then proposed that the new bit only
> modify future clients that wanted to use it, thus leaving the EDE spec
> setting the TC bit. A future bit could be defined that would indicate
> that only supplemental information was dropped.
>
> My proposal for EDE is that we follow this train of thought, which seems
> to be the widest idea accepted from what I could tell. TLDR for things
> to do:
>
> 1. We have the EDE document say to set the TC bit (which it already did)
> 2. We create a new document that defines an extra bit for indicating
> that the dropped information was supplemental and didn't contain
> operationally important information.
>
> If this sounds like a good compromise, great! If you would like to
> propose an alternative, great! do so!
From 2181:
> The TC bit should be set in responses only when an RRSet is required
> as a part of the response, but could not be included in its entirety.
> The TC bit should not be set merely because some extra information
> could have been included, but there was insufficient room.
I finally got a chance to go back and do some reading and found the above.
The way I read this is that setting the bit simply because you couldn't
include diagnostic info is a no-no. Let's not do it.
I read "required" not as "the querier (person) requires it" but as "the
protocol requires it".
So - 3rd (4th?) option. Include a bit in querier EDNS(0) that says
"set the TC bit if I dropped EDE" and maybe "return the EDE info that
was dropped instead of or in preference to the query response data".
Later, Mike
>
> In the mean time, I threw together a quick ID for the new bit as well:
>
> https://datatracker.ietf.org/doc/draft-hardaker-dnsop-drop/
>
--------------6ABCA2BF19529CF5F7467A71
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
On 11/21/2019 1:53 AM, Wes Hardaker
wrote:
During the first DNSOP meeting at IETF 106 there was a discussion that
had multiple opinions about what to do with setting the TC bit for EDE
information, which is generally supplemental. During my presentation I
mentioned that an associate of Viktor suggested creating a new bit, and
during the conversation there was discrepancy about whether or not that
was a good idea. Brian Dickson then proposed that the new bit only
modify future clients that wanted to use it, thus leaving the EDE spec
setting the TC bit. A future bit could be defined that would indicate
that only supplemental information was dropped.
My proposal for EDE is that we follow this train of thought, which seems
to be the widest idea accepted from what I could tell. TLDR for things
to do:
1. We have the EDE document say to set the TC bit (which it already did)
2. We create a new document that defines an extra bit for indicating
that the dropped information was supplemental and didn't contain
operationally important information.
If this sounds like a good compromise, great! If you would like to
propose an alternative, great! do so!
From 2181:
The TC bit should be set in responses only when an RRSet is required
as a part of the response, but could not be included in its entirety.
The TC bit should not be set merely because some extra information
could have been included, but there was insufficient room.
I finally got a chance to go back and do some reading and found
the above.
The way I read this is that setting the bit simply because you
couldn't include diagnostic info is a no-no. Let's not do it.
I read "required" not as "the querier (person) requires it" but
as "the protocol requires it".
So - 3rd (4th?) option. Include a bit in querier EDNS(0) that
says "set the TC bit if I dropped EDE" and maybe "return the EDE
info that was dropped instead of or in preference to the query
response data".
Later, Mike
In the mean time, I threw together a quick ID for the new bit as well:
https://datatracker.ietf.org/doc/draft-hardaker-dnsop-drop/
--------------6ABCA2BF19529CF5F7467A71--
From nobody Mon Dec 2 11:34:14 2019
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 CDFCF120045; Mon, 2 Dec 2019 11:34:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 01PvrHCgQGvL; Mon, 2 Dec 2019 11:34:03 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 2B33312003F; Mon, 2 Dec 2019 11:34:02 -0800 (PST)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB2JQiY1012883; Mon, 2 Dec 2019 19:34:00 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=qcUETTB43O14McFZBgPJ3MAVzJAQeSzCzPK/lT0ML5g=; b=dgFgJZoiQ3acrZcAIncL1C/R88dDDoMBI2RUx76Rvk8qGR4+HHUyqrNUwJDUt76eCXiC cCbxfJV0KlUzMjHirOJXtTxWpLbqC6jT6N9ksjP2vJL5yjuHlnEhtStrJvph1xYjsVwB w+VZQewhEHnJvkxmPLeq4JLQM0BOzYAeNOxoPuACR5rF2F6AY+bX/vw9bH4gDfzGoi0f d9IoKE+ED/cJ3kw6IPLDSu4mpk4vwPOb8E2aXJA7Mk7W4ttZZiYRvY37cF4nWFqrdQyb KebV2bmDoOWu7KU0aUgMMf55wTYOtWGBnqbMTN170zYyi3Ljzn2cW/LWlvPu/mEE/6KM zA==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2wkvjrj2vn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Dec 2019 19:34:00 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xB2JWG4R022219; Mon, 2 Dec 2019 14:33:59 -0500
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2wkmmyb6et-1; Mon, 02 Dec 2019 14:33:58 -0500
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 132661FC95; Mon, 2 Dec 2019 19:33:32 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1ibrRq-0006Ne-Mz; Mon, 02 Dec 2019 11:33:30 -0800
Date: Mon, 2 Dec 2019 11:33:30 -0800
From: Benjamin Kaduk
To: Brian E Carpenter
Cc: Dave Lawrence , dnsop@ietf.org, gen-art@ietf.org
Message-ID: <20191202193329.GK3397@akamai.com>
References: <157194421575.11362.4964821589228085335@ietfa.amsl.com> <23985.64786.138127.971733@gro.dd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-02_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912020166
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-02_04:2019-11-29,2019-12-02 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 clxscore=1011 mlxscore=0 malwarescore=0 suspectscore=0 phishscore=0 adultscore=0 impostorscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912020165
Archived-At:
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt
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: Mon, 02 Dec 2019 19:34:06 -0000
Hi Brian,
I agree that this updated text provides more clarity about why the
change is being made, but I am not sure that it fully addresses all of
the concerns you raised, and would appreciate your thoughts.
Specifically, you had raised the possibility of existing, fielded,
implementations that would behave poorly when presented with input that
has the sign bit set. The DNS-OARC data that indicates such packets have
not been seen in the wild serves only to amplify this uncertainty, since
we have no reason to believe that such a codepath would have been triggered
already and diagnosed. Isn't there still some latent risk of such
fielded implementations that would be incompatible with this change if it
ever did show up on the wire?
Thanks,
Ben
On Fri, Oct 25, 2019 at 11:23:42AM +1300, Brian E Carpenter wrote:
> Hi Dave,
>
> Thanks. I think that covers it. I still suspect that the original reason
> was concern about int versus uint confusion, but the new text is fine.
>
> Regards
> Brian Carpenter
>
> On 25-Oct-19 08:35, Dave Lawrence wrote:
> > internet-drafts@ietf.org writes:
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-09
> >
> > This revision addressed the one remaining outstanding issue that Brian
> > Carpenter raised in the Gen-ART Last Call Review. The following text
> > was added to explain why a TTL with the high-order bit set is now
> > handles as a large positive number (then capped down) rather than a
> > negative number (and treated as zero).
> >
> > As for the change to treat a TTL with the high-order bit set as
> > positive and then clamping it, as opposed to [RFC2181] treating it as
> > zero, the rationale here is basically one of engineering simplicity
> > versus an inconsequential operational history. Negative TTLs had no
> > rational intentional meaning that wouldn't have been satisfied by just
> > sending 0 instead, and similarly there was realistically no practical
> > purpose for sending TTLs of 2^25 seconds (1 year) or more. There's
> > also no record of TTLs in the wild having the most significant bit set
> > in DNS-OARC's "Day in the Life" samples. With no apparent reason for
> > operators to use them intentionally, that leaves either errors or
> > non-standard experiments as explanations as to why such TTLs might be
> > encountered, with neither providing an obviously compelling reason as
> > to why having the leading bit set should be treated differently from
> > having any of the next eleven bits set and then capped per Section 4.
> >
> > I also removed the phrasing about 2181's handling of this issue as a
> > "curious suggestion". I recognize it could have an unintended
> > negative connotation against the original authors, though when I wrote
> > the sentence originally I meant it only with its neutral denotation.
> > It was curious to me only because no rationale was provided as to why
> > that particular choice had been made, despite the current assertion
> > that it was obvious as to why.
> >
> >
>
From nobody Mon Dec 2 13:02:28 2019
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 2358512008C; Mon, 2 Dec 2019 13:02:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 p-vLtv79XWd7; Mon, 2 Dec 2019 13:02:24 -0800 (PST)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 C24A7120018; Mon, 2 Dec 2019 13:02:24 -0800 (PST)
Received: by mail-pj1-x1032.google.com with SMTP id l4so325673pjt.5; Mon, 02 Dec 2019 13:02:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hWUdAyHH6z9MYNkZdb2Xdt8Jplv5ltdNNK9f/k/hjAQ=; b=SRjothvD0hoATCyT13dm75vlHqPekXft3mDyK3peUTmxSbxiZVggTrGJExf9+TAm2n 4YDYPXpTIH2Pdg5K7zwQVUxuwXqqmcLMHm6/qYHT81zHiX+Nl62kRmzR7yjY+r8mcqLr dqMux/Dt2xBize046XLIbhMoP5OacRA7alLgbQ7qcimQHRUNYtTXzAlux9Rci7+YN52d XVpOAyU48gOIaaCnHerPosmGq78LkbS/PZlrecY025iRmTHkK7Tfi/ZDDoK2Nlf5JU/c t69HYeZOObMwbowJap2KRJebO6Va4vmH9xj8NvUyB02rzTh1wtZlgKOHrmTUaU7aHhWq xrKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hWUdAyHH6z9MYNkZdb2Xdt8Jplv5ltdNNK9f/k/hjAQ=; b=k3uU1io949YwfD3tFlWxviGVmCgV29wqxH8K0wIS1wQfTWp0AhIepmtme7vtyJWnZN T7Sz7CI7XjMn78XvWs2CEtL5HkxmmqnR684cxBQ7c9m12nFG3jXH7zV5rhkQ955MC5HM rhsJ5W9+3mqF2T5aJy07qJzM1pKP8YLrPikOdVHETUS3RqLc0oEJ/+X7QT1EnZ7XNAXd qd49xwmEow0AhX0wRlMDtYL3SeZ6o3evWMnlWl3FlTwBJF7WaDM21GwZ+dA2lmkgBsFN PRh0dKOAZaNs/79sOWc0PGBXAe/QlelzOjEVhgyFvQBCqFFzIV+PXoGXsukYxRqAoM6T nkEw==
X-Gm-Message-State: APjAAAVX1F859/eX8BCGOmDkxFHlNHrGKzseuB4eURcEPFWZ9vYiLemO LKo9UqpoBlliqlfQ1PcwqH2vphX6SSw=
X-Google-Smtp-Source: APXvYqxBNZbD8QhykyR0xdyZLjH9pR0cZc1IojpRxGqldeJpGCrSqd/PjDUWiOCniVVpBMcHhXSsAg==
X-Received: by 2002:a17:902:904c:: with SMTP id w12mr1261625plz.144.1575320543613; Mon, 02 Dec 2019 13:02:23 -0800 (PST)
Received: from [130.216.37.136] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.37.136]) by smtp.gmail.com with ESMTPSA id s27sm401859pfd.88.2019.12.02.13.02.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2019 13:02:22 -0800 (PST)
To: Benjamin Kaduk
Cc: Dave Lawrence , dnsop@ietf.org, gen-art@ietf.org
References: <157194421575.11362.4964821589228085335@ietfa.amsl.com> <23985.64786.138127.971733@gro.dd.org> <20191202193329.GK3397@akamai.com>
From: Brian E Carpenter
Message-ID: <81d31e70-21fa-a7dd-2a27-cc82dc9f4253@gmail.com>
Date: Tue, 3 Dec 2019 10:02:18 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <20191202193329.GK3397@akamai.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At:
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt
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: Mon, 02 Dec 2019 21:02:27 -0000
Ben,
It's certainly a judgment call, but it really does seem that uint_32t has been around so long now that surviving implementations that misuse int for this surely have many other problems too. We'd be talking about resolver code that hasn't been refurbished since 1997 *and* a DNS record with an absurdly large TTL.
I think DNSOP participants are better placed than me to comment.
Regards
Brian Carpenter
On 03-Dec-19 08:33, Benjamin Kaduk wrote:
> Hi Brian,
>
> I agree that this updated text provides more clarity about why the
> change is being made, but I am not sure that it fully addresses all of
> the concerns you raised, and would appreciate your thoughts.
>
> Specifically, you had raised the possibility of existing, fielded,
> implementations that would behave poorly when presented with input that
> has the sign bit set. The DNS-OARC data that indicates such packets have
> not been seen in the wild serves only to amplify this uncertainty, since
> we have no reason to believe that such a codepath would have been triggered
> already and diagnosed. Isn't there still some latent risk of such
> fielded implementations that would be incompatible with this change if it
> ever did show up on the wire?
>
> Thanks,
>
> Ben
>
> On Fri, Oct 25, 2019 at 11:23:42AM +1300, Brian E Carpenter wrote:
>> Hi Dave,
>>
>> Thanks. I think that covers it. I still suspect that the original reason
>> was concern about int versus uint confusion, but the new text is fine.
>>
>> Regards
>> Brian Carpenter
>>
>> On 25-Oct-19 08:35, Dave Lawrence wrote:
>>> internet-drafts@ietf.org writes:
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-09
>>>
>>> This revision addressed the one remaining outstanding issue that Brian
>>> Carpenter raised in the Gen-ART Last Call Review. The following text
>>> was added to explain why a TTL with the high-order bit set is now
>>> handles as a large positive number (then capped down) rather than a
>>> negative number (and treated as zero).
>>>
>>> As for the change to treat a TTL with the high-order bit set as
>>> positive and then clamping it, as opposed to [RFC2181] treating it as
>>> zero, the rationale here is basically one of engineering simplicity
>>> versus an inconsequential operational history. Negative TTLs had no
>>> rational intentional meaning that wouldn't have been satisfied by just
>>> sending 0 instead, and similarly there was realistically no practical
>>> purpose for sending TTLs of 2^25 seconds (1 year) or more. There's
>>> also no record of TTLs in the wild having the most significant bit set
>>> in DNS-OARC's "Day in the Life" samples. With no apparent reason for
>>> operators to use them intentionally, that leaves either errors or
>>> non-standard experiments as explanations as to why such TTLs might be
>>> encountered, with neither providing an obviously compelling reason as
>>> to why having the leading bit set should be treated differently from
>>> having any of the next eleven bits set and then capped per Section 4.
>>>
>>> I also removed the phrasing about 2181's handling of this issue as a
>>> "curious suggestion". I recognize it could have an unintended
>>> negative connotation against the original authors, though when I wrote
>>> the sentence originally I meant it only with its neutral denotation.
>>> It was curious to me only because no rationale was provided as to why
>>> that particular choice had been made, despite the current assertion
>>> that it was obvious as to why.
>>>
>>>
>>
>
From nobody Mon Dec 2 14:34:02 2019
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 64F6112006F; Mon, 2 Dec 2019 14:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 LY7e9hXOb_Em; Mon, 2 Dec 2019 14:33:58 -0800 (PST)
Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92F4120018; Mon, 2 Dec 2019 14:33:56 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id 791EDB8191; Mon, 2 Dec 2019 17:33:53 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24037.37201.477919.347188@gro.dd.org>
Date: Mon, 2 Dec 2019 17:33:53 -0500
From: Dave Lawrence
To: dnsop@ietf.org, gen-art@ietf.org
In-Reply-To: <20191202193329.GK3397@akamai.com>
References: <157194421575.11362.4964821589228085335@ietfa.amsl.com> <23985.64786.138127.971733@gro.dd.org> <20191202193329.GK3397@akamai.com>
Archived-At:
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt
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: Mon, 02 Dec 2019 22:34:00 -0000
Benjamin Kaduk writes:
> Isn't there still some latent risk of such fielded implementations
> that would be incompatible with this change if it ever did show up
> on the wire?
There's always some risk with any change, right? I'm not trying to be
flatly dismissive of the concern. I do, however, find vague,
unsubstantiated concerns about the behaviour of unidentified software
to be a poor basis for an engineering decision.
Given that no circumstance has been identified where this is an issue,
the next best thing is a risk analysis of the potential, and I've
previously gone over the possible failure scenarios. The worst case
identified is that someone was actually sending a negative TTL with
the intent of it being cached as 0 (leaving open the question about
why they'd make that choice), but which would now be treated by new
software as very large and almost universally capped at something more
sane but still on the order of days instead of an augenblick.
As failure cases go, my subjective opinion is that this is not vexing,
especially without any evidence that someone is making meaningful
operational use of the treat-as-zero logic. If they were, it seems to
me that the people running the authority doing that and needing the
dynamic remapping it implies would be highly incentivized to update
their relatively smaller footprint of servers to behave more
reasonably.
On the flip side, authorities sending an obnoxiously large TTL (2^31+)
would now get the expected behviour of being cached as long as
possible rather than 0. Of course I personally would expect them to
get their act together and send more sane TTLs, too, in no small part
because in practical terms there are smaller values they could use to
achieve the same aims without having to even deal with the question of
the high order bit. The risk on this end is that new software,
written with the expectation that 2^31+ TTLs would be treated as
basically equivalent to 2^31-1 and then capped by modern resolvers,
might send to an old treat-as-0 resolver and get surprisingly frequent
requeries for what the operator intended to be a static response. If
this traffic were for a popular enough name to cause packet volume to
rise above the usual noise in any sort of remotely problematic way,
the authority operators are then highly incentivized to change as
well. This is all hinging on a lot of "ifs" though, starting that
chain with it being new behavior by an authority to start sending such
TTLs.
If you see some greater risk potential, I'll gladly think on that some
more. I certainly don't want to cause any harm either; I just don't
see it here.
From nobody Mon Dec 2 20:12:51 2019
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 A014D120116 for ; Mon, 2 Dec 2019 20:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level:
X-Spam-Status: No, score=-17.501 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, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 2_soGNcw2GYL for ; Mon, 2 Dec 2019 20:12:47 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 8AB42120113 for ; Mon, 2 Dec 2019 20:12:47 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id n27so1506267vsa.0 for ; Mon, 02 Dec 2019 20:12:47 -0800 (PST)
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:content-transfer-encoding; bh=dPT2gFVZJfkVO5MwK/FVcHmba7VGjHNwAYE7k3qSfqY=; b=E3l9jrS89xMWxthXcvKlzMpjCGo6Nen4+8ZqrDNyYA2ZFS5ywUIWc2zba+oBoBl7sH FSvws0BQKwxhc2eF2ef9p7qz4QyAfPZcuOTo9MLBSFQSvWM/LNQkYuV0UxTV9pMkY8It GDE3pTEzM0uA1Nf0Hf68FnS8N6e/Qzi5wcwAQ8apg8ZThcehMkSh9j19FdmsWZ/S8+ee WXKvaA94maOGnGCm+gaXSlC5L30GEMefB45us8mTVCu30PCS3MYDZF9OQqb+XCP1C4NN /sBoHfr3AvDga3bOD5m6lZXcf/MhdPHsodsiav+tEjgIr54n6On4JgI4L2hvevGSbwwl LMjQ==
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:content-transfer-encoding; bh=dPT2gFVZJfkVO5MwK/FVcHmba7VGjHNwAYE7k3qSfqY=; b=gdNVFUVa2N8mbRSYQ0tyO249mfm8u/COJ03GxhUIMpQDZ3fL+AM3zP7egMgInRD4kp gFkmuelSQSQMdWrlx1Pflil4tdrdlML12Ty0J+U5FX3Nqo5kXdHFW8PmeDW5mvbvV5se P/iy+k8bjWqkSD1GYeK0Nxt1t4TUc9odm0zt/GnK8U4lZCUrmAKBgwECbK0c090VeOPQ 7gAi1qJPxZarO60NdGEu7AfqGOGqzQMNymqgtf/yCcYRBgRdy5wSe1ZijByl5WfB0+Mq 7wsyRMvHv2cOGuXKQJm4n4p4Bbqc3qp7BYiLgfJ06ZP4foxCZNSY0rc3Wi0uYJphDXBV Sz/A==
X-Gm-Message-State: APjAAAUeqgvviQ5DXNR0qBvhISZcBmPL6jIifYPIDisGanVmQ/r1PGNv Uu10IKwnljcCCVS7cNg1tjMn/t88FftFh56Q9c34SQ==
X-Google-Smtp-Source: APXvYqz6VDBrFZsSXyvJ22J9dIO+tFZIgeVTRhw/b3bDf7GF/Gux7+bqE6mcJul5CWqEBaUTlDuhoHeANkNQZQx88Qo=
X-Received: by 2002:a67:be13:: with SMTP id x19mr1543827vsq.20.1575346365758; Mon, 02 Dec 2019 20:12:45 -0800 (PST)
MIME-Version: 1.0
References: <81b64ed1-3b0a-e323-ab4f-b3ab89a14775@bellis.me.uk>
In-Reply-To:
From: Puneet Sood
Date: Mon, 2 Dec 2019 23:12:34 -0500
Message-ID:
To: Eric Orth
Cc: dnsop
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At:
Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit
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: Tue, 03 Dec 2019 04:12:49 -0000
My preference is also to not add the DP bit as part of the EDE
feature. We should gain more experience with EDE before adding any new
bits to the protocol.
On Mon, Dec 2, 2019 at 1:55 PM Eric Orth
wrote:
>
> I still have a soft preference (but am definitely not going to call it a =
hard blocker) for some way to avoid followup queries when the only thing ca=
using truncation is EDE.
>
> My concern comes from the EXTRA-TEXT being an open-length field, and I im=
agine many operators would want to create long verbose error messages. See=
ms that could lead to many cases where EDE causes common excessive truncati=
on.
>
> Maybe an alternate easy solution would be to add a don't-do-that note to =
section 3.4 along the lines of "Long EXTRA-TEXT fields may cause truncation=
and bad resolve performance, which is usually undesirable for the suppleme=
ntal nature of EDE. Operators setting the field SHOULD avoid setting unnece=
ssarily long contents, especially when it can be determined that doing so w=
ill cause truncation." With something like that, I think my concerns are en=
ough resolved that I wouldn't worry about DP unless future experience shows=
EDE truncation to be a significant problem.
I would support text like the above in section 3.4 to remind operators
not to put very long text in the EXTRA-TEXT field.
>
> But otherwise, if people don't like my suggested note, because I only hav=
e a soft preference to do something, I agree that moving TC/DP to a separat=
e doc is a good idea. If EDE is otherwise consensus-ready, let's get it pu=
blished.
>
> On Thu, Nov 21, 2019 at 12:04 PM Ray Bellis wrote:
>>
>>
>>
>> On 21/11/2019 15:37, Ben Schwartz wrote:
>>
>> > I would suggest adding a requirement to the EDE draft that EDE be
>> > the last option in OPT
>>
>> And what if some other future option wants to lay claim to that requirem=
ent?
>
>
> I agree that this would be a difficult requirement to set. Only one thi=
ng can be last, and I would argue that EDE is not important enough to claim=
that distinction and take away the flexibility from future specs.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
From nobody Mon Dec 2 21:38:42 2019
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 A498F1200C1 for ; Mon, 2 Dec 2019 21:38:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level:
X-Spam-Status: No, score=-17.501 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, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 VTpoGvr_j0Ge for ; Mon, 2 Dec 2019 21:38:38 -0800 (PST)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 5501A120033 for ; Mon, 2 Dec 2019 21:38:38 -0800 (PST)
Received: by mail-vs1-xe32.google.com with SMTP id p21so1578292vsq.6 for ; Mon, 02 Dec 2019 21:38:38 -0800 (PST)
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=PcALtHwyy8BzGqYT7la5vU4xadw09cjIG+gfkmEFD0I=; b=W6nsMh/dvgrXUQhZYVB7u0YIIEWOURDnY8IIuP6FZedgRO5k4djGZm5FNChQINDLB0 ju5/UafAPOtMKUDXR4Xp/A97Cv/dvkZEwt1Tc7byAs7Z66Qpm1D19gVX7HqmcRUfMRVt eLsMEoaLSVxwDZcZ3R2v6IIS/WLf1vz8T4X9VZu++24ipw5u0q8WLCt1u42IA0KclUxo syNSrWehVJnmtScnswEH57yvplCAPSip45EJ1crpX6AGtiwgc4NsmIb+yZjRYc2hl/PK oWgs1Mu9NpAP4042DJfMiQHl3d8+/0WUJSOKAjUZdOD7WXlhEHR7GN8Cn+/d6hZu2Mb1 vnSA==
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=PcALtHwyy8BzGqYT7la5vU4xadw09cjIG+gfkmEFD0I=; b=lO/vfKboCPJEl4rhKqceVuWX1qCIe5eAg04v6sXpqHdtMSpqmo1UjuFVUz+x1pi0jw CgJtVyUQLE1S5IjbQjG6gElynssJSQswB454xIlNhirfjOOJLf0br+VtUPYtpbBThcN4 j67tFkLKgTCeawQroK31r7ibkgtVRAE43MK0IAVGlPITF+ZkybKInrLXd/L3axIxSoaQ XbysdK4e2D+sopbelKeBowT79eQPEnumP7W5bjdQkVkK/4g5sta/yg6iQ2NVrmJtuKDj 7EEOzRhLyTrdH7F/GBTO7jCII/1OU3/wzscFego/RxHQPMU8TeH8UHBVsxahylLMxPgH ytSw==
X-Gm-Message-State: APjAAAW6ed3iFYJTkFrk/89SFsHFxXJgpKAKC6AZjckJcpx1xavWu+da +0Ij4oGojAoD9YYox0UmLUemT0MRy5uk6EQrahj5yA==
X-Google-Smtp-Source: APXvYqyXBrdQ3j5sfVz5B667MJ1U7UqIdX4nCdvoGgCxCCDg0EuwyNxJWwXWD2sSTrwT/YE6orxQJJFCPtuO6S5SM/A=
X-Received: by 2002:a67:f2d7:: with SMTP id a23mr278978vsn.114.1575351516747; Mon, 02 Dec 2019 21:38:36 -0800 (PST)
MIME-Version: 1.0
References: <157271808929.6094.7926587135820341966@ietfa.amsl.com>
In-Reply-To:
From: Puneet Sood
Date: Tue, 3 Dec 2019 00:38:25 -0500
Message-ID:
To: "Wessels, Duane"
Cc: "dnsop@ietf.org"
Content-Type: text/plain; charset="UTF-8"
Archived-At:
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-05.txt
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: Tue, 03 Dec 2019 05:38:41 -0000
On Sat, Nov 2, 2019 at 2:18 PM Wessels, Duane
wrote:
>
> Hello dnsop,
>
> This draft has been updated with the following changes since -04:
>
> - added DNS-over-TLS to the abstract
> - added recent discussions about avoiding fragmentation in DNS
> - changed "SHOULD use TFO" to "MAY use TFO" due to concerns expressed in the WG
> - changed discussion of KSK rollover to past tense
> - added privacy consideration text
> - added a few new references
>
> The authors would like to take this draft to working group last call.
General comment: I do not see much discussion of this draft on the
list (https://mailarchive.ietf.org/arch/search/?q=%22draft-ietf-dnsop-dns-tcp-requirements%22),
The longest thread is about the semantics of DNS flag days and their
(lack of) benefit. Personally I find the appendix very useful since it
pulls together all relevant RFCs.
Specific comments below.
COMMENT: Section 5.1 DNS Wedgie
This is an issue for a resolver. Could we add a recommendation to
section 4.2 "Connection Management" for resolvers to handle this
better?
Something along the lines of "A resolver MAY want to track and limit
the number of TCP connections it opens to a single nameserver.".
COMMENT: Section 5.3 DNS-over-TLS seems out of place in section 5. It
would fit better in section 4. Network and System Considerations.
COMMENT: Section 6 Logging and Monitoring
Use some SHOULD keywords to make the recommendations stronger.
Thanks,
Puneet
>
> DW
>
>
> > On Nov 2, 2019, at 1:08 PM, internet-drafts@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Domain Name System Operations WG of the IETF.
> >
> > Title : DNS Transport over TCP - Operational Requirements
> > Authors : John Kristoff
> > Duane Wessels
> > Filename : draft-ietf-dnsop-dns-tcp-requirements-05.txt
> > Pages : 26
> > Date : 2019-11-02
> >
> > Abstract:
> > This document encourages the practice of permitting DNS messages to
> > be carried over TCP on the Internet. This includes both DNS over
> > unencrypted TCP, as well as over an encrypted TLS session. The
> > document also considers the consequences with this form of DNS
> > communication and the potential operational issues that can arise
> > when this best common practice is not upheld.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dnsop-dns-tcp-requirements-05
> > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-tcp-requirements-05
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-tcp-requirements-05
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
From nobody Mon Dec 2 23:17:17 2019
Return-Path:
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2EA12002F; Mon, 2 Dec 2019 23:17:15 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach via Datatracker
To: "The IESG"
Cc: draft-ietf-dnsop-serve-stale@ietf.org, Suzanne Woolf , dnsop-chairs@ietf.org, suzworldwide@gmail.com, dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.111.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Adam Roach
Message-ID: <157535743570.1893.17344031020923882056.idtracker@ietfa.amsl.com>
Date: Mon, 02 Dec 2019 23:17:15 -0800
Archived-At:
Subject: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF DNSOP WG mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 03 Dec 2019 07:17:15 -0000
Adam Roach has entered the following ballot position for
draft-ietf-dnsop-serve-stale-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thanks to everyone who put work into documenting this useful and apparently
well-deployed mechanism. I have a handful of comments on the current document.
---------------------------------------------------------------------------
§3:
> Several recursive resolver operators, including Akamai, currently use
> stale data for answers in some way.
This won't age well; and it's not clear why calling out Akamai amongst
the various DNS service providers is warranted. Suggest:
At the time of this document's publication, several recursive resolver
operators use stale data for answers in some way
(If the notion of citing Akamai is to indicate the scale of such operators,
I suggest "...operators, including large-scale operators, use stale...")
---------------------------------------------------------------------------
§4:
> The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is
> amended to read:
>
> TTL a 32-bit unsigned integer number of seconds that specifies the
> duration that the resource record MAY be cached before the source
> of the information MUST again be consulted. Zero values are
> interpreted to mean that the RR can only be used for the
> transaction in progress, and should not be cached. Values SHOULD
> be capped on the orders of days to weeks, with a recommended cap
> of 604,800 seconds (seven days). If the data is unable to be
> authoritatively refreshed when the TTL expires, the record MAY be
> used as though it is unexpired. See the Section 5 and Section 6
> sections for details.
The addition of what I must presume is intended to be RFC 2119 language to a
document that doesn't cite RFC 2119 seems questionable. I would suggest
either explicitly adding RFC 2119 boilerplate to RFC 1035 as part of this
update, or using plain English language to convey the same concepts as are
intended.
Nit: "See the Section 5 and Section 6 sections for details" is a very awkward
way to phrase the closing sentence.
More substantively: Sections 5 and 6 of RFC 1035 are "MASTER FILES" and "NAME
SERVER IMPLEMENTATION" respectively. Is this final sentence intended to refer to
those two sections? Or is it pointing to "Example Method" and "Implementation
Considerations" of this document? If the latter, please specifically cite this
document (e.g., "See Section 5 and Section 6 of [RFCXXXX] for details.")
---------------------------------------------------------------------------
§4:
> therefor leave any previous state intact. See Section 6 for a
Nit: "therefore"
---------------------------------------------------------------------------
§5:
> When a request is received by a recursive resolver, it should start
> the client response timer.
The passive tense in this sentence makes "it" linguistically ambiguous.
Suggest: "When the recursive resolver receives a request, it should start..."
---------------------------------------------------------------------------
§10:
> A proposed mitigation is that certificate authorities
> should fully look up each name starting at the DNS root for every
> name lookup. Alternatively, CAs should use a resolver that is not
> serving stale data.
This seems like a perfectly good solution, although I wonder how many CAs are
likely to read this document. If I were the type to engage in wagering, I'd
put all of my money on "zero." I'm not sure specific action is called for
prior to publication of this document as an RFC, but it seems that additional
publicity of this issue and the way that serve-stale interacts with it --
e.g., to CAB Forum and its members -- is warranted.
From nobody Tue Dec 3 02:41:50 2019
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 8CD951201E5 for ; Tue, 3 Dec 2019 02:41:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 SQy1s4bOIF8m for ; Tue, 3 Dec 2019 02:41:48 -0800 (PST)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 2E7EF120044 for ; Tue, 3 Dec 2019 02:41:48 -0800 (PST)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 0A30F6A24E; Tue, 3 Dec 2019 11:41:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1575369704; bh=6+xRAQb+To8Td7ywriACKFaoFuFE8bYIZyBKhSmi0jA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=4vHqEqJcucNIerkxjvT+XWdoePPgT7lCcMc/rPZpXrag53K53UzMyz0BQM6ANFR1T BfePOjki9QBpyQ1QPpPSqDUR/RxaCR4K/nwgJundXvXRrfycGTr+2adeQgh7p4w1xQ w6RMX7xwLrHAXOOgVaqLs42Qv5TpHkHjw1KLz3J0/ucOZkVawOoAP86g9WC7nNlWN8 pM7EpboROABoKK8MYbLOWn6FRlAl3ZEYRgdKPascTRFYUlvArRvDHAdXMvXd8OF62a 9FM9aYZ8j7zzu+H7uLtLiDTUv/IGpdiDJgyfzDqKJRCHAQpyDUG3PoZlyNwVJxCWRs 0qf7vaSFUbm4g==
Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id F07F33C06BD; Tue, 3 Dec 2019 11:41:43 +0100 (CET)
Date: Tue, 3 Dec 2019 11:41:43 +0100 (CET)
From: Vittorio Bertola
Reply-To: Vittorio Bertola
To: Puneet Sood
Cc: dnsop
Message-ID: <741936722.57527.1575369703891@appsuite-gw1.open-xchange.com>
In-Reply-To:
References: <81b64ed1-3b0a-e323-ab4f-b3ab89a14775@bellis.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.2-Rev17
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At:
Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit
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: Tue, 03 Dec 2019 10:41:49 -0000
> Il 3 dicembre 2019 05:12 Puneet Sood ha scritto:
>
> I would support text like the above in section 3.4 to remind operators
> not to put very long text in the EXTRA-TEXT field.
Thinking at how that field could be used in practice for a use case that we have in mind, I think it would be structured and contain pointer(s?) to more detailed information, under the form of URL(s). As long as it can keep a couple of average-length URLs and some shorter things, I think it will be ok. Also, independently from whether I like this or not, I expect this type of advanced use cases to require DoH as a transport protocol - I don't see clients trusting this information if received from an unauthenticated resolver over a cleartext connection.
--
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy
From nobody Tue Dec 3 10:24:09 2019
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 37B4F120220; Tue, 3 Dec 2019 10:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.851
X-Spam-Level:
X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 b4uOzk4P4KPJ; Tue, 3 Dec 2019 10:24:07 -0800 (PST)
Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC98A1201E5; Tue, 3 Dec 2019 10:24:06 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 0) id D90BBB8AA8; Tue, 3 Dec 2019 13:24:05 -0500 (EST)
Received: by gro.dd.org (Postfix, from userid 102) id 99E9BB81A1; Mon, 2 Dec 2019 17:42:23 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24037.37711.610534.987269@gro.dd.org>
Date: Mon, 2 Dec 2019 17:42:23 -0500
From: Dave Lawrence
To: iesg@ietf.org, draft-ietf-dnsop-serve-stale@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org
In-Reply-To: <157530400244.4096.7440148624032232624.idtracker@ietfa.amsl.com>
References: <157530400244.4096.7440148624032232624.idtracker@ietfa.amsl.com>
Archived-At:
Subject: Re: [DNSOP] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_dra?= =?iso-8859-1?q?ft-ietf-dnsop-serve-stale-09=3A_=28with_COMMENT=29?=
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: Tue, 03 Dec 2019 18:24:08 -0000
Thank you very much for your review, Mirja.
> 1) It seems to me that this sentence in section 7 should/could
> actually be phrased as a normative requirement in this document: "it
> is not necessary that every client request needs to trigger a new
> lookup flow in the presence of stale data, [...]"
I agree. We had a lot of back-and-forth in the working group about
normative language in this document, and but for the Standards Action
section. I'm personally in support of more of it, but ended up having
to strip out existing instances of normative language based on working
group consensus.
> 2) I find the Implementation Status section (8) actually quite
> interesting for this document and maybe it should be considered to
> keep it in the document for final publication.
I personally am in favor of this, not just for this document but for
all RFCs. RFC 6982 recommends that the section be removed, but I'd
be happy to help evolve that recommendation.
From nobody Tue Dec 3 10:28:49 2019
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 C5D1B1200FD; Tue, 3 Dec 2019 10:28:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 BaYVUBVpm8lo; Tue, 3 Dec 2019 10:28:45 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 31F7F1200EC; Tue, 3 Dec 2019 10:28:45 -0800 (PST)
Received: from 200116b824a7d500b41578c7b19a2328.dip.versatel-1u1.de ([2001:16b8:24a7:d500:b415:78c7:b19a:2328]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1icCug-0000Ll-DC; Tue, 03 Dec 2019 19:28:42 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind
In-Reply-To: <24037.37711.610534.987269@gro.dd.org>
Date: Tue, 3 Dec 2019 19:28:41 +0100
Cc: iesg@ietf.org, draft-ietf-dnsop-serve-stale@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <10A2FD64-FEF9-4747-B801-D4C5C4E2F94B@kuehlewind.net>
References: <157530400244.4096.7440148624032232624.idtracker@ietfa.amsl.com> <24037.37711.610534.987269@gro.dd.org>
To: Dave Lawrence
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1575397725;82a189ac;
X-HE-SMSGID: 1icCug-0000Ll-DC
Archived-At:
Subject: Re: [DNSOP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-dnsop-serve-stale-09=3A_=28with_COMMENT=29?=
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: Tue, 03 Dec 2019 18:28:47 -0000
Hi Dave,
Just on this point:
> On 2. Dec 2019, at 23:42, Dave Lawrence wrote:
>=20
>> 2) I find the Implementation Status section (8) actually quite
>> interesting for this document and maybe it should be considered to
>> keep it in the document for final publication.
>=20
> I personally am in favor of this, not just for this document but for
> all RFCs. RFC 6982 recommends that the section be removed, but I'd
> be happy to help evolve that recommendation.
RFC6982 recommends this because usually it's more important to have this =
information during the life-time of a draft (to understand the maturity =
of the protocol) but then it might quickly get out-dated after =
publication. However, we had also drafts were we retained the section =
for final publication because e.g. the whole draft was based on one =
specific implementation. I think that is also the case here and there is =
nothing in RFC6982 that permits keeping this information in the draft =
(if it seen as still useful in future).
Mirja
From nobody Tue Dec 3 10:35:00 2019
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 24DE212010D; Tue, 3 Dec 2019 10:34:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 HXe45Ks3KzBB; Tue, 3 Dec 2019 10:34:52 -0800 (PST)
Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03CF7120826; Tue, 3 Dec 2019 10:34:48 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id 57EEDB8AD9; Tue, 3 Dec 2019 13:34:47 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24038.43719.333541.632103@gro.dd.org>
Date: Tue, 3 Dec 2019 13:34:47 -0500
From: Dave Lawrence
To: iesg@ietf.org, draft-ietf-dnsop-serve-stale@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org
In-Reply-To: <24037.37711.610534.987269@gro.dd.org>
References: <157530400244.4096.7440148624032232624.idtracker@ietfa.amsl.com> <24037.37711.610534.987269@gro.dd.org>
Archived-At:
Subject: Re: [DNSOP] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_dra?= =?iso-8859-1?q?ft-ietf-dnsop-serve-stale-09=3A_=28with_COMMENT=29?=
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: Tue, 03 Dec 2019 18:34:54 -0000
Dave Lawrence writes:
> We had a lot of back-and-forth in the working group about
> normative language in this document, and but for the Standards Action
> section.
Huh, I clearly had a slipping brain clutch in the middle of that
sentence when it came to the final phrase. I think I had intended to
finish the sentence something like "... determined it was best to not
use normative keywords." Apologies for my failure to proofread before
sending.
From nobody Tue Dec 3 12:23:05 2019
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 35AD212002F for ; Tue, 3 Dec 2019 12:23:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 Zh_Ngy-0ueTj for ; Tue, 3 Dec 2019 12:22:58 -0800 (PST)
Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 D431D12000F for ; Tue, 3 Dec 2019 12:22:57 -0800 (PST)
Received: by mail-qk1-x741.google.com with SMTP id d202so4855947qkb.1 for ; Tue, 03 Dec 2019 12:22:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lBirvs7pvlq0LsSF8RCQZe/tD0RWlIznuMIGlxwi/Ek=; b=L+NVn7w7pG/eKIWbJuNTgPXD5sEpMhe4xxb9emt4duagPMWoTLK1Y4jEIfsQhYI0h0 V8MviPKcWeQzTDs7JS4q+Tbc8wVf2wKy01GJSMd8kCDgqm0hKORn5skwe/mwxWixqWgU 94h+NEvAI+h1piFILqZac+Zx5Kvq/t5ZjSFeOCtOAzlQBuPjw7BKemSESLa2yuSOM9Dz o0iAxDyI2WTm2G3iomIOckxUA2FhoqJGJLv8bYweKt5gonOeSceP9Vus5yLsAX4YoTDl AcBiV3ZIY5SBf+CUX6kqXg0qOi3w3/TZOIqAy+PylL9rXDFU6YxenI+HaUwkP5kMlvvj M2ow==
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:content-transfer-encoding; bh=lBirvs7pvlq0LsSF8RCQZe/tD0RWlIznuMIGlxwi/Ek=; b=dQgDtuIlbD+fyfKvVoLR6bFM+fXajtB/0Uk4lEisnYrPVF+Qi586zQPGLz9ISPRLpV xKsjOO++ZjxW1Rv4cdNBgFoV0fAj1+hVqp6h1QWXTiAaWxGCbh0DP4z4JQydv6E/AuSh v9sZjvrffxm2oj5jxXqic+4qPGHf1kka8LNAsUaA7kMPkyxHpw89okzi8Qx22aSUhupQ 14M7VNcdfULPfYhMH7w7aFAGNF+w1r+XQstqr9NDwNCxcd+cajRUgfx9G4lhFFIhJzyu xBD2TJfkjjjs2yhDZbD2V6W+fnGWIiW/3LXRlJBLcBwN2OJXsiQwd0pe5pFi4z8a0HTv +xoA==
X-Gm-Message-State: APjAAAWZgaIDZY5NFoWBSQiR/H1zx54ejep1gPx3YZfPHUs3S0jylKeC 44uXeMbezltRL7qW4ylBfYJDQVmYnxKETnOc3QbICw==
X-Google-Smtp-Source: APXvYqzYadtrGlkdJTl3o9e2SZhlni/zFtpCBzwmkUDU80gP+DTOx4cwTdya8fL2TG/RtqHwQqRkrJ85uabyEOpSAnM=
X-Received: by 2002:a05:620a:94f:: with SMTP id w15mr7336006qkw.63.1575404576479; Tue, 03 Dec 2019 12:22:56 -0800 (PST)
MIME-Version: 1.0
References: <157530400244.4096.7440148624032232624.idtracker@ietfa.amsl.com> <24037.37711.610534.987269@gro.dd.org> <10A2FD64-FEF9-4747-B801-D4C5C4E2F94B@kuehlewind.net>
In-Reply-To: <10A2FD64-FEF9-4747-B801-D4C5C4E2F94B@kuehlewind.net>
From: Warren Kumari
Date: Tue, 3 Dec 2019 15:22:20 -0500
Message-ID:
To: Mirja Kuehlewind
Cc: Dave Lawrence , The IESG , draft-ietf-dnsop-serve-stale@ietf.org, DNSOP-Chairs , dnsop
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At:
Subject: Re: [DNSOP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-dnsop-serve-stale-09=3A_=28with_COMMENT=29?=
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: Tue, 03 Dec 2019 20:23:00 -0000
On Tue, Dec 3, 2019 at 1:28 PM Mirja Kuehlewind wrote=
:
>
> Hi Dave,
>
> Just on this point:
>
> > On 2. Dec 2019, at 23:42, Dave Lawrence wrote:
> >
> >> 2) I find the Implementation Status section (8) actually quite
> >> interesting for this document and maybe it should be considered to
> >> keep it in the document for final publication.
> >
> > I personally am in favor of this, not just for this document but for
> > all RFCs. RFC 6982 recommends that the section be removed, but I'd
> > be happy to help evolve that recommendation.
>
> RFC6982 recommends this because usually it's more important to have this =
information during the life-time of a draft (to understand the maturity of =
the protocol) but then it might quickly get out-dated after publication. Ho=
wever, we had also drafts were we retained the section for final publicatio=
n because e.g. the whole draft was based on one specific implementation. I =
think that is also the case here and there is nothing in RFC6982 that permi=
ts keeping this information in the draft (if it seen as still useful in fut=
ure).
Note: Author hat only.
I'm not 100% sure, but I suspect you meant: "I think that is also the
case here and there is nothing in RFC6982 that **prevents** keeping
this ..."?
I'm personally in favor of keeping the information - even if it ends
up out of date, it still seems useful to me.
W
>
> Mirja
>
>
--=20
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
From nobody Tue Dec 3 13:18:56 2019
Return-Path:
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 555D112003E; Tue, 3 Dec 2019 13:18:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To:
Cc: dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.111.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: dnsop@ietf.org
Message-ID: <157540793023.4724.8140667702082755557@ietfa.amsl.com>
Date: Tue, 03 Dec 2019 13:18:50 -0800
Archived-At:
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF DNSOP WG mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 03 Dec 2019 21:18:50 -0000
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : Message Digest for DNS Zones
Authors : Duane Wessels
Piet Barber
Matt Weinberg
Warren Kumari
Wes Hardaker
Filename : draft-ietf-dnsop-dns-zone-digest-03.txt
Pages : 29
Date : 2019-12-03
Abstract:
This document describes a protocol and new DNS Resource Record that
can be used to provide a cryptographic message digest over DNS zone
data. The ZONEMD Resource Record conveys the digest data in the zone
itself. When a zone publisher includes an ZONEMD record, recipients
can verify the zone contents for accuracy and completeness. This
provides assurance that received zone data matches published data,
regardless of how the zone data has been transmitted and received.
ZONEMD is not designed to replace DNSSEC. Whereas DNSSEC protects
individual RRSets (DNS data with fine granularity), ZONEMD protects
protects a zone's data as a whole, whether consumed by authoritative
name servers, recursive name servers, or any other applications.
As specified at this time, ZONEMD is not designed for use in large,
dynamic zones due to the time and resources required for digest
calculation. The ZONEMD record described in this document includes a
field intended to enable future work to support large, dynamic zones.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-03
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-03
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-zone-digest-03
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
From nobody Tue Dec 3 13:35:27 2019
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 50C73120044 for ; Tue, 3 Dec 2019 13:35:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 S3FiFz9rGAqA for ; Tue, 3 Dec 2019 13:35:24 -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 B0C6C12003F for ; Tue, 3 Dec 2019 13:35:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9836; q=dns/txt; s=VRSN; t=1575408924; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=XNN+G5wSDMBB4lBHjndmNtFHo/5nNSasEmafevQGrYI=; b=TkY+wK+frWykkcf1ij7Bhv9NPexsYD0mKOs2KacH+zV+iG2GCTe1gYtt pntKbZzvSHZFdRuaZxKmXvP+lAOF3hIPcbyQnmY58AGuz0h7wj11aAFPL WtOfcFqWNGENk1Feu6HEBy/MIEuiSfhL4XFt3q85sZkq4Js+stbvHAeSQ r00tYa/MGkr71MhK/rM+XPeK7wyZVhtHZJprrVrgbLfLZxRfxRC03njfh lm4XJ7cT8r4ZELgP3zEQ4Mfqnt+OcDaF4uBcTAixui7IyGyz4go0sEUX2 +OLh735SwNptBSPubyR0gyHvQH+c19UQezWXyspCxTHH1M5x36IfKdojz g==;
IronPort-SDR: dCsfRhhq3NjsYxBSuaS90fn1ve4LLy0Rkrl1euPOJY4BnIMDTc2VF8J1Eyq12cQ3DY0vYYd8uL hVhmMKLSr2YMBYF6swOvBVQAVr/eH4m2YJO08x0QFhKFAMbBzESwnUMqY+oCroDtup1y4vweqm 3m733rfN2OAfgeK/YopWeMFtXm6mGM726uSCoK7br8vbHZwhZbD7+8kb77cqQTd6XrjFOaBv64 vckGYQ8sumBzEjc9LDFNhXcYsPG/9EI6tu0zLVHXVKqHCDmI8phk5o2tOx6Vh7XsuJzmIaaIFO 6Po=
X-IronPort-AV: E=Sophos;i="5.69,275,1571716800"; d="p7s'?scan'208";a="179899"
IronPort-PHdr: =?us-ascii?q?9a23=3Ama0LvxFw/961bexLVl0rE51GYnF86YWxBRYc79?= =?us-ascii?q?8ds5kLTJ7yps6wAkXT6L1XgUPTWs2DsrQY0rGQ6v+/EjVcsN6oizMrSNR0TR?= =?us-ascii?q?gLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ?= =?us-ascii?q?/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vIhi6txjdu8sUjIdtN6o8xR?= =?us-ascii?q?/EqWZUdupLwm9lOUidlAvm6Meq+55j/SVQu/Y/+MNFTK73Yac2Q6FGATo/K2?= =?us-ascii?q?w669HluhfFTQuU+3sTSX4WnQZSAwjE9x71QJH8uTbnu+Vn2SmaOcr2Ta0oWT?= =?us-ascii?q?mn8qxmRgPkhDsBOjUk62zclNB+g7xHrxKgvxx/wpDbYIeJNPplY6jRecoWSX?= =?us-ascii?q?ddUspNUiBMBJ63YYkSAOobJetWr5fzqUYSrRWwBgesCuHgxDhJhnDq0qI3yO?= =?us-ascii?q?shHR3D3AE6H9ICrGrYodPoP6kSS+C1y6zIwC3NY/xWxzj985PIfQ4lofGXRb?= =?us-ascii?q?57bMTfyVQ1GAPDkFqcp5HuMjSI2eUDrWeb9PFgWvyri248sAxxvCagxt0tio?= =?us-ascii?q?nSh4IVxVbE+T9lz4YyIN21UUh2asOqHptXsiGVLYp2QsU6TmFppik61rMGtY?= =?us-ascii?q?S8fCgQx5QqwQPUZf+fc4WQ/x7vSPydLSp6iX9rYr6zmha//Ea6xuDzUsS4yE?= =?us-ascii?q?tGojZfntXRtH0Bywbf5tWIR/Z+5EutxDWC2xjd6u5aIk04ia/WJps7zbMzkp?= =?us-ascii?q?ccqkHOEyHolErrjaKbc14r9+yp5unlZ7jrqJGROo1phQz4L68ggNawAf4iPQ?= =?us-ascii?q?gLR2Wb/OO826D98kDhW7VKi+E2krHesJDHOcQXvq65DBFR0oYk8xuyEiuo3s?= =?us-ascii?q?wFkXYHNFxLdxOIg5T3N13UPvD3EfC/g060kDtx3f/JI6ftAovXLnjYlrftZ6?= =?us-ascii?q?py60lZyAYrzNBf4YxbCq0ZLf7uRkP9rsHUAx03PgCu3urqCNtw2pkRVG+LGq?= =?us-ascii?q?OZNbndsV6M5uIhOemMY4oVtS7gJPkr+fHulmQ5lkEZfamyxpYXdm63Hu5nI0?= =?us-ascii?q?WCYHrsjdEBHX0WsQo5SezmkEeCXiJLZ3auQ6I84Sk2B5+gDYfYQYCtmKeM3C?= =?us-ascii?q?alEZ1KaGBKEFeMEW3nd9bMZ/BZZCSJJdcprRNMAbSnUIg5/RCjqAG8zKBoeL?= =?us-ascii?q?n64Cod4Njc2cNu6unI0Vke6DVyAo7Vh22SQnpvk2cTbyE7xqFkoEN7jFyE1P?= =?us-ascii?q?4r0LRjCdVP6qYRAU8BPpnGwrk/UoiqVw=3D=3D?=
X-IPAS-Result: =?us-ascii?q?A2FFAADs1OZd/zGZrQplGgEBAQEBAQEBAQMBAQEBEQEBA?= =?us-ascii?q?QICAQEBAYF+gwwrgQYKlUGDbJVagWcJAQEBAQEBAQEBAwQBGA0KAQEChD4Cg?= =?us-ascii?q?jI4EwIDAQELAQEBBAEBAQEBBQMBAQEChiAMgjspAWNrAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARYCQ1USAQEdAQEBAQIBAQFsEAsCAQgYLgIlCyUCBBMOgxQBglcRH?= =?us-ascii?q?rB/gieEPgIOQUCEZBCBNoFTil2BQj6BOCCCTD6CZAEBAgEBGIEvF4NDgiwEl?= =?us-ascii?q?gqYOQMHgi6DUYI1gRiOVoJBc4Z7j3WXCI5Agx8CBAIEBQIVgWmBe3AVGiEqA?= =?us-ascii?q?YJBCTUSERSVbYU/dJBvgRABAQ?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 3 Dec 2019 16:35:22 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1779.002; Tue, 3 Dec 2019 16:35:22 -0500
From: "Wessels, Duane"
To: dnsop WG
Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-03.txt
Thread-Index: AQHVqiGRDuxNR3GKMkSpfdnpBiDJsw==
Date: Tue, 3 Dec 2019 21:35:22 +0000
Message-ID:
References: <157540793023.4724.8140667702082755557@ietfa.amsl.com>
In-Reply-To: <157540793023.4724.8140667702082755557@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.9.1)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_C7B128D0-9C8F-4DA2-9ED4-E4C1C8F487B7"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At:
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-03.txt
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: Tue, 03 Dec 2019 21:35:26 -0000
--Apple-Mail=_C7B128D0-9C8F-4DA2-9ED4-E4C1C8F487B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Hi All,
Based on list feedback and the IETF-106 dnsop meeting, this revision has =
just two substantive changes:
- The mnemonic for digest type 1 has been changed to SHA384-SIMPLE (from =
SHA384-STABLE).
- The intended status has been changed to Standards Track (from =
Experimental) and the Scope of Experimentation section has been removed.
DW
> On Dec 3, 2019, at 1:18 PM, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Domain Name System Operations WG of =
the IETF.
>=20
> Title : Message Digest for DNS Zones
> Authors : Duane Wessels
> Piet Barber
> Matt Weinberg
> Warren Kumari
> Wes Hardaker
> Filename : draft-ietf-dnsop-dns-zone-digest-03.txt
> Pages : 29
> Date : 2019-12-03
>=20
> Abstract:
> This document describes a protocol and new DNS Resource Record that
> can be used to provide a cryptographic message digest over DNS zone
> data. The ZONEMD Resource Record conveys the digest data in the =
zone
> itself. When a zone publisher includes an ZONEMD record, recipients
> can verify the zone contents for accuracy and completeness. This
> provides assurance that received zone data matches published data,
> regardless of how the zone data has been transmitted and received.
>=20
> ZONEMD is not designed to replace DNSSEC. Whereas DNSSEC protects
> individual RRSets (DNS data with fine granularity), ZONEMD protects
> protects a zone's data as a whole, whether consumed by authoritative
> name servers, recursive name servers, or any other applications.
>=20
> As specified at this time, ZONEMD is not designed for use in large,
> dynamic zones due to the time and resources required for digest
> calculation. The ZONEMD record described in this document includes =
a
> field intended to enable future work to support large, dynamic =
zones.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-03
> =
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-03
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-dns-zone-digest-03
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--Apple-Mail=_C7B128D0-9C8F-4DA2-9ED4-E4C1C8F487B7
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINuDCCBmAw
ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug
b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ
BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50
ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs
IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk
aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F
44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a
NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB
AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5
Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG
AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu
Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ
LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG
AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl
MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j
cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF
BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi
SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s
Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH
5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e
DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggdQMIIGOKADAgECAhBozS15Aosz
FnqCXz2mRlt6MA0GCSqGSIb3DQEBCwUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50
ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT
LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT
eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTE5MDQxNzAwMDAwMFoXDTIwMDQyMjIzNTk1OVowcDEkMCIGCSqGSIb3DQEJARYVZHdlc3Nl
bHNAdmVyaXNpZ24uY29tMRcwFQYDVQQDDA5XZXNzZWxzLCBEdWFuZTEWMBQGA1UECwwNRU5URVJQ
UklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQCwQZ96T2koG0tlmsfXOuYViBANV4nfdJr4564BwoyGXX8bZ79IcvYsYAA4gluSHnoD
8zBx+vL3g7nrVdDv9aGdabTNDLFvBc9HOF/y5oSkrEUumIe1ffA0CPVkAgPBuOusANlx2fg3uvAX
Twu+OTzBXd52uM6DvH49FPlfnTovg5T2vHrTQLK2in+UEcosYtAoSvrrEGcvFHqSuvfmXZIxZDrf
jwCKbTNTNh6QFDtQ68RgHBghHn29sJlzqYJ79C+hBuTaiBzEHroJ49nsriEmqkjWxZBquDDKr/fs
kOMF0AY6YOOF6mA8Mo8gGJOr/4lC1u7WNmpl/Q59c10LxDIdAgMBAAGjggOKMIIDhjAMBgNVHRMB
Af8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4EFgQU
VoVKaC1xEPB9EWKq3dWrwskIufkwIAYDVR0RBBkwF4EVZHdlc3NlbHNAdmVyaXNpZ24uY29tMB8G
A1UdIwQYMBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcAYIKwYBBQUHAQEEggFiMIIBXjAnBggr
BgEFBQcwAYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMQYIKwYBBQUHMAKGggEjbGRh
cDovL2RpcmVjdG9yeS5zeW1hdXRoLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAy
JTIwU2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUy
MCUzRCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJl
ciUyMENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0Ql
MjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7Ymlu
YXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3
ZDY0NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtg
hkgBhvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggr
BgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoG
CCqGSIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG
+EUBEAMEHjAcBhJghkgBhvhFARABAgIBAYvxxgkWBjI0NzY2NDA5BgpghkgBhvhFARAFBCswKQIB
ABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBCwUAA4IB
AQBiCnGrS7F3f1l82AQV0ft7zy6jdYUWmKlRhGLuJOrmhWRyPYH3Vo/WKDJrq4N82ZP2sq61RK7g
8GdF1iB0/fVuLpoyTXVTT7nFS+RdwgSDkXevHBbbjLY72A/73+RVjLwALyCbCo0A+PRAPdX7ZMu5
1YF2lstu/Kb8fA1CUGCMfBY2huvwQkltnnO0OMhIN0fS4cMB4zAIoIr/+c9jcfCaS11R0X91dpAN
ZgGPHZ1d2oGWntiPoMcNAwdNW71UnjWGb3ViaRjZx7ON6YIBBx8RSMEcENZ6I7vwo81muFzqk4lP
c1S20pHKtwykEWuXXI+k/NBRMClYfLsmMNUOa1q0MYIETTCCBEkCAQEwgd4wgckxCzAJBgNVBAYT
AlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1
c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj
cmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEGjNLXkCizMWeoJfPaZGW3owCQYFKw4DAhoFAKCCAkMwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMjAzMjEzNTM4WjAjBgkq
hkiG9w0BCQQxFgQUNUJNuiIF/hcfxZcv1I1M5VPvu3Iwge8GCSsGAQQBgjcQBDGB4TCB3jCByTEL
MAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1h
bnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1
YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UEAxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJt
ZWRpYXRlIENlcnRpZmljYXRlIEF1dGhvcml0eQIQaM0teQKLMxZ6gl89pkZbejCB8QYLKoZIhvcN
AQkQAgsxgeGggd4wgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv
bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5h
Z2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNz
IDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEGjNLXkCizMWeoJf
PaZGW3owDQYJKoZIhvcNAQEBBQAEggEAawzLCgHK2lopvgQY9E+UnD+2DBGLI3Z/DeoFgHRDZun3
j7r7VEvGiOZXfnVrs3CfHxNwm7B83SQ198/xNeJPvYR7+03AUaM4HTWwjopnnymDYrfKGSSJ2Tdi
DzCkGTghG3qo/XcZydcOMQaIbkD12sogv0HUjJSrQy7MaMbUPyRIYTJBGCZ9sTb4tUPQBySIixlY
3isQo1NqgaK91f3zMHZPjHgQWZY8qwButT5PIk0TJOEOWF7PWzoSOvvHbTtbgyom+5rD6kqI7e+2
Tt6J4GltnzEVKxA8bPp31FVjeEMfUVUA5w4O4tQecrUQdlBmD6LVSzFSV9/8a6HZlbzzfQAAAAAA
AA==
--Apple-Mail=_C7B128D0-9C8F-4DA2-9ED4-E4C1C8F487B7--
From nobody Tue Dec 3 14:22:08 2019
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 A2254120044 for ; Tue, 3 Dec 2019 14:22:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.435
X-Spam-Level: *
X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 ltslqDrYiytS for ; Tue, 3 Dec 2019 14:22:06 -0800 (PST)
Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 100DA12003F for ; Tue, 3 Dec 2019 14:22:05 -0800 (PST)
Received: by nyx.guxx.net (Postfix, from userid 107) id 02C395F40B6A; Tue, 3 Dec 2019 23:22:03 +0100 (CET)
Received: from [172.19.216.63] (unknown [111.223.111.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id EA8865F401BB; Tue, 3 Dec 2019 23:22:02 +0100 (CET)
From: "Ralf Weber"
To: "Michael StJohns"
Cc: dnsop@ietf.org
Date: Wed, 04 Dec 2019 06:21:58 +0800
X-Mailer: MailMate (1.13r5655)
Message-ID:
In-Reply-To: <07cdee93-eb69-9a67-65d8-ea85e82a8761@nthpermutation.com>
References: <07cdee93-eb69-9a67-65d8-ea85e82a8761@nthpermutation.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At:
Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit
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: Tue, 03 Dec 2019 22:22:07 -0000
Moin!
On 3 Dec 2019, at 3:15, Michael StJohns wrote:
> From 2181:
>
>> The TC bit should be set in responses only when an RRSet is
>> required
>> as a part of the response, but could not be included in its
>> entirety.
>> The TC bit should not be set merely because some extra
>> information
>> could have been included, but there was insufficient room.
>
> I finally got a chance to go back and do some reading and found the
> above.
>
> The way I read this is that setting the bit simply because you
> couldn't include diagnostic info is a no-no. Let's not do it.
I disagree. The EDNS0 OPT RRSet is needed and thus if can not be fitted
entirely a TC bit has to be set. Also 2181 was before EDNS0 so IMHO it
doesn’t apply here anyway. EDE is all is new stuff we have to decide
over what do with it now and not some ancient RFC. And a lot of people
(including me) have said that they, because of the rare cases this
appears, see TC as the right solution as it is simple and backwards
compatible. EDE already is complex we should not increase it complexity
for a rare corner case.
So long
-Ralf
—--
Ralf Weber
From nobody Tue Dec 3 14:27:08 2019
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 7F25B12004D; Tue, 3 Dec 2019 14:27:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 lIgZwYY--F2R; Tue, 3 Dec 2019 14:27:05 -0800 (PST)
Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9DD12003F; Tue, 3 Dec 2019 14:27:02 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id BB53CB8C62; Tue, 3 Dec 2019 17:27:00 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24038.57652.748207.835678@gro.dd.org>
Date: Tue, 3 Dec 2019 17:27:00 -0500
From: Dave Lawrence
To: "The IESG" , draft-ietf-dnsop-serve-stale@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org
In-Reply-To: <157535743570.1893.17344031020923882056.idtracker@ietfa.amsl.com>
References: <157535743570.1893.17344031020923882056.idtracker@ietfa.amsl.com>
Archived-At:
Subject: Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
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: Tue, 03 Dec 2019 22:27:06 -0000
Thank you very much for your review, Adam. I have incorporated your
feedback into the document (which is not yet pushed to datatracker).
Here's the diff:
https://github.com/vttale/serve-stale/commit/3ae0f4e5f79e0b326608beaa77b74a1efe62663c
Adam Roach via Datatracker writes:
> The addition of what I must presume is intended to be RFC 2119
> language to a document that doesn't cite RFC 2119 seems
> questionable. I would suggest either explicitly adding RFC 2119
> boilerplate to RFC 1035 as part of this update, or using plain
> English language to convey the same concepts as are intended.
I definitely agree it is questionable, and if something needs to be
done to resolve this then your first suggestion is the one that is
more agreeable to me personally, but I can also see how that too is
questionable and might get some pushback. It's a bit of a weird
situation.
It is perhaps worth noting that several other RFCs that have updated
1035, starting with 3658, have already used 2119 normative keywords.
So in spirit it's already there, just not with an explicit remark in
any of the that formally puts the boilerplate on 1035 itself. (And,
in the end, that means 1035 is a weird hodge-podge of old world and new.)
> > A proposed mitigation is that certificate authorities
> > should fully look up each name starting at the DNS root for every
> > name lookup. Alternatively, CAs should use a resolver that is not
> > serving stale data.
>
> This seems like a perfectly good solution, although I wonder how
> many CAs are likely to read this document. If I were the type to
> engage in wagering, I'd put all of my money on "zero." I'm not sure
> specific action is called for prior to publication of this document
> as an RFC, but it seems that additional publicity of this issue and
> the way that serve-stale interacts with it -- e.g., to CAB Forum and
> its members -- is warranted.
Completely agree, except to the point that if it were known that there
was money riding on it then someone at a CA would read it just to take
your money. :) That said, anyone have thoughts on how best to bring
it to their attention?
From nobody Tue Dec 3 15:50:44 2019
Return-Path:
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 521B912000F; Tue, 3 Dec 2019 15:50:43 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker
To: "The IESG"
Cc: draft-ietf-dnsop-serve-stale@ietf.org, Suzanne Woolf , dnsop-chairs@ietf.org, suzworldwide@gmail.com, dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.111.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw
Message-ID: <157541704332.4708.13617952601376840902.idtracker@ietfa.amsl.com>
Date: Tue, 03 Dec 2019 15:50:43 -0800
Archived-At:
Subject: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF DNSOP WG mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 03 Dec 2019 23:50:43 -0000
Roman Danyliw has entered the following ballot position for
draft-ietf-dnsop-serve-stale-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
* I agree with Mirja, Section 8 is more informative than what is alluded to the
paragraph starting with “Several recursive resolvers …” in Section 3, and IMO
is worth keeping. I struck me as odd to call out the operation practice of a
particular vendor (Akamai). We might want to check if this reference is ok –
Ben?
* A few reference nits:
- Section 6. Per the mention to DNS-OARC, please provide a citation.
- Section 6 and 9. The text references “during discussions in the IETF”. What
is that specifically – WG deliberation?
* Thanks for covering the attacker use cases of stale data in Section 10.
From nobody Tue Dec 3 18:33:22 2019
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 ABC53120059 for ; Tue, 3 Dec 2019 18:33:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 i5qVsX3rW3XO for ; Tue, 3 Dec 2019 18:33:19 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3033B12001A for ; Tue, 3 Dec 2019 18:33:19 -0800 (PST)
Received: from [192.168.0.58] (cpc158605-hari23-2-0-cust247.20-2.cable.virginm.net [86.14.252.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 85E65B0592; Wed, 4 Dec 2019 02:33:15 +0000 (UTC)
To: Ralf Weber
Cc: Michael StJohns , dnsop@ietf.org
References: <07cdee93-eb69-9a67-65d8-ea85e82a8761@nthpermutation.com>
From: Paul Vixie
Message-ID: <67a385df-c026-41f6-3a99-aa24e5587aa1@redbarn.org>
Date: Tue, 3 Dec 2019 18:33:12 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.8
MIME-Version: 1.0
In-Reply-To:
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At:
Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit
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: ,