Subject: Re: Summary: What to do with expired signatures

From: Brian Wellington <[email-masked]>
Date: Mon, 11 Feb 2002 20:48:05 -0800 (PST)

On 11 Feb 2002, Derek Atkins wrote:

> Brian Wellington <[email-masked]> writes:
> 
> > On Mon, 11 Feb 2002, Ólafur Guðmundsson wrote:
> > 
> > > Authorative servers SHOULD log any errors they detect in zone files.
> > 
> > Is it the feeling of the working group that expired signatures are
> > considered an error?
> 
> I believe that, in terms of server _LOGGING_, expired signatures
> should be considered errors.  I do NOT believe that a single expired
> signature should cause the zone-load to fail.

Sounds pretty reasonable to me.

Brian

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: Paul Vixie <[email-masked]>
Date: Fri, 15 Feb 2002 19:19:52 -0800

> 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.