Subject: [DNSOP] Fwd: [Editorial Errata Reported] RFC1035 (5915)

From: Warren Kumari <[email-masked]>
Date: Thu, 19 Dec 2019 22:36:12 -0500

Hi there all,

I stumbled across this while cleaning out my mailbox -- I *think* that
this makes sense, and that I should accept this as Hold For Document
Update ( https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
) - does anyone disagree?
If so, please let me know by Jan 5th.
W

---------- Forwarded message ---------
From: RFC Errata System <[email-masked]>
Date: Thu, Nov 21, 2019 at 7:03 PM
Subject: [Editorial Errata Reported] RFC1035 (5915)
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

The following errata report has been submitted for RFC1035,
"Domain names - implementation and specification".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5915

--------------------------------------
Type: Editorial
Reported by: Alexander Dupuy <[email-masked]>

Section: 6.2

Original Text
-------------
When a response is so long that truncation is required, the truncation
should start at the end of the response and work forward in the
datagram.  Thus if there is any data for the authority section, the
answer section is guaranteed to be unique.

Corrected Text
--------------
When a response is so long that truncation is required, the truncation
should start at the end of the response and work forward in the
datagram.  Thus if there is any data for the authority section, the
answer section is guaranteed to be complete.

Notes
-----
It's not clear what it might mean for an answer section to be unique.
However, by following the algorithm described of removing RRs from the
back to the front, if any RRs remain in the authority (or additional)
section, the answer section is guaranteed to be complete.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC1035 (no draft string recorded)
--------------------------------------
Title               : Domain names - implementation and specification
Publication Date    : November 1987
Author(s)           : P.V. Mockapetris
Category            : INTERNET STANDARD
Source              : Legacy
Area                : Legacy
Stream              : IETF
Verifying Party     : IESG

-- 
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: Wes Hardaker <[email-masked]>
Date: Fri, 20 Dec 2019 05:43:28 -0800

> If so, please let me know by Jan 5th.

I agree the word "unique" is odd there.  I agree the update seems to
make sense, but it would be sure be good to have the opinion of someone
familiar with the original discussions to ensure we're not missing
something and "unique" was intentional.  (if it is intentional,
clarification text would certainly be good)
-- 
Wes Hardaker
USC/ISI

---

From: Bob Harold <[email-masked]>
Date: Fri, 20 Dec 2019 10:08:21 -0500

On Thu, Dec 19, 2019 at 10:37 PM Warren Kumari <[email-masked]> wrote:

> Update (
> https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
I agree that "complete" is much better than "unique".

But if we are updating it, could we consider a better word than "forward"
?  Actually "backward" would be correct, although I prefer "from the back
to the front" as used elsewhere.

-- 
Bob Harold

---

From: Ray Bellis <[email-masked]>
Date: Mon, 23 Dec 2019 22:01:31 +0000

On 20/12/2019 15:08, Bob Harold wrote:

> But if we are updating it, could we consider a better word than
> "forward" ?  Actually "backward" would be correct, although I prefer
> "from the back to the front" as used elsewhere.

It's not possible to traverse the RRs in a raw DNS packet "backwards".
 You have to start at the beginning and remember the offset of each RR
found.

Ray

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 23 Dec 2019 18:16:18 -0500

+1 on "Complete"

Tim
(no hats this time)

On Mon, Dec 23, 2019 at 5:01 PM Ray Bellis <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Dick Franks <[email-masked]>
Date: Thu, 26 Dec 2019 18:55:27 +0000

>  You have to start at the beginning and remember the offset of each RR

Is there an implicit assumption here that all RRs beyond the UDP limit
are to be discarded without requiring inspection of their internal
content?

If so, then I have a problem with the current EDE draft which appears
to involve preferentially discarding the EDE option from the OPT RDATA
(as distinct from the entire OPT RR).

draft-ietf-dnsop-extended-error-13 says:

    3.  Extended DNS Error Processing
        When the response grows beyond the requestor's UDP payload size
       [RFC6891], servers SHOULD truncate messages by dropping EDE options
       before dropping other data from packets.  Implementations SHOULD set
       the truncation bit when dropping EDE options.

--
RWF

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Dec 2019 18:12:37 -0500

> On Dec 26, 2019, at 1:55 PM, Dick Franks <[email-masked]> wrote:
> 

That makes for RRs that carry relevant DNS data from zone files, but
the OPT RR is "chrome" (channel metadata), and required for EDNS.

> (as distinct from the entire OPT RR).

So it may be reasonable to drop EDNS options, rather the whole OPT RR.
And if necessary drop answer and/or auth RRs, while retaining at least
a minimal OPT RR.

But I have not thought this through further, so perhaps some crucial
neglected factor could change the conclusion.

-- 
	Viktor.