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

From: "Paul V. Mockapetris" <[email-masked]>
Date: Sat, 16 Feb 2002 08:58:49 -0800

At 08:54 AM 2/13/2002 -0800, Paul Vixie wrote:
> > > All zone changes are made by RFC2136 "UPDATE" requests.  There is no
> > > "load" and there is no "zone file" and there is no way to map your
> > > "implied delete" to any process that it has.  Yet this server is entirely
> > > protocol compliant.
> >
> > as the docs do specify a zone file and format, this is interesting.
>
>Yes.  Since at no time in any interoperability workshop has it ever happened
>that one implementor handed the other a *.TXT file and said "read this and
>serve it so we can test interoperability", I can legitimately claim that a
>server which does not parse "zone file format" and does not have a concept
>of "loading" a zone is completely protocol compliant.

Interoperability and/or interoperability testing happened several times in 
the past, and among those times, one was to allow some newfangled DNS 
server call bind to interoperate with another  UNIX implementation of DNS 
from Stanford and the old TOPS20 implementation.

>   On the wire, you just
>can't tell how the other guy deals with backend storage of zone data.  And
>if an implementation can pass every possible on-the-wire compliance and
>interoperability test you can devise, then they are fully compliant with the
>protocol.

Yeah, but servers that can load zone files should get the same result.  If 
they don't, zone files shouldn't be either a standard or a BCP, so maybe we 
are in agreement.  But it should be testable if the specs are written 
correctly.

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.

>This supports my earlier statement that zone file format should be a BCP
>rather than a PS.  You can't have a PS that is by its nature untestable,
>according to my reading of the IETF charter documents.
>
>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: "Eric A. Hall" <[email-masked]>
Date: Sat, 16 Feb 2002 12:10:33 -0600

"Paul V. Mockapetris" wrote:

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

From my PoV, the two compelling features are portability and directives.
The latter is probably the more important of the two in the current
environment. I think we need more directives, such as a directive that
applies to all entries in a zone (a $DEFAULT or something) so we can set
an MX for all defined and undefined entries. My IDNS draft also called for
a $UTF-8 directive to indicate the charset in use with the zone file. So
at the least, before the zone file format can be deprecated, we would have
to come up with a way to define directives outside of a zone file (a
"directive" RR that was bound to the top of the zone could do this, I
suppose, in a weird sort of way).

I think more work needs to be done on the zone file if it is kept, and I'm
in favor of keeping it. There should be a definition of line formats,
end-of-line markers, etc. So having it in a separate document makes some
sense from this perspective. There is plenty of precedent for having a
data-format specification supplementing a protocol specification (see
[2]822, HTML, etc) so this wouldn't be unheard of.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Stefan Arentz <[email-masked]>
Date: Sat, 16 Feb 2002 20:32:04 +0100

On Sat, Feb 16, 2002 at 08:58:49AM -0800, Paul V. Mockapetris wrote:

...

> from Stanford and the old TOPS20 implementation.

This is a bit off topic so I'm putting it in another thread.

Are there any tools or test suites available to test for RFC compliance? We
have created several tests in which we compare query results with the output
of Bind, but it's far from complete.

I think the whole DNS developer community would benefit from such a test suite.

Anyone interested?

 Stefan

---

From: Paul Vixie <[email-masked]>
Date: Sat, 16 Feb 2002 19:18:47 -0800

> I think the whole DNS developer community would benefit from such a

yes.  but, funding it has been a problem.  isc's new BIND Forum ought,
if successful, provide the continuous background funding needed for
this kind of task.  we'll certainly let y'all know.

---

From: Robert Elz <[email-masked]>
Date: Mon, 18 Feb 2002 13:54:21 +0700

Date:        Sat, 16 Feb 2002 12:10:33 -0600
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | "Paul V. Mockapetris" wrote:
  | 
  | > 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.

It isn't whether the text format is useful, it is whether standardising it
is the right thing to do which is the issue.   I don't think I'd survive
with anything that didn't keep data in text file format, I like to be able
to use all the standard tools (grep, ...) on the data (and that includes
secondary data).   But I don't care in the slightest if my files look much
like your files, or anyone else's.  Nor do I mind that there are others for
whom text file format is an ancient anachronism from the dinosaur era, and
who have no need for anything like that.

I do appreciate that in the early days having the implementations use a
common format was useful - it allowed exchange of data when AXFR wasn't
all that reliable.  These days, it makes no sense.

[Aside: if interop testing was done with (early) BIND's text file format,
and others, then it must have been pretty pathetic testing, BIND's parser
for the text file was only occasionally related to what the RFC specifies,
the variations were almost as common as the compliances].

  | There is plenty of precedent for having a
  | data-format specification supplementing a protocol specification (see
  | [2]822, HTML, etc) so this wouldn't be unheard of.

Bad analogy.   Those specify the format of data that is interchanged between
two systems.   So does the DNS, but it isn't the text file format.   The
equivalent analogy for e-mail would be mailbox format, and that's something
that certainly isn't standardised (though there are some common formats).
The arguments for standardising it are exactly the same as those in favour
of standardising the DNS text file format (once we accept that AXFR now works)
but they're not nearly good enough to win.

kre

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 18 Feb 2002 12:51:26 +0100

> all that reliable.  These days, it makes no sense.

I'd refrain from saying that AXFR is "all that reliable" -- for some of us
AXFR'en have stopped working for certain zones. But we are a very small
minority, perhaps 4 or so large TLDs and their slaves. ;-)

Toungue firmly in cheek, ftp'ing his slave zone every day.
-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 18 Feb 2002 09:21:28 -0600

Robert Elz wrote:

> It isn't whether the text format is useful, it is whether
> standardising it is the right thing to do which is the issue.

There are valid reasons why people want it. What are your valid reasons
for preventing other people from having it? I mean, as weak as the
arguments for a standardized out-of-band replication system may be, there
are no valid arguments against it that I can think of. So the question
really is, why should we not clarify it? What is the cost?

> The equivalent analogy for e-mail would be mailbox format, and that's
> something that certainly isn't standardised (though there are some
> common formats).

Except that mbox has never been defined in a STD, while this one has.
Another example of this would be LDIF (albeit not an STD), and to lesser
degrees, things like bootptab which have been described as examples.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 18 Feb 2002 11:29:50 -0800

Eric,

An unintended consequence of moving the foci of XPG / POSIX standardization
from sections 2, 3, 4 (kernel, library and driver APIs, respectively) and
section 5 (file formats), to sections 1 and 8 (usr and root cmds), was that
the white spaces in the output of the long format (-l) of the ls.1 got
specified. Naturally, the standards conformance test suite eventually
included a test for the -l option of ls. Mercifully, I've forgotten which
way was "wrong", N spaces or N/8 tabs, but the fix (to obtain conformance)
broke more tools that harbored secret knowledge about white space ... 

Now there really was a good reason to specify this, it is handy when the
l10n guys and gals are putting in inobvious date formats with surprising
display character length properties, but we hadn't thought of that at the
time we took that sip of the standards koolaid.

Uh, I was a primary co-author of Spec 1170, so the egg is on my, err, napkin.

I've no problem with the whois-fix proto-wg attempting to find-and-fix (or
search-and-destroy) the odd whois (or isn't) formats. More fun with lex and
yacc. However, the utility of standardizing the text format here escapes me.

Eric

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 18 Feb 2002 11:03:15 -0600

Eric Brunner-Williams in Portland Maine wrote:

> the utility of standardizing the text format here escapes me.

Two reasons: out-of-band zone replication which contributes towards
overall stability of the Internet's namespace, and zone directives. The
latter will have to be replaced with something else before the file can be
deprecated, but moreover, I can't think of a good reason to deprecate it
in the first place. Clearly it is useful. I would like to hear arguments
that it is unuseful and an interoperability hazard of such magnitude that
the loss of stability afforded by a common import/export format (at least)
is worthwhile. Anybody?

Okay then, well, if we aren't going to deprecate it, would a clarification
of the spec that redefined the purpose (import/export, not the backend DB)
and the structural format of the file be such a resource drain that the
effort should not be undertaken? What is the limiting resource here?
Wouldn't such an effort strengthen the benefits?

I'm certainly comfortable with a MAY clause so that implementors don't
have to mess with it if they don't have the resources. But otherwise it
offers some pretty important features. Best for the Internet community to
spend a few cycles cleaning it up, I would think.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Feb 2002 08:33:30 -0800

> really is, why should we not clarify it? What is the cost?

as long as it is clarified that the whole thing is optional, that's fine.

because a number of interoperable-on-the-wire dns implementations don't
have a concept of "loading" or even "importing" their authoritative data
except via AXFR or DYNUPD or out-of-band methods such as SQL, and it
would be factually wrong of this WG to call these "nonstandard".

the ability to "load" a "zone file" is often QUITE useful, and so many
implementations (including BIND) have implemented and will continue to
implement it.  and it makes _great_ sense, at the system design level,
for there to be a standard "zone file" format to make OOB zone transport
easier.

this discussion isn't about whether it's useful, or whether the format we
use is a good one, or whether it can be or should be extended.  the topic
at hand is: can a DNS implementation which doesn't "load" zones at all but
is still interoperable-on-the-wire for udp/53 and tcp/53 be thought
incomplete from a standards point of view?  i say "no, that's fine, such
an implementation is still complete from the DNS standards point of view."

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 18 Feb 2002 12:20:07 -0800

> overall stability of the Internet's namespace, and zone directives

I'm at a loss to understand the first assertion offered. Oh well. ENOCLUE.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 18 Feb 2002 16:15:05 -0500

>as long as it is clarified that the whole thing is optional, that's fine.

Paul,

for the last few years I have called the text format "presentation format"
as that is where the main use is.  For looking at the results
of a lookup and recognizing quickly the content of the answer.
Because that dig, DnsExpert, DNSjava, nslookup, NET:DNS, and Qdns,
all use similar output, derived from the presentation formats in the RFCs
I can use these tools interchangeably.

There is no reason why any server should be required to be able to load
from that format. And for performance reasons using the text format
specified by nameserver is suboptimal due to parsing overhead.

Having said that it is nice to be able to cut and paste output from dig
into a zone file either directly or via a tool.

>an implementation is still complete from the DNS standards point of view."

We could not agree more.
If/when DNSSEC and/or IDN happens there will be much more need for
separating the view that the administrator sees to what is given
to the nameserver. DNSSEC signer in this case could read a regular
zone file but output a file in wire format, another way is that
the signer sends dynamic updates with the new signatures, in this
case there is no need for the server to ever understand "text zone file."

         Olafur

---

From: Greg Hudson <[email-masked]>
Date: 18 Feb 2002 16:50:44 -0500

On Mon, 2002-02-18 at 12:03, Eric A. Hall wrote:
> overall stability of the Internet's namespace, and zone directives.

(Zone directives?  I don't get it.)

There is certainly utility in being able to replicate zones out of band
between different nameserver implementations, but is the value
compelling?

Should the IETF try to standardize the format of the aliases file used
by MTAs?  The format of access permissions files used by FTP and HTTP
servers?  The format of mailbox files used by an IMAP server?  All of
these standards would facilitate the distribution of services among
heterogeneous server implementations, as well as the gradual migration
of a distributed service from one implementation to another. 
Nonetheless, we don't try to standardize those formats because it would
be a waste of time.  Implementors don't generally see enough value in
this kind of interoperability to prevent them from making little
improvements to or wholesale reinventions of those data formats.  They
write import tools to help people migrate from other implementations to
their own, and usually leave it at that.

---

From: Randy Bush <[email-masked]>
Date: Mon, 18 Feb 2002 14:25:24 -0800

the fact is that, whether we like it or nor, zone file format is a formal
ietf standard.  the question is whether would-be historical revisionism
should be a high priority item for this wg.  imiho, it isn't.

  o we have open questions from the dnssec document team
  o we should close on restrict-key
  o we may have cooled off enough to discuss opt-in
  o the usual collection of 42 ids to discuss
  o ...

randy, with co-chair hat on

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Feb 2002 00:39:18 +0100

> between different nameserver implementations, but is the value

The point is pretty moot - even without exact interoperability, zone files
are semantically all identical - RFC 1035 is quite explicit about 'records'
and how they need to be traversed to generate anwers to DNS queries.

So whatever format you think up, it is always possible to convert it to any
other format that complies with basic DNS specifications regarding records
and zones.

Even 'zone directives' can easily be expressed by explicitly supplying TTL
per record.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc