Re: DNSSEC *can* retrieve "A" and "KEY" records in the same query

Re: DNSSEC can retrieve "A" and "KEY" records in the same query

Paul A Vixie <paul@vix.com> Fri, 13 September 1996 05:20 UTC

Received: by gw.home.vix.com id WAA06099; Thu, 12 Sep 1996 22:20:59 -0700 (PDT)
Received: by wisdom.home.vix.com id AA08661; Thu, 12 Sep 1996 22:20:59 -0700
Message-Id: <9609130520.AA08661@wisdom.home.vix.com>
To: John Gilmore <gnu@toad.com>
Cc: dee@cybercash.com, chk@border.com, perry@piermont.com, ipsec@TIS.COM
Subject: Re: DNSSEC *can* retrieve "A" and "KEY" records in the same query
Date: Thu, 12 Sep 1996 22:20:54 -0700
From: Paul A Vixie <paul@vix.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

> The ability to retrieve keys along with A and NS records reduces
> long-haul round trips, because the keys will be cached and can be
> retrieved from the local cache.  There are currently no applications
> which ask for both A and KEY records.  The app (typically) asks for A
> records with gethostbyname to open a TCP connection.  When the first
> TCP packet comes out, a key management daemon (on the same host, or on
> a S/WAN gateway) asks for the KEY records.

The DNS caching model calls for each resolver to have a cache.  BIND
implements this with a stub resolver and a statically configured list
of caching forwarders.  Windows and the other DNS clients emulate BIND
in is regard.

If the KEY RR comes in as additional data from the authority server
when it answers someone's caching forwarder, the KEY will be cached
and the stub resolver will be able to retrieve it "locally."  In other
words this isn't ideal or pretty but it should work without massive
performance problems.

Message-Id: <3.0b16.32.19960913111912.00a46008@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b16 (32)
Date: Fri, 13 Sep 1996 11:23:40 -0400
To: caronni@tik.ee.ethz.ch, Robert Moskowitz <rgm3@chrysler.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: SKIP in IPSEC: is it really simple?
Cc: HUGO@watson.ibm.com, skrenta@osmosys.incog.com, ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

At 07:03 PM 9/12/96 +0200, Germano Caronni wrote:
>Robert Moskowitz wrote:
>> >no reliance on shared time, 
>> very goodness
>
>How do you plan to handle certificate expiry without shared time?

When you factor in proper business practices (not those that verisign
practices), the slew for cert expiry is much greater than for secure hand
shakes.  In fact, a business goal for a registery is to reissue a cert n
months before expiry unless there is a REAL business reason (chapter 11 or
worst) to totally trash their cert.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Re: DNSSEC *can* retrieve "A" and "KEY" records i… Paul A Vixie