Subject: expired SIGs in an active zone

From: "Scott Rose" <[email-masked]>
Date: Fri, 8 Feb 2002 11:00:38 -0500

This is some issues that came up in a small group discussion (WG chairs,
DNSSEC editors, etc). that all of us thought should be taken to
namedroppers - given the content.  The question is how should authoritative
servers handle expired SIG records, since they are unique compared to the
rest of DNS data.

Some of the special processing of expired SIG records we thought needed
attention are both protocol changes and implementation changes.  Someone (me
and some other unlucky volunteers) will try to pull a draft out of the
consensus of the group so the protocol changes are on record and in the new
RFC2535bis drafts.

Protocol changes:
Def:  An expired SIG is a SIG record who's "expiration" section is in the
past. not who's TTL has expired.

-When dealing with expired SIG records in an authoritative zone, the server
SHOULD drop them from the zone when the SIG expires.  This entails the
server periodically checking SIG expiration times.

- Servers should avoid placing expired SIGs in DNS responses.
NOTE: <- this isn't a SHOULD NOT since it might prove more difficult for
servers to implement
than resolvers to ignore expired SIGs  Some other warning/on line signing
might occur, but that is not a protocol issue, but an operational one.

Open question:  Should deleting expired SIG records require an updating of
the zone serial number?  (I think "no" personally, but there are open
issues).

So this is another debate for those of us that have tired of the Opt-In
debate (and give the Verisign guys a chance to catch their breaths ;-)

Scott

===============================================================
Scott Rose
Advanced Network Technologies Division
NIST

ph: 301-975-8439                       fax: 301-590-0932
http://www.antd.nist.gov
===============================================================

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: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 8 Feb 2002 17:46:46 +0100

On Fri, 8 Feb 2002 11:00:38 -0500
"Scott Rose" <[email-masked]> wrote:

> Protocol changes: 
> Def: An expired SIG is a SIG record who's "expiration" section is in
> the past. not who's TTL has expired.

Agreed: the expiration date is a 'crypto' parameter, the TTL is a
'database optimalization' parameter. 

> -When dealing with expired SIG records in an authoritative zone, the
> server SHOULD drop them from the zone when the SIG expires.  This
> entails the server periodically checking SIG expiration times.

> servers to implement than resolvers to ignore expired SIGs  
> Some other warning/on line signing might occur, but that is not a 
> protocol issue, but an operational one.

I am confused: What is the difference between SHOULD avoid and SHOULD
NOT?  Don't you mean that this isn't a MUST NOT?

> the zone serial number?  (I think "no" personally, but there are open

If you want a consistent view of the DNS and you allow some servers
not to drop expired SIGs then you want the secondaries to pick up the
zone without expired SIGs.. hence increase the serial.

Otherwise I am (still) agnostic on this.

> debate (and give the Verisign guys a chance to catch their breaths ;-)

I am (still) not agnostic on this :-)

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Derek Atkins <[email-masked]>
Date: 08 Feb 2002 12:11:49 -0500

I think it can be dangerious to (automatically) remove expired SIGs
from a zone, or to drop them from responses.  In all things security,
it is the verifier who has the final say of whether to believe
something.  Knowing that a pieces of data was signed, but the sig is
expired, is very different than believing a piece of data is unsigned.
The two are not equivalent.

I also feel that a DNS server that is authoritative for a zone that
contains expired sigs should syslog an error every time a request is
made that would reply with an expired SIG.  Operators should be warned
continuously if they allow their signatures to expire.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Paul Vixie <[email-masked]>
Date: Fri, 08 Feb 2002 09:35:28 -0800

> server periodically checking SIG expiration times.

this is just impossible.  authority servers do not auto-edit zones.  if you
really mean this then you'll have to structure it as a dynamic update and
increment the serial number and show the change in IXFRs and so forth.  but
i for one would never, ever, (ever) turn this functionality on in my servers.

> - Servers should avoid placing expired SIGs in DNS responses.  NOTE:
> <- this isn't a SHOULD NOT since it might prove more difficult for
> servers to implement than resolvers to ignore expired SIGs Some other
> warning/on line signing might occur, but that is not a protocol issue,
> but an operational one.

if you really want this behaviour then you'll have to ratchet down the
TTL as the expiry gets closer in time.  otherwise you'll have cached SIGs
"floating around" whose signatures are expired but not their DNS TTL's,
and you won't have solved whatever problem you're worried about.  but if
you plan to ratchet down your TTL's in authority responses, then every
time you do it you'll have changed the zone's identity, and you'll have
to autoincrement the serial number and show this delta in IXFR's.

i went through all of this logic for a different purpose (see attached)
and was told by the committee that my draft had completely proved that the
implementation complexity was just unimaginably higher than anybody had
thought.

> debate (and give the Verisign guys a chance to catch their breaths ;-)

i've got to say that last time i participated in a secret-handshake meeting
in a smoke filled back room that had the result of making a recommendation
to the namedroppers committee, we did a better job explaining our motives
in public than you've done here.  what are the motives?  2535 requires the
clients and servers to have securely synchronized clocks.  that means a
client, of either direct authoritative data or recursively cached data,
will know whether the signature is expired or not.  why are you protecting
the client from something it HAS to be able to deal with ANYWAY?

btw, here's another copy of DEFUPD for those whose nightmares have stopped:

--------

   DNSIND Working Group                                    Paul Vixie (ISC)
   INTERNET-DRAFT                                                  May 1996
   <draft-ietf-dnsind-defupd-00.txt>

   Amends: RFC 1035, [UPDATE]

       Deferred Dynamic Updates in the Domain Name System (DNS DEFUPD)

   Status of this Memo

      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its areas,
      and its working groups.  Note that other groups may also distribute
      working documents as Internet-Drafts.

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as ``work in progress.''

      To learn the current status of any Internet-Draft, please check the
      ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
      Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
      munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
      ftp.isi.edu (US West Coast).

   Abstract

      Not all applications that perform dynamic updates using the protocol
      specified in [UPDATE] want their updates applied immediately.  A case
      in point is [DHCP], wherein the DHCP lease time should control the
      lifetime of associated DNS data even if the DHCP client or server is
      not available at the time the DHCP lease expires.

      The essence of this proposal is that DNS Dynamic Updates should be
      deferrable for some time delay period, after which they will be
      executed normally.  Furthermore, RRs added or updated by a deferred
      update can have expiration times specified for them, as enforced by
      the automatic Dynamic Updates.  Automatic serial number changes (as
      in [UPDATE]), dynamic zone slave notification (see [NOTIFY]) and
      incremental zone transfer (see [IXFR]) will jointly see to it that
      the zone changes are propagated with expedience.

   Expires November 1996                                          [Page 1]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   1 - New Assigned Numbers

      Opcode:   DEFUPD (6?)
      RRtype:   TUU (34?)
      RRtype:   TUE (35?)

   2 - Message Format

   The format and encoding of a DEFUPD is identical to that of UPDATE as
   defined in [UPDATE 2], except that the Opcode is DEFUPD rather than
   UPDATE, and there are two new RR types that can be used in the
   Additional Data section.

   2.1 - Additional Data Section: TUU RR

   In addition to the optional uses described in [UPDATE 2.6], a DEFUPD
   request's Additional Data section can include a TUU (Time Until Update)
   RR as follows:

      Owner:      same as ZNAME (see [UPDATE 2.3])
      Class:      same as ZCLASS (see [UPDATE 2.3])
      Type:       TUU (new RRtype for this protocol)
      TTL:        deferral time, relative, in seconds
      RDLENGTH:   0
      RDATA:      empty

   Of particular note is the TTL, which contains the relative time delay,
   in seconds, starting from the time this DEFUPD is received by the
   primary master, before operations contained in the Update Section (see
   [UPDATE 2.5]) will actually be performed.

   Expires November 1996                                          [Page 2]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   2.2 - Additional Data Section: TUE RR

   In addition to the optional uses described in [UPDATE 2.6], a DEFUPD
   request's Additional Data section can include a TUU (Time Until Expiry)
   RR as follows:

      Owner:      same as ZNAME (see [UPDATE 2.3])
      Class:      same as ZCLASS (see [UPDATE 2.3])
      Type:       TUE (new RRtype for this protocol)
      TTL:        expiry time, relative, in seconds
      RDLENGTH:   0
      RDATA:      empty

   Of particular note is the TTL, which contains the expiration time delay,
   in seconds, starting from the time this DEFUPD is received by the
   primary master, of all RRs added or updated by operations in the Update
   Section (see [UPDATE 2.5]).

   3 - Server Behavior

   A server, upon receiving a DEFUPD request, will first scan the request's
   Additional Data section in search of TUU or TUE RRs.  If no RRs of
   either type TUU or TUE are found, then this request will be processed as
   a normal UPDATE with no special behaviour.  If any TUU or TUE RRs are
   found, then processing continues as follows.

   3.1 - Verify TUU RR

   If any TUU RRs are found in the Additional Data section, this update
   will be processed with Deferral as explained below.  If more than one
   TUU RR is found, signal FORMERR to requestor.  The TUU RR's owner name
   and class are compared to ZNAME and ZCLASS; if a mismatch occurs, signal
   FORMERR to requestor.  The TUU RR's RDLENGTH/RDATA is ignored by
   implementations of this specification, but future specifications may
   make use of this field.

   3.2 - Verify TUE RR

   If any TUE RRs are found in the Additional Data section, this update
   will be processed with Expiry as explained below.  If more than one TUE
   RR is found, signal FORMERR to requestor.  The TUE RR's owner name and
   class are compared to ZNAME and ZCLASS; if a mismatch occurs, signal
   FORMERR to requestor.  The TUE RR's RDLENGTH/RDATA is ignored by
   implementations of this specification, but future specifications may
   make use of this field.

   Expires November 1996                                          [Page 3]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   3.3 - Deferral

   If a TUU RR was specified in the Additional Data section, this update
   will be processed with Deferral.  Deferral means that the update will
   not be applied synchronously to the requestor's transaction cycle, but
   instead will be applied asynchronously at some potentially later time.
   The delay period is measured in seconds and expressed in the TUU's TTL.

   3.3.1 - Store Deferred Update

   Subject to per-server, per-zone, and per-RRset quotas, this UPDATE
   message is stored, persistently, on the name server.  If per-RRset
   quotas are implemented, it is recommended that a DEFUPD ``count
   against'' all RRsets mentioned in the Update Section.  If an
   implementation defined quota is exceeded by this deferred update, or if
   persistent storage is unavailable, signal SERVFAIL to requestor (leaving
   the zone in its former state).  Note that even a deferred update whose
   TUU's TTL is zero (0), specifying immediate application, should be
   subject to quotas if the name server implements quotas.

   3.3.2 - Send Early Response

   Signal NOERROR to requestor.

   3.3.3 - Apply Deferred Update

   When a period of time equal to or greater than the TUU's TTL (measured
   in seconds) has elapsed since a DEFUPD was first received at the primary
   master, the DEFUPD message is applied to the zone as an UPDATE would be,
   except that no error can be signalled to the requestor.  Thus, all
   errors not found and reported at the time the DEFUPD request was
   received are silent, affecting only the continued processing of the
   deferred update.  Note that all sections are processed, including those
   processed before the deferred update were stored.  Thus, prerequisites
   must hold before and after the deferral period.

   Expires November 1996                                          [Page 4]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   3.4 - Expiry Processing

   When a DEFUPD is applied, either during the requestor's transaction
   cycle or following the optional Deferral period, the inclusion of a TUE
   RR in the Additional Data section will cause this update to be processed
   with Expiry.

   Expiry as expressed in the TUE's TTL is the time, in seconds, before all
   RRs added or modified by the Update Section will be automatically
   deleted by the primary master server.  This time is relative to the time
   the DEFUPD message is processed, which might be after the delay period
   specified by a TUU RR.

   3.4.1 - Initial TTL Limits

   The TTL of all added or updated RRs in the Update Section will be
   maximized silently to one half of the Expiry time.  This will cause
   downstream caching name servers to purge RRsets containing this RR at
   least once before expiry.

   3.4.2 - TTL Half Life

   Each time an RR's expiry reaches half of its previous value, that RR's
   TTL will be reduced to half of its previous value, until the TTL reaches
   a value less than or equal to sixty (60), i.e., one minute of real time,
   at which time the TTL will not be automatically reduced further by the
   primary master.  It should be noted that RRs held in a server's memory
   need not be swept for half life processing, as long as the TTL changes
   appear when the RR next becomes externally visible, and as long as the
   ``zone has changed'' processing (see below) is done at the time of the
   half life expiration.

   Whenever the TTL is automatically reduced by this process, the zone will
   be considered ``changed'' for the purpose of automatic SOA SERIAL
   increment (see [UPDATE 3.6]) and real time zone slave notification (see
   [NOTIFY]).

   Expires November 1996                                          [Page 5]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   3.4.3 - Automatic Deletion

   When the time since an RR was added or updated by a DEFUPD with Expiry
   exceeds the TUE's TTL as specified in that update, all RRs added or
   updated by that DEFUPD's Update Section will be automatically deleted by
   the primary master.  This deletion can be deferred until the deleted RRs
   would next become visible, so long as the ``zone has changed''
   processing (see below) is done at the time of expiration (i.e., when the
   automatic deletion is first deferred.)

   Whenever automatic deletion occurs, the zone will be considered
   ``changed'' for the purpose of automatic SOA SERIAL increment (see
   [UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]).

   3.5 - Requirements for Persistence

   Stored deferred updates should persist across name server restarts.

   3.5.1 - Restarts and Deferral

   In the event of a name server restart, all deferred updates whose TUU
   has expired must take effect before any network requests are processed
   using data from the affected zone, and before any Expiry processing
   takes place on RRs in the affected zone.

   3.5.2 - Restarts and Expiry

   In the event of a name server restart, all expiries must be checked as
   of the current time before any network responses are generated using
   data from the affected zone.

   If an RR's expiry time has been reached while the name server was not
   running, that RR will be deleted.  Otherwise, the RR's TTL will be set
   to one half of the time remaining before expiration, and half life
   processing as specified in Section 3.4.2 will be restarted.

   If any RR is deleted or if an RR's TTL is changed during startup, then
   the zone will be considered ``changed'' for the purpose of automatic SOA
   SERIAL increment (see [UPDATE 3.6]) and real time zone slave
   notification (see [NOTIFY]).

   Expires November 1996                                          [Page 6]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   4 - Requestor Behaviour

   A requestor will generate and transmit a DEFUPD request as specified in
   [UPDATE 4], except that TUU and TUE RRs can be included in the
   Additional Data section.

   4.1. The TUU RR, if specified, must have an owner name and class equal
   to the ZNAME and ZCLASS (see [UPDATE 2.3]).  The TTL should be set to
   the delay, measured in seconds, before this update should be processed
   by the primary master.  RDLENGTH should be set to 0, and RDATA should
   therefore be empty.

   4.2. The TUE RR, if specified, must have an owner name and class equal
   to the ZNAME and ZCLASS (see [UPDATE 2.3]).  The TTL should be set to
   the delay, measured in seconds, before all RRs added or changed by the
   Update Section will be automatically deleted by the primary master.
   This delay is measured starting from the time the update is applied,
   which could follow a deferral delay if a TUU RR was also included in
   this update.

   5 - Notes on Resource Consumption

   A TUE RR will require the primary master will initiate an automatic
   update approximately O(log2(TTL)) times over the life of an expiring RR.
   Even for massively sized zones, this is not considered an inappropriate
   load on the primary master server itself.

   The network bandwidth consumed due to the use of TUE RRs is more
   noticeable, although for massively sized zones, the bandwidth
   requirements should flatten somewhat as many RRs will be automatically
   updated during any given cycle of NOTIFY and AXFR/IXFR.

   6 - Security Considerations

   This protocol suffers the same abject and intentional lack of security
   as [UPDATE], from which it inherits its basic semantics.  In the absence
   of DNS Secure Updates, this protocol should not be used outside of an
   enterprise network, and only with great care within an enterprise
   network.

   Expires November 1996                                          [Page 7]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   7 - Discussion Items for DNSIND and Namedroppers

   Should the server's response to a DEFUPD include an opaque cookie called
   a ``deferred update ID'' which could be used in future DEFUPD requests
   to cancel or replace a previous deferred update?

   Should automatic updates caused by a TUE RR be required to be batched up
   and processed at some minimum interval?  For example, if we only checked
   for half life and expiration once per minute, this might drastically
   reduce the number of NOTIFY/AXFR/IXFR cycles caused by any given zone.
   We would have to recommend that all zones in a given server not be
   synchronized to the same timer, lest a server with many zones cause all
   of its zones to change and require NOTIFY/AXFR/IXFR in the same second.

   Astute readers will have noticed that this proposal is a precise
   superset of [UPDATE], and by adding the optional behaviour and
   definitions of TUU and TUE to [UPDATE], we could do away with the
   separate Opcode for DEFUPD.  This was only possible up until the time
   [UPDATE] went to proposed standard, but hopefully the intent was clear.

   8 - References

   [RFC1035]
      P. Mockapetris, ``Domain Names - Implementation and Specification,''
      RFC 1035, USC/Information Sciences Institute, November 1987.

   [IXFR]
      M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February
      1996, <draft-ietf-dnsind-ixfr-06.txt>.

   [NOTIFY]
      P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes,''
      Internet Draft, March 1996, <draft-ietf-dnsind-notify-07.txt>.

   [UPDATE]
      P. Vixie (Ed), et al, ``Dynamic Updates in the Domain Name System,''
      Internet Draft, March 1996, <draft-ietf-dnsind-dynDNS-09.txt>.

   [DHCP]
      Y. Rechter, ``Interaction between DHCP and DNS,'' Internet Draft,
      February 1996, <draft-ietf-dhc-dhcp-dns-00.txt>.

   Expires November 1996                                          [Page 8]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   9 - Acknowledgements

   Yakov Rechter assisted in the design of this protocol.  Robert Elz
   assisted in the requirements definition.

   10 - Author's Addresses

      Paul Vixie
         Internet Software Consortium
         Star Route Box 159A
         Woodside, CA 94062
         +1 415 747 0204
         <[email-masked]>

   Expires November 1996                                          [Page 9]

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Fri, 08 Feb 2002 13:01:52 -0500

>consensus of the group so the protocol changes are on record and in the new

This is not strictly protocol change, more a protocol clarification,
the current RFC's do not talk about what authoritative server do if
they detect expired signatures.

>server periodically checking SIG expiration times.

There is another issue here, what to do with expired signatures
on load, IMHO the expired SIG should be dropped.

>the zone serial number?  (I think "no" personally, but there are open

This is the BIG ISSUE, AXFR-clarify clearly outlaws any changes in
contents of a zone without updating SOA, (this is a requirement to be
able to support IXFR). In this case only the primary master for the zone
can purge expired signatures and when it purges expired SIGs SOA
serial number MUST be updated in order to enable IXFR update to other 
authoritative servers and/or to trigger AXFR. Having said this,
purging is now only possible by servers that have zone signing key
on-line.

This brings us to what gets put into the answers:
Principle: Servers should never put known bad data into answers.

 From this principle authoritative servers should not put expired
signatures into answers. Recursive security aware servers MUST NOT
cache these signatures.

Q1: Is it good enough to have the recursive servers purge the expired 
signatures?

Q2: What should a authoritative server do when it detects that
ALL signatures for the SOA or the whole zone are expired ?
My answer: Same as if the SOA was malformed, refuse to load the zone.

         Olafur

---

From: Rob Austein <[email-masked]>
Date: Fri, 08 Feb 2002 13:10:59 -0500

Um, -why- does SIG need this special processing?  Current model is
that TTLs and the SOA parameters control whether or not the resolver
sees the SIGs, while expiration time is a separate thing that the
verifier has to check anyway.  If this is broken, please explain how.

---

From: Roy Arends <[email-masked]>
Date: Fri, 8 Feb 2002 19:36:43 +0100 (CET)

> to autoincrement the serial number and show this delta in IXFR's.

Not to mention:
- Regenerate SOA sig's
- Resign the RRsets which TTL values has changed
- Drop the RRset which had the associated dropped SIG (or use Opt-In)
- Regenerate NXT records
- Resign NXT records

Roy Arends
Nominum

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 8 Feb 2002 15:06:38 -0500

Forgot about the NXT stuff.  Then dropping the SIGs results in masive zone
changes (every NXT record - assuming all SIG records expire at the same time
for a given RRset).

So expired SIGs shouldn't be dropped, but should they be excluded in
responses?  The servers job of checking every SIG in a response it sends out
would be a larger cost than passing it on to the clients to check.

But should this be enforced by the protocol?  (i.e. "A security aware server
MUST NOT place expired SIG records in a response")

Scott

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2002 15:49:57 -0500

Rob's message led me to ramble thusly, not necessarily a direct response to
his question:

The issue is what happens when an authoritative server receives a query.
If the CD bit is on, then the authoritative server will return whatever it
has, old, good, future sigs and all.  With the CD bit off, the
authoritative server (perhaps) answer with data only if there is a current
signature to cover it.

We haven't defined the semantics of an RRset that has no current signature
in a signed zone.  (I.e, all SIGs have expired, are in the future, or both.)

At a cache server, the same treatment should happen.  A cache server should
always issue queries with the CD bit on.  The question is whether the cache
server holds answers that fail it's policy.  If they are held, then I could
get bad data with a CD query, if not I can't.  In the former, perhaps the
data would pass my policy and it would be nice if the cache had it to give
me.

The issue is whether the data is checked on arrival or on departure.  On
arrival  is more efficient (as data may be retrieved more often than it
arrives).  On departure (with no CD bit) is more accurate.  Even if the
data has a bit set on arrival (in server memory) regarding the result, this
won't guarantee an approximation of checking on departure as the validation
depends on external items (other keys).

>verifier has to check anyway.  If this is broken, please explain how.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

---

From: Rob Austein <[email-masked]>
Date: Fri, 08 Feb 2002 16:48:46 -0500

Assuming that I understood Ed's explanation, this looks like a classic
end-to-end vs middlebox problem.  I don't really believe in the
middlebox flavor of DNSSEC anyway (see "Betrayal By Trusted Server" in
draft-ietf-dnsext-dns-threats-00), so further hairing up the protocol
to support the middlebox case seems ill-advised to me.

Another way of looking at the same thing is that this is a layering
issue.  TTL controls the low-level caching behavior, which is
hop-by-hop.  Signatures are at a higher layer and are strictly
end-to-end (data generator to data consumer).

---

From: Derek Atkins <[email-masked]>
Date: 08 Feb 2002 16:39:49 -0500

> would be a larger cost than passing it on to the clients to check.

Yes, they should be included in responses.

> MUST NOT place expired SIG records in a response")

IMHO: Absolutely not.  The server should definitely complain about
expired SIGs, but it should still place them in the response.

-derek

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2002 17:18:59 -0500

>to support the middlebox case seems ill-advised to me.

Not complete sure of understanding myself either, you definitely hit the
issue right.  If the end unit of the process did the validation, there's no
question that the servers along the way should just send all they get -
good or bad.  This benefit would be that any end point could see what is
clear across the network (minus the latency of the speed of light/packets).
We've inserted this telephony notion of a dumb end unit that relies on
something in the core of the network, and therein lies the problem.

>end-to-end (data generator to data consumer).

Yes.  But now we need to decide if the consumer is the last name server to
see the data or the stub resolver.  (Keeping in mind that the last name
server may be the source.)

Thinking deeper, it seems the check on send (if the Checking Disabled is
off) would achieve the goal of pushing the check as close to the end unit
as possible.  However, it has been rightly noted that check on send is less
efficient than check on receipt.  For the implementors of servers, checking
on send is much less palatable than sending on receive for reasons that are
solid from a software engineering point of view.  But it seems to me that
checking on send has other benefits, including enabling pushing the
decision of good/bad as close to the periphery as possible.

Perhaps some servers should refuse to answer queries with the CD bit is set
to on.  This would allow servers, such as the roots, remain able to run in
an answer-only mode with no computation required.

?

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 8 Feb 2002 09:35:57 -0800 (PST)

> might occur, but that is not a protocol issue, but an operational one.

What is this change supposed to accomplish?  If SIGs have expired,
resolution will fail whether they are included in the response or not.
It seems to me that omitting them would only make it harder for the
client administrator to diagnose the cause of the resolution failure.
-- 
Andreas Gustafsson, [email-masked]

---

From: Rob Austein <[email-masked]>
Date: Fri, 08 Feb 2002 22:57:05 -0500

> server may be the source.)

The consumer is the application, but the DNS-speaking-entity closest
to the application is the resolver.

---

From: Robert Elz <[email-masked]>
Date: Mon, 11 Feb 2002 12:02:45 +0700

Date:        Fri, 08 Feb 2002 13:01:52 -0500
    From:        Ólafur  Guðmundsson <[email-masked]>
    Message-ID:  <5.1.0.14.2.20020208123717.03268ca0@localhost>

This has been one of the wildest suggestions I've seen recently, even
on namedroppers.

  | This brings us to what gets put into the answers:
  | Principle: Servers should never put known bad data into answers.

That's certainly true.   But an expired SIG isn't "known bad data" it
is just data that you're not expecting will be of value to the receiver.
If we start asking servers to edit their responses based upon what they
believe that is actually going to be useful, or the even the server's
theory of what is "bad", then we really are making a mess.

Just consider another example - suppose a server is authoritative for
its own name.  That is, it holds its own A records.   Suppose some client
requests the server's A records.   Since the server is monitoring its
interfaces to watch for incoming packets, it is entirely believable that
it might know that one of its addresses is not working right now.  That is,
that A record is "bad" (by some definition of bad anyway).   Are you suggesting
that in such circumstances, the server should omit that A record from its
reply?

More than that, the best way to diagnose the DNS is to send queries at
servers, and evaluate the responses.   The reason this works is that that's
the one way that you can see exactly what the server is telling the world
(no gazing at config files will ever achieve that).

However, if servers start editing their responses, because the data is no
longer useful, how is it ever going to be possible to really diagnose what
is happening, and why?

  | From this principle authoritative servers should not put expired
  | signatures into answers. Recursive security aware servers MUST NOT
  | cache these signatures.

No.   If it is in the zone, it is valid data.   That it might be useless
to its user is irrelevant.  Servers MUST serve the data they have been
configured with, correct or not, useful or not.   Anything else is anarchy.

  | Q1: Is it good enough to have the recursive servers purge the expired 
  | signatures?

A server implementation that noticed that a large bunch of signatures have
expired could do an auto-update I guess, and delete them (and do everything
else an automatic update of a zone file would do).   This will not, and
cannot, remove the sigs that it sent out a few seconds ago, and nor should
the server start playing TTL tricks to cause those to be expired early
(and certainly not without being certain that all the server for the zone
are playing the exact same tricks - the TTL is a part of the RR, all 
authoritative servers for a zone must issue the same TTLs for the same
RRs in answers).

  | Q2: What should a authoritative server do when it detects that
  | ALL signatures for the SOA or the whole zone are expired ?
  | My answer: Same as if the SOA was malformed, refuse to load the zone.

This one is certainly just a quality of implementation issue.   Different
users are likely to want different results.   A good implementation is likely
to have a (per-zone probably) switch that can configure what will happen
there (generate SERVFAIL, generate non auth answers, just act as if nothing
happened and return expired SIGs, ...)

kre

---

From: Paul Vixie <[email-masked]>
Date: 11 Feb 2002 06:44:15 -0800

> Just consider another example - suppose a server is authoritative for its
> own name.  That is, it holds its own A records.  Suppose some client=
> it might know that one of its addresses is not working right now.  That
> is, that A record is "bad" (by some definition of bad anyway).  Are you
> suggesting that in such circumstances, the server should omit that A
> record from its reply?

i know you're trying to show a deliberate absurdity here, but you apparently
don't know that a number of local- and wide-area load balancing products now
on the market do EXACTLY that kind of editing.

the designers of these products believe that DNS is a mapping function rather
than a distributed coherent autonomous reliable database.  there is no Truth
to these implementations, only Opinion.

so while it is absurd, it's not a good example of absurdity, because it's
quite widespread and has even been spoken of with respect by some.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 11 Feb 2002 13:54:50 -0500

>the client from something it HAS to be able to deal with ANYWAY?

The whole point of this question was to get discussion started on
what is acceptable behavior, proposing a particular behavior
jump started the discussion.

         Olafur