[DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-avoid-fragmentation-17: (with COMMENT)

[Murray Kucherawy via Datatracker]

Murray Kucherawy has entered the following ballot position for
draft-ietf-dnsop-avoid-fragmentation-17: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/



--
COMMENT:
--

Thanks for addressing my DISCUSS and Barry's remaining ARTART review point.

I support Rob Wilton's DISCUSS position.  Piling on a bit, in reference to:

   R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
   size to the RECOMMENDED size of 1400 or a smaller size.

I think the "RECOMMENDED" here is just carrying forward a "RECOMMENDED" from
someplace else.  If that's correct, I suggest changing it to "recommended" or,
if you want to be more precise, "... to the size recommended by RFC of 1400
or smaller."  Now it's clear what the SHOULD is referencing, and you don't own
the RECOMMENDED part here.

I suggest defining "EMSGSIZE" in Section 2 to be the UNIX error code of the
same name.  Otherwise, we encounter it in Section 3.1 in a way that could mean
it's an error code (which is how I think you intend it) or as a symbolic name
for the path MTU size.

Forwarded comments from Orie Steele, incoming ART Area Director:

"Recommendations for zone operators and DNS server operators"

* Define "large / small" better.

"Protocol compliance considerations"

* Would be nice to see reporting recommendations, perhaps that make the failure
an internal cost for the failing component?... would not want a repeat of dmarc
though.



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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-qdcount-is-one

[Wessels, Duane]

I’ve reviewed qdcount-is-one-02 and find it to be ready for publication as an 
RFC.

DW
 


> On Mar 5, 2024, at 6:51 AM, Suzanne Woolf  wrote:
> 
> Hi,
> 
> We're leaving this open a few more days to allow for any other comments. We'd 
> like to submit it for publication before IETF 119.
> 
> 
> Thanks,
> Suzanne
> For the chairs
> 
>> On Feb 15, 2024, at 10:57 AM, Suzanne Woolf  wrote:
>> 
>> Hi,
>>  
>> The qdcount draft is brief and straightforward, and there have been no new 
>> changes proposed or issues introduced since the -01 version was posted. We 
>> think there’s likely consensus to advance it for publication.
>>  
>> This note starts a Working Group Last Call for 
>> draft-ietf-dnsop-qdcount-is-one.
>>  
>> Current version of the draft is available here: 
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-qdcount-is-one/ 
>> 
>>  
>> The Current Intended Status of this document is: Proposed Standard
>>  
>> Please review the draft and offer relevant comments.
>>  
>> For WGLC, we need positive support and constructive comments; lack of 
>> objection is not enough. So if you think this draft should be published as 
>> an RFC, please say so.
>>  
>> If you feel the document is *not* ready for publication, please speak out 
>> with your reasons.
>>  
>> This starts a two week Working Group Last Call process, and ends on:  29 
>> February, 2024.
>>  
>> thanks,
>> Suzanne (for the chairs)
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/18BZXO046m-S-gFeTS8XVcBsn9c8bXsZLW_u3jUtVr3RvaQjL6K1zd0EeNxHSeBG8rRzmBD0skEhWfjqDfjet_3mXJAWwn_kG94MFRIEQrA6ucQRfzAUFMzMwdrz1P8lCnXIwK8oJWEiyeY6x6HzH-XvLrcZpzOqqzJhCIHidCQv2B9XsjiUdWoxLTwwqEb35o6GYSm67GIxNfKHWw6KBxtUXzFM-WkA0cY4LHZGgNwdPEYRNkczNlmIiGK_JeHj39iGlhOf_mpLCvzTp7E6CZdxg8snEGSdjLFNcijnvz5o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-06.txt

[internet-drafts]

Internet-Draft draft-ietf-dnsop-ns-revalidation-06.txt is now available. It is
a work item of the Domain Name System Operations (DNSOP) WG of the IETF.

   Title:   Delegation Revalidation by DNS Resolvers
   Authors: Shumon Huque
Paul Vixie
Willem Toorop
   Name:draft-ietf-dnsop-ns-revalidation-06.txt
   Pages:   10
   Dates:   2024-03-17

Abstract:

   This document recommends improved DNS [RFC1034] [RFC1035] resolver
   behavior with respect to the processing of Name Server (NS) resource
   record sets (RRset) during iterative resolution.  When following a
   referral response from an authoritative server to a child zone, DNS
   resolvers should explicitly query the authoritative NS RRset at the
   apex of the child zone and cache this in preference to the NS RRset
   on the parent side of the zone cut.  The (A and ) address RRsets
   in the additional section from referral responses and authoritative
   NS answers for the names of the NS RRset, should similarly be re-
   queried and used to replace the entries with the lower
   trustworthiness ranking in cache.  Resolvers should also periodically
   revalidate the child delegation by re-querying the parent zone at the
   expiration of the TTL of the parent side NS RRset.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-ns-revalidation-06

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-ns-revalidation-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

[Dave Lawrence]

Ray Bellis writes:
> I get the impression with DELEG on the horizon that there's a shift 
> towards the parent side data being considered more "authoritative" even 
> though in protocol terms it explicitly isn't.

Yes and no; there's a bit of nuance to ferret out here.  This is part
of the original sin of parent/child NS.  There is no child-side DELEG
for parent-side DELEG to be considered more authoritative about.  It
is just authoritative in the parent in the same way that DS is, which
incidentally is also more authoritative than if you put a DS in the apex.

Your general observation is, of course, correct that yes, this shift
takes a clearer parent-centric view of the perennial parent-centric /
child-centric debate.  In practical terms, operations have largely
been parent-centric anyway.

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

Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

[Dave Lawrence]

Willem Toorop writes:
> Should RFC 8767 stale data be ranked differently than fresh data?
> Should EDNS Client Subnet play into ranking?
> 
> I like your thinking! Yes, fresh data should replace stale data in
> resolver caches

It's basically A- in your draft's hierarchy, I think, though the
current structure gives each letter grade only one type of data for it
and there's already an A-.  However, I am also wondering about the A-
as described, because it seems to suggest that an SOA in auth is less
trustworthy than an SOA in ans.  (Also, A and A- differ in
"authoritative reply" vs "authoritative answer" which are seemingly
describing the same thing.)

I get that you're trying to indicate that NS in auth is lower than
(correctly scoped) NS in ans, but it needs a little finagling, maybe
just to call out explicitly NS rather than generalized data.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

[Dave Lawrence]

Shumon Huque writes:
> The draft allows (but does not proscribe) NXDOMAIN to be inserted
> into the Rcode for non DNSSEC enabled responses. I guess the main
> reason for not being proscriptive was what I mentioned - there were
> deployments in the field that didn't. But I'm amenable to tightening
> up the language if there is consensus for it (and I'll also chat
> with the implementers). Since we also support signaled restoration
> of the NXDOMAIN RCODE field for DNSSEC enabled  queries, I'm
> persuaded that we should probably close this divergence for non
> DNSSEC too.

You already know my position on this, but for the list: yes, please,
do this.

The existence of some deployments that currently do otherwise is
insufficient reason on its own to not specify better behavior.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

[John R Levine]

On Sun, 17 Mar 2024, Shumon Huque wrote:

The draft allows (but does not proscribe) NXDOMAIN to be inserted into
the Rcode for non DNSSEC enabled responses. I guess the main reason
for not being proscriptive was what I mentioned - there were deployments
in the field that didn't. ...


You're certainly right that there is software that sends NXDOMAIN when 
NODATA would be appropriate or vice versa.  (rbldnsd which is widely used 
in dnsbls has been a notable example which I think is now mostly fixed, 
due to giving wrong answers to minimized queries.)  But I think we're 
agreeing that it's better to confirm this is bad practice and encourage 
software to conform than to add yet another hump on the camel.


R's,
John

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

[Shumon Huque]

On Sun, Mar 17, 2024 at 9:08 AM John Levine  wrote:

> It appears that Dave Lawrence   said:
> >Stephane Bortzmeyer writes:
> >> > One current implementation does not differentiate DO=0 vs 1 and gives
> the
> >> > same NODATA answer for both cases.
> >>
> >> Yes. I see no practical problem with that but, from a philosophical
> >> point of view, it disturbs me. Naive clients may make wrong
> >> conclusions from the NODATA answer.
> >
> >Very much so, and not just naive programmatic clients but also
> >non-naive real-life human clients.  I myself have been misled by
> >noerror/nodata where nxdomain would have been correct.  It's
> >frustrating.
> >
> >nxdomain is usefully distinct and auth servers really ought to be
> >strongly encouraged to return it where applicable.
>
> We have an entire RFC 8020 about the difference and why it's important.
>

Yes, I agree with this of course.

Compact Denial intentionally broke the NXDOMAIN signal. One of the
main thrusts of this draft was to bring back the non-existence signal
in the form of an authenticable record in the payload.

The draft allows (but does not proscribe) NXDOMAIN to be inserted into
the Rcode for non DNSSEC enabled responses. I guess the main reason
for not being proscriptive was what I mentioned - there were deployments
in the field that didn't. But I'm amenable to tightening up the language if
there
is consensus for it (and I'll also chat with the implementers). Since we
also
support signaled restoration of the NXDOMAIN RCODE field for DNSSEC
enabled  queries, I'm persuaded that we should probably close this
divergence
for non DNSSEC too.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

[John Levine]

It appears that Dave Lawrence   said:
>Stephane Bortzmeyer writes:
>> > One current implementation does not differentiate DO=0 vs 1 and gives the
>> > same NODATA answer for both cases.
>> 
>> Yes. I see no practical problem with that but, from a philosophical
>> point of view, it disturbs me. Naive clients may make wrong
>> conclusions from the NODATA answer. 
>
>Very much so, and not just naive programmatic clients but also
>non-naive real-life human clients.  I myself have been misled by
>noerror/nodata where nxdomain would have been correct.  It's
>frustrating.
>
>nxdomain is usefully distinct and auth servers really ought to be
>strongly encouraged to return it where applicable.

We have an entire RFC 8020 about the difference and why it's important.

>From my point of view, anything that doesn't keep that distinction is 
>seriously broken.

R's,
John



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