RR Text format (was: Re: Summary: What to do ...)

[Ólafur Guðmundsson <[e-mail]>]

At 11:33 AM 2/18/2002, Paul Vixie wrote:
>eric just said, in comments directed at robert:
>
> > 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?
>
>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.


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


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 


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