[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

DNSEXT WGLC Summary: AXFR clarify

Erik,

DNSEXT has completed it's review of this document and requests that
it be advanced to Proposed standard. This document updates RFC1035,
actually it fills in a under specified section.
Unfortunately the current version has expired, until author can post a
identical new version here is the last version
http://users.starpower.net/ogud/draft-ietf-dnsext-axfr-clarify-04.txt

thanks
        Olafur



X-Sender:  (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 01 Mar 2002 01:57:16 -0500
To: namedroppers@ops.ietf.org
From: Ólafur Gudmundsson/DNSEXT co-chair <ogud@ogud.com>
Subject: DNSEXT WGLC Summary: AXFR-02.txt
Sender: owner-namedroppers@ops.ietf.org


This last call concluded a long time ago, it is this chairs fault for
not posting the consensus sooner, Sorry everyone.

The working group rough consensus is to advance the document with minor
changes as outlined below.
There has been strong objection from certain well respected member of
the working group.
The main objections can be summarized in two major points:

1. He objects to the restriction that all data go in answer section,
he wants section agnostic rules.

There is no technical reason why one is better or worse than the other.
All implementations but ONE, put all AXFR data in ANSWER section, thus
that is less disruptive to formalize.

2. He objects to the restriction that AXFR MUST contain exactly the
data that the master server loaded from zone file.
Most early implementations did not comply with this rule, but some
did, the old implementation that became the de-facto standard for DNS
allowed data to leak between zones.
This has certain beneficial behavior for delegations if data from
children is better than parent, but has the following drawbacks
    a. AXFR of the same version of a zone from two servers may
       differ.
    b. IXFR updates may fail due to preconditions not being true,
       this was not explained in IXFR document.
    c. Dynamic Update may fail due to preconditions (not explained
       in Dynamic Update RFC).
    d. Diagnosing problem is harder as answers differ between
       Authorative servers.

Since the AXFR last call concluded the working group had extensive
discussion on similar issue: if DNSSEC servers could drop expired
signatures.
The working group expressed a strong and clear consensus on this
issue:
Authorative Servers MUST not change or discard any zone data, even if
the server can determine data is wrong/bad.

This counters objection #2.

The Author has made all changes to the document that are needed, but
the document has expired, Andreas please resubmit before deadline.

<snip suggested change that author and WG rejected>


         Olafur


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