Re: Summary: What to do with expired signatures

Paul Vixie <paul@vix.com> Sat, 16 February 2002 03:42 UTC

Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28090 for <dnsext-archive@lists.ietf.org>; Fri, 15 Feb 2002 22:42:22 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1) id 16bvOE-0000HS-00 for namedroppers-data@psg.com; Fri, 15 Feb 2002 19:19:54 -0800
Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.33 #1) id 16bvOD-0000HM-00 for namedroppers@ops.ietf.org; Fri, 15 Feb 2002 19:19:54 -0800
Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 7E50928EB0 for <namedroppers@ops.ietf.org>; Fri, 15 Feb 2002 19:19:52 -0800 (PST) (envelope-from vixie@as.vix.com)
From: Paul Vixie <paul@vix.com>
To: namedroppers@ops.ietf.org
Subject: Re: Summary: What to do with expired signatures
In-Reply-To: Message from "Paul V. Mockapetris" <pvm@a21.com> of "Fri, 15 Feb 2002 18:10:09 PST." <4.2.0.58.20020215175638.02707078@127.0.0.1>
X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1
Date: Fri, 15 Feb 2002 19:19:52 -0800
Message-Id: <20020216031952.7E50928EB0@as.vix.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> Yeah, but servers that can load zone files should get the same result.

I'm fine with that.  But making the ability to "load" a "zone file" a
prerequisite to "standards compliance" is what I couldn't understand.
So, logic like...

	IF (the capability to load zone data from external files exists)
		THEN (you must be able to parse $TTL in all its glory)
		ELSE (you can still call yourself standards compliant)

...wouldn't be a problem, even though it would also be completely useless
text to put into a standards document.

> So a better way to decide this is just to have the argument about whether a 
> text format for zone data is still useful or not, rather than whether it is 
> possible.

I think it's useful.  Among my servers that can load zones, I copy zone
files all the time.  But once upon a time someone yammered at me about
how my slave zones had to be stored in $TTL format and I had to
impolitely demure.  Slave zones stored in Lisp format, or AXFR format,
or SQL format, don't make your DNS implementation less
standards-compliant.  And by that logic, a master server which could
only serve zone data from SQL or from its own internal format that was
managed by RPC or DNS UPDATE or what have you, is also completely
conformant.

The lack of an ability to read a zone file just doesn't seem meaningful
from a standards point of view.  It's only in the narrow case where an
implementation clearly has an "import" facility but $TTL and its friends
aren't supported by it that standards conformance would come into play.
The narrowness of that case equates to irrelevance in my considered
opinion.

Making zone file format its own RFC so that implementations can either
support it or not without affecting their "support level" of "DNS itself"
would seem to be the right way out of this argument.

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