Re: [DNSOP] [core] WGA call for draft-lenders-dns-over-coap

[Martine Sophie Lenders]

Hi Ben, Hi Carsten,

thanks for your suggestions, Ben! It seems a good idea to clarify 
options for compactification of DNS messages in a separate document, 
since the compactification is indeed not bound to CoAP. We will prepare 
such a draft until the cut-off for IETF 115, so we can discuss whether 
we keep or remove Section 5.1 at the IETF meeting in London. Would that 
work for you?


I tend to agree with Carsten. At least with the current wording (or the 
proposed), the restatements may lead to confusion, but some guidelines 
for the constrained use case should IMHO be part of the document, even 
if only in reference to the new document proposed.


Best
Martine

Am 20.09.22 um 18:17 schrieb Carsten Bormann:

I think we are falling into the restatement antipattern.

This antipattern happens when documents restate mandates from their 
references, invariably creating confusion if this is just a 
restatement or actually new normative text that replaces or updates 
text from the dependency. Don’t do that.


Examples can be put into their own section and clearly marked as such.

Grüße, Carsten

Sent from mobile, sorry for terse

On 20. Sep 2022, at 17:12, Ben Schwartz 
 wrote:



Martine,

Thanks for the proposed updated text regarding CNAMEs.  I agree that 
it is an improvement, but I still think it would be better to omit 
entirely.  By writing that implementations SHOULD follow RFC 1034, 
you imply that they are permitted not to, which seems objectionable.  
I think it would be much clearer to simply say that use of DoC does 
not alter the DNS message contents.


I feel similarly about the Additional section.  If you think that it 
would be useful to deviate from ordinary practices regarding the 
Additional section, I think this should be in a separate draft on 
compact DNS responses, not coupled to DoC.  For example, such 
compactification might be even more relevant to UDP Do53 than to DoC.


--Ben

On Mon, Sep 19, 2022 at 7:30 AM Martine Sophie Lenders 
 wrote:


Hi,

Sorry for the late reply, I was away from any keyboard for the
past two weeks.

I think there might be a misunderstanding regarding the CNAME
behavior, due to some poor wording in our draft: The CNAMEs
should, of course, only be resolved in such a way, if the queried
record was an A or  record. This does not, to my
understanding, contradict the behavior described for CNAMEs in
RFC 1034. We propose a different wording for the first sentence
in 5.1 to prevent such misunderstandings in the future:

    In the case of CNAME records in a DNS response to an A or
 record query, a DoC server SHOULD follow common DNS resolver
behavior [RFC1034

]
by resolving a CNAME until the originally requested resource
record type is reached.

Regarding the population of the additional section, we also
follow recommendations in RFC 1034, to only include records
useful to the client. We deem this particularly noteworthy when
it comes to DNS, as from our analysis of DNS traffic, responses
can become quite large due to an abundance of records in the
Additional section. With the message size constraints in LLNs, it
might thus be necessary to prune the DNS message for records
actually useful to the querying DoC client.

Lastly, mind, that, at least in our model for DoC, a DoC client
does not further distribute the information it gathered via DoC.

Regards
Martine

Am 06.09.22 um 17:06 schrieb Ben Schwartz:

Some further notes on this draft.

Section 5.1 says that a DoC server "SHOULD" follow CNAMEs.  This
is a misunderstanding of the nature of DNS transports.  DoC is a
DNS transport, like DoT and DoH.  The choice of transport is
independent of the DNS server's answering behavior, which must
not be modified by the transport.  Indeed, DPRIVE is now
chartered to enable the use of alternate transports for
recursive-to-authoritative queries for which CNAME following has
entirely different rules.  This is possible precisely because
the choice of transport does not alter the logical DNS contents.

Section 5.1 also proposes that the population of the Additional
section might follow different logic when using DoC.

Modifying the logical DNS behavior would create a wide range of
exciting and unpredictable compatibility issues when trying to
use a new transport.  I urge the authors to delete Section 5.1,
which would resolve this problem.  The draft could instead note
that the DNS queries and responses are not modified when using
DoC, except under private arrangement between the client and server.

On Fri, Sep 2, 2022 at 12:20 PM Jaime Jiménez  wrote:

Dear CoRE WG,

Thanks to the authors and the reviewers that provided
comments on the list for this draft. Given the in-room
  

[DNSOP] Last Call: (DNS Security Extensions (DNSSEC)) to Best Current Practice

[The IESG]

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Security Extensions
(DNSSEC)'
   as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2022-10-05. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document describes the DNS security extensions (commonly called
   "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of
   others.  One purpose is to introduce all of the RFCs in one place so
   that the reader can understand the many aspects of DNSSEC.  This
   document does not update any of those RFCs.  Another purpose is to
   move DNSSEC to Best Current Practice status.

   This document is currently maintained at
   https://github.com/paulehoffman/draft-hoffman-dnssec.  Issues and
   pull requests are welcomed.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
rfc5702: Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource 
Records for DNSSEC (Proposed Standard - Internet Engineering Task Force (IETF))
rfc5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence 
(Proposed Standard - Internet Engineering Task Force (IETF))
rfc4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records 
(RRs) (Proposed Standard - Internet Engineering Task Force (IETF))
rfc6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) 
(Proposed Standard - Internet Engineering Task Force (IETF))
rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed 
Standard - Internet Engineering Task Force (IETF))
rfc4034: Resource Records for the DNS Security Extensions (Proposed 
Standard - Internet Engineering Task Force (IETF))
rfc4033: DNS Security Introduction and Requirements (Proposed Standard - 
Internet Engineering Task Force (IETF))
rfc3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) 
(Proposed Standard - Internet Engineering Task Force (IETF))




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [core] WGA call for draft-lenders-dns-over-coap

[Ben Schwartz]

Preparing a separate document on compact DNS seems like a fine start to me.

On Wed, Sep 21, 2022 at 4:32 AM Martine Sophie Lenders <
m.lend...@fu-berlin.de> wrote:

> Hi Ben, Hi Carsten,
>
> thanks for your suggestions, Ben! It seems a good idea to clarify options
> for compactification of DNS messages in a separate document, since the
> compactification is indeed not bound to CoAP. We will prepare such a draft
> until the cut-off for IETF 115, so we can discuss whether we keep or remove
> Section 5.1 at the IETF meeting in London. Would that work for you?
>
> I tend to agree with Carsten. At least with the current wording (or the
> proposed), the restatements may lead to confusion, but some guidelines for
> the constrained use case should IMHO be part of the document, even if only
> in reference to the new document proposed.
>
> Best
> Martine
>
> Am 20.09.22 um 18:17 schrieb Carsten Bormann:
>
> I think we are falling into the restatement antipattern.
>
> This antipattern happens when documents restate mandates from their
> references, invariably creating confusion if this is just a restatement or
> actually new normative text that replaces or updates text from the
> dependency. Don’t do that.
>
> Examples can be put into their own section and clearly marked as such.
>
> Grüße, Carsten
>
> Sent from mobile, sorry for terse
>
> On 20. Sep 2022, at 17:12, Ben Schwartz
>  
> wrote:
>
> 
> Martine,
>
> Thanks for the proposed updated text regarding CNAMEs.  I agree that it is
> an improvement, but I still think it would be better to omit entirely.  By
> writing that implementations SHOULD follow RFC 1034, you imply that they
> are permitted not to, which seems objectionable.  I think it would be much
> clearer to simply say that use of DoC does not alter the DNS message
> contents.
>
> I feel similarly about the Additional section.  If you think that it would
> be useful to deviate from ordinary practices regarding the Additional
> section, I think this should be in a separate draft on compact DNS
> responses, not coupled to DoC.  For example, such compactification might be
> even more relevant to UDP Do53 than to DoC.
>
> --Ben
>
> On Mon, Sep 19, 2022 at 7:30 AM Martine Sophie Lenders <
> m.lend...@fu-berlin.de> wrote:
>
>> Hi,
>>
>> Sorry for the late reply, I was away from any keyboard for the past two
>> weeks.
>>
>> I think there might be a misunderstanding regarding the CNAME behavior,
>> due to some poor wording in our draft: The CNAMEs should, of course, only
>> be resolved in such a way, if the queried record was an A or  record.
>> This does not, to my understanding, contradict the behavior described for
>> CNAMEs in RFC 1034. We propose a different wording for the first sentence
>> in 5.1 to prevent such misunderstandings in the future:
>>
>> In the case of CNAME records in a DNS response to an A or  record
>> query, a DoC server SHOULD follow common DNS resolver behavior [RFC1034
>> 
>> ] by resolving a CNAME until the originally requested resource record
>> type is reached.
>>
>> Regarding the population of the additional section, we also follow
>> recommendations in RFC 1034, to only include records useful to the client.
>> We deem this particularly noteworthy when it comes to DNS, as from our
>> analysis of DNS traffic, responses can become quite large due to an
>> abundance of records in the Additional section. With the message size
>> constraints in LLNs, it might thus be necessary to prune the DNS message
>> for records actually useful to the querying DoC client.
>>
>> Lastly, mind, that, at least in our model for DoC, a DoC client does not
>> further distribute the information it gathered via DoC.
>>
>> Regards
>> Martine
>>
>> Am 06.09.22 um 17:06 schrieb Ben Schwartz:
>>
>> Some further notes on this draft.
>>
>> Section 5.1 says that a DoC server "SHOULD" follow CNAMEs.  This is a
>> misunderstanding of the nature of DNS transports.  DoC is a DNS transport,
>> like DoT and DoH.  The choice of transport is independent of the DNS
>> server's answering behavior, which must not be modified by the transport.
>> Indeed, DPRIVE is now chartered to enable the use of alternate transports
>> for recursive-to-authoritative queries for which CNAME following has
>> entirely different rules.  This is possible precisely because the choice of
>> transport does not alter the logical DNS contents.
>>
>> Section 5.1 also proposes that the population of the Additional section
>> might follow different logic when using DoC.
>>
>> Modifying the logical DNS behavior would create a wide range of exciting
>> and unpredictable compatibility issues when trying to use a new transport.
>> I urge the authors to delete Section 5.1, which would resolve this
>> problem.  The draft could instead note that the DNS queries and responses
>> are not modified when using DoC, except under private arrangement between
>> the client and