Subject: DNSSECbis Q-9: Dropping SIG(NXT) in authoritative section for neg. response.

From: "Scott Rose" <[email-masked]>
Date: Tue, 20 May 2003 12:29:19 -0400

Q:  Should the space restriction for a SIG RR covering a NXT RR in a
negative response cause the response to be truncated?  Should the "MUST set
the TC bit" language be dropped or changed?

Discussion:

When a DNSSEC aware server sends a negative or positive wildcard response,
the NXT RRs that are included are similar.  In the Authority section, a NXT
showing that the exact response does not exist, and a NXT showing the
closest encloser status are included along with their respective SIGs.
However, if the space does not permit their inclusion without truncation,
should the TC bit be set and the response truncated?

In RFC2535:

<start>
     1. when an RRset is placed in a response, its SIG RR has a higher
        priority for inclusion than additional RRs that may need to be
        included.  If space does not permit its inclusion, the response
        MUST be considered truncated except as provided in 2 below.

     2. When a SIG RR is present in the zone for an additional
        information section RR, the response MUST NOT be considered
        truncated merely because space does not permit the inclusion of
        the SIG RR with the additional information.
<end>

Taken as is, NXT RRs in the authority section in which there is no room for
SIG RRs would cause truncation.  In the DS draft, it also states that if
there is not room for a NXT and SIG(NXT) to be included in the authority
section (to signal lack of DS RR), the response must be truncated.

Current text in -01 version of protocol draft:

<start>
   If space does not permit inclusion of these NXT RRs, the response
   MUST be considered truncated, and the TC bit MUST be set.  Any SIG
   RRs associated with the NXT RRsets MUST also be included in the
   response.
<end>

And a sample of possible replacement text if dropping the SIGs is agreed
upon (Please suggest corrections if desired):

If space does not permit inclusion of these NXT RRs, the response MUST be
considered truncated, and the TC bit MUST be set.  Any SIG RRs associated
with the NXT RRsets SHOULD also be included in the response.  If space does
not allow the inclusion of the SIG RRs without causing truncation, all NXT
RRs have a higher priority in the response over any accompanying SIG RRs.
If space does not permit the inclusion of the necessary SIG RRs, the
response MUST NOT be considered truncated and the TC bit MUST NOT be set.

...

Reasoning for keeping the current language:
NXT RRs are the only RRs that have the same name in both delegating and
delegated zones, but with different RDATA, yet are both authoritative.   So
if a validator did not get
the accompanying SIG, it will have to know which authoritative server to get
the correct NXT RR to attempt to verify the SIG.  This would only happen at
delegation points.

Resoning to change the current langauge to something else:
It is more important to get the NXT RRs, which the validator cannot predict,
than the SIGs that accompany it.
It is possible to get the SIGs by a second UDP
query for the NXT RR in question to get the accompanying SIG RR.  Or a query
for the SIG RRset of the query name.  For not delegation points, this would
work.

Scott

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Bob Halley <[email-masked]>
Date: 20 May 2003 14:33:56 -0700

I support keeping the current language.

Given that we have EDNS0, I don't expect that cases where a SIG(NXT)
causes truncation will be that common.  If we don't think that the
switch to TCP is going to happen frequently, I don't think we need to
worry about it.

More importantly, separating SIGs from what they sign is something to
avoid.  Whenever you separate a SIG, you run into the possibility that
the SIG you subsequently fetch will be for another version of the
data.  When the SIG doesn't verify, the validator must not treat that
as a failure of validation, but instead must refetch both data and its
SIG and try again.

/Bob

---

From: [email-masked]
Date: Wed, 21 May 2003 09:54:43 +1000

> as a failure of validation, but instead must refetch both data and its
	I concur.
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 21 May 2003 13:16:22 -0400

At 14:33 -0700 5/20/03, Bob Halley wrote:
>avoid.

Very true.

Do not make separation of SIG and data an acceptable behavior by a sender.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Your office is *not* a reality-based sit-com TV show.

---

From: Mans Nilsson <[email-masked]>
Date: Sun, 25 May 2003 09:53:06 +0200

> as a failure of validation, but instead must refetch both data and its

I agree. 
-- 
Måns Nilsson         Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

TONY RANDALL!  Is YOUR life a PATIO of FUN??