[RZERC] rzerc-zone-protection-recommendations

[Wessels, Duane]

All,

Daniel and I had a brief call to discuss his comments on this document.  Since Daniel was not on the committee while this document was being developed, I provided some of the background to how we got to this point.  From our discussion I made a small number of editorial changes to the document to address his concerns.  We can go over these changes in our call tomorrow.

DW



> On Oct 8, 2020, at 11:14 AM, Daniel Migault <mglt.biz at gmail.com> wrote:
> 
> Hi,
> 
> Please find my comments regarding the current
> draft rzerc-zone-protection-recommendations.
> I assume, my comments are coming pretty late,
> so please consider these as random comments.
> 
> """The mechanism of promulgating """
> 
> In the first paragraph it looks like zone
> transfer is new and differs from DNS query
> exchange protected by DNSSEC. If my
> reading is correct, it is confusing to me as
> I see AXFR/IXFR as mechanisms based on
> conventional query responses that are neither
> new nor protected by DNSSEC. I do not think
> the paragraph adds any value here and the
> background section may start with the second
> paragraph instead "Traditionally .... ".
> 
> """ Traditionally..."""
> 
> I am wondering if we should add a coma
> after Traditionally ?
> 
> I do not see any references to RFCs for AXFR,
> DNSSEC... I suppose that is an editorial
> choice.
> 
> Most expended acronyms are using small
> letters but not always, for example TSIG or
> DNSSEC. I am wondering if that should not be
> uniformed, unless there is a reason for not
> uniforming these.
> 
> """Since the root zone is signed..."""
> 
> I read this paragraph as providing reasons
> for signing the zone as a whole. It sounds
> surprising to me that the first reason
> invoked is that some elements are not signed
> with DNSSEC - NS. The obvious solution seems
> to sign these RR as opposed to the zone if
> that were a problem. Thus, I believe that the
> primary reason is that DNSSEC has not been
> designed for that purpose and as a result
> should be mentioned first. This design has
> two consequences: A major consequence is that
> using DNSSEC to check the integrity of the
> zone would be very difficult as it would
> mostly consist in validating the DNSSEC file.
> A second consequence is that some data -
> delegation and corresponding addresses are
> not signed. Just to be clear I thing that is
> more a consequence that DNSSEC has not been
> designed for zone transfer.
> 
> """Prior to the use of DNSSEC... """
> 
> I am a bit puzzled by the word "important" as
> if that were the case, I think we would have
> secured communications and maybe not have any
> resolvers. I think I would remove
> "important". "The source of the data" seems
> to me ambiguous as to me the data is the zone
> as opposed to the queries/exchange.  It also
> seems to me that the DNS client is limited to
> the DNS client on a resolver, as opposed to
> stub client. I would thus propose some text
> around the following lines:
> 
> """
> Prior to the use of DNSSEC,  DNS clients on
> resolvers implicitly trusted the server
> assumed it provides authentic and unmodified
> resource records. With the advent of DNSSEC,
> modification of resource records can be
> detected which relaxes the need to
> communicate with a trusted server.  """
> 
> Yours,
> Daniel
> 
> -- 
> Daniel Migault
> Ericsson
> 8400 boulevard Decarie
> Montreal, QC   H4P 2N2
> Canada
> 
> Phone: +1 514-452-2160
> _______________________________________________
> RZERC mailing list
> RZERC at icann.org
> https://secure-web.cisco.com/1Vf1iTyuCn7ktNePFSYaPBMhy1IR6q8YuGtq6wYpPtDygTU3U0j5Gq-H_grTZvAUQOMpW3rdD7siieF7831Vl5O7A7bBbV0OwmYavDJ4KFWxuoaiJZcwA1pYAwXjYsXMpoJTozbtCZ-cXA9KklG4M135V40Eh6RKaMSEa5nOnXIyghPRLbf6NM7PGnhOM6IiZKxdEU_OVaEW-sGV1Kp9zkwXOHMI3cH49c9BgLNDUR8mfORtGL8vbCYUEFVVd0qL7PWbKjGTwC4a1oibcdyodAA/https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Frzerc
> 
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://secure-web.cisco.com/1GUSnkz7ZkhA93wSkdMznELxIoyAPnuSVcm3Cch_7sYgqehScOjZXf5jQmJfWJsZ_fkrz2EX6woIXzvbKFgqa4lk45g69Z43VqeUanljcKfJD5fNHedsx4tE2yMSkMCEJkgy88_wzYlWBc0lM_fkiq_4QI26ekJFB6ig38cxaV8_slwvcm1gRqwbHNKAIWDyLfP2A5mhoEcNK3CWldRjBblwcRwywmF_e-z-17v_ynWgCN4-Tto5Bjh3kOzKEwk-SCOtfA92NqFHJAT8se8Vwsw/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy) and the website Terms of Service (https://secure-web.cisco.com/1r9vxjyOTr3aWvt97KCkxMAs7de3xX1SwPD4lq-_2oOCxhomemxQvXyagIaTpXlc_6zxoEQBs1zjBBWflOdPnisNkzr_HBoaZrXBdJMTG09jiADt8PSolgTqCl1bLMSTNuF3xLVIqIks1fy37QV1xQQBo-0JA6lFxhj-b_FlPMdiag5Jgz-3G9DbgBogdFFEvXEnhNPW2cppkmGNBwrzq7wKXONnfjXyt9j8y7ExH5PPPrcyHvH4a7rM6Laem3_wLOTjuETLcKZUdIRkdZ_eO2A/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4695 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rzerc/attachments/20201019/4858e70b/smime.p7s>