Subject: AXFR "clarify"

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Jan 2008 17:48:09 -0500

Here's a work topic I'd like to get moving, something that got 
stalled almost 5 years ago.

Starting from
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-axfr-clarify/
and probably most notably the objections raised on this web page [0]:
http://cr.yp.to/djbdns/axfr-clarify.html

[0] That's the only document I could find of the objections, but they 
appear to be somewhat out of date with respect to the -05 version.

The reason I want to address this is that a number of industry 
requests are coming out requesting "AXFR" access to databases and 
they RFPs want a list of RFCs that specify compliance. Yes, I'm 
asking for a paper exercise here, I want to be able to respond with 
"yes, we comply with RFC 7xxx".

I tried (weakly I admit because I want to get on with this) to get 
the background on this document from some people without a response. 
That's no condemnation on any of the parties involved, but I hoped to 
have something to show before bringing this up to the WG.  Because I 
know passions run deep on this list.

With the permission of the chair and working group, I'd like to take 
stab at rewriting the draft, in the spirit of the wildcard "clarify" 
document.  In my opinion, the -05 needs to be fixed in a few places 
although I don't recognize the problem points that caused Dan 
Bernstein's objections - I mean as far as what in the -05 causes 
interoperability problems.

In the web page I cite above Dan made a few good points, but it seems 
that those points were levied against earlier versions of the 
document and were addressed for the most part by -05.

One of the tones I'd like to change is to have the document recognize 
that inter-server zone replication can be done many ways, AXFR is 
just one, the one least functional, most interoperable way defined. 
Much as 1034's wildcards are just a subset of record or answer 
synthesis.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

--
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: Mark Andrews <[email-masked]>
Date: Fri, 18 Jan 2008 13:52:27 +1100

The first thing the WG has to decide is which document we
	are producing.

	* a document that allows for future growth and removes
	  implementation quirks.
	  [Some implementations will not be conformant with the new
	   specification.  Known quirks should be documented but
	   should not be accepted by default.]
	
			or 

	* a minimal change document which allows leaves all existing
	  implementations comformant.

	I believe most of the issues are because Dan percieved the
	that the later was what was requested but the former was
	what was coming out.

	I believe we should be producing a document that allows for
	future growth and removes implementation quirks.

		---------------------------------------

	One thing that is missing is case preservation of rdata
	when using compression.  This is a general requirement of
	DNS servers.

	When using label compression the master server MUST choose
	compression targets that preserve the case of the original
	domain name.

	In general, most servers are overly agressive when applying
	compression and do not met the spirit of RFC 103[45] when
	it comes to preserving case.  This applies in general not
	just AXFR.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Jan 2008 22:20:45 -0500

>	   should not be accepted by default.]

No!  I feel strongly that this is not what we want.

We don't need innovation in DNS now.  It's good.  There's a lot of 
work being done based on what it is, not what it may be.  I really 
like it as it is - it has too much already even.

And the worst thing the IETF can do is declare working DNS 
implementations (meaning they meet the needs of the application) 
invalid because of nuances or the desire for feature bloat.

>	  implementations comformant.

That's what I want.  I prefer not to change the world, it's a paper 
pushing exercise.

>	that the later was what was requested but the former was

I can see that.  I sympathize with both sides, but I somewhat agree 
with what *I think* is Dan's side.  It's hard to say without talking 
to him.

>	future growth and removes implementation quirks.

I don't.  And the folks that are asking us to be clear on AXFR 
prioritize meeting the de jure understanding of AXFR.

Well, maybe a mention of an issue like this, but really, does it 
matter?  E.g., the world cares more about IDN than capitalization. 
I'm no longer really interested in maintaining the spirit of 1034 and 
1035 if it becomes an obstacle to getting a useful definition of DNS.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 18 Jan 2008 03:31:42 +0000

this can be a SHOULD but not a MUST.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Jan 2008 15:50:41 +1100

> We don't need innovation in DNS now.

	I said *allows* for innovation.  The current draft prevents
	innovation as it encodes forever a implementation bug,
	garbage message id's.

	There is nothing innovative about wanting to be able to
	check message id's of incoming AXFR streams and rejecting
	(or warning about) them if they don't match the AXFR's query
	id as default behaviour.

	Declaring nameservers that don't set the message id to that
	of the query as broken is a good thing.

> It's good.  There's a lot of 

	Actually it isn't.  The worst thing the IETF can do is produce
	wishy washy specification.
 
> That's what I want.  I prefer not to change the world, it's a paper 

	The world's already changed and will continue to change.

> 1035 if it becomes an obstacle to getting a useful definition of DNS.

	Well if you don't want to take implementors experiences into
	account...

	People DO care about this.  I've got the bug reports to
	prove it.

	Mark

---

From: Paul Vixie <[email-masked]>
Date: Fri, 18 Jan 2008 05:17:59 +0000

> 	of the query as broken is a good thing.

i agree, having at least once made a coding mistake that mixed my outbound
axfr streams and sent A's to B and B's to A.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Jan 2008 09:47:41 -0500

>	of the query as broken is a good thing.

You mention innovation and then give an example that is unrelated.

As far as innovation, what I want to avoid is any discussion of the 
use of the other sections of the message AXFR does not make use of 
now (like Authority).

When it comes to tightening up a requirement like you mention, I 
think that we need to hear from more implementers that such a change 
is desired.

>	wishy washy specification.

Which it already has done.  The worst next thing is to break the 
world we built on a bad foundation.

>	The world's already changed and will continue to change.

Engineers love to believe that, but some elements don't change.  The 
DNS is nearing that point.

>	People DO care about this.  I've got the bug reports to

This is the first I have heard of it.  Anyone else?  And in that 
vein, a soapbox moment:

I want to issue this challenge to the implementers on this list.  A 
lot is heard about ISC's BIND experience.  ISC has been energetic in 
contributing to the process.  But the volume of the contribution 
sometimes backfires, and one victim has been the axfr-clarify 
document.  To make a clarification, or an updated definition, have 
merit it needs to be based on a broad spectrum of implementation 
experiences.

The goal is not to declare, by default, the BIND way of doing DNS as 
a standard.  The goal is an interoperable definition.  The experience 
of BIND yields a wealth of information to us, and that's valuable 
input.  The question is how can the document benefit from the BIND 
reports without becoming BIND centric?  The answer is to have input 
and reactions from other implementations.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Mark Andrews <[email-masked]>
Date: Sat, 19 Jan 2008 07:34:08 +1100

> You mention innovation and then give an example that is unrelated.

	An example of innovations would be to multiplex responses
	down a TCP connection based on message id.  At this point
	a server HAS to serialize the responses as it can't expect
	the client to be able to distingish responses to based on
	message id.  It has to wait for the final SOA record to be
	transmitted before sending the next response.

> This is the first I have heard of it.

	I wouldn't expect you to hear as you are not a vendor.

	It's marked as "func" as it required a API change to implement.

1811.   [func]          Preserve the case of domain names in rdata during
                        zone transfers. [RT #13547]

	Those that want the fix are pointed to the version which contains
	the fix.

> Anyone else?  And in that vein, a soapbox moment:
>

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Jan 2008 16:07:55 -0500

>	transmitted before sending the next response.

How would that work.  The first message must have the SOA, the last 
too.  Everything in the middle can be jumbled every which way.  But 
if you allow that, how do you know that the first gets in first and 
the last gets there last?

If you are saying that we want to have two open AXFRs (for the same 
zone to the same client?) then we have other problems.  How is the 
client to know which is newer?  SOA serial numbers have to jump, but 
what I can concoct a scenario in which you can't tell the newer from 
the older.  And if we randomize message IDs, they aren't in any 
sequence either.

>	I wouldn't expect you to hear as you are not a vendor.

Then why hasn't the vendor brought this to the list?  Okay, maybe no 
one asked, that'd be a fair question.

So now I'm asking - anyone have a list of feature requests for the 
AXFR protocol?

I don't think we are opening the door to changes.  First steps are to 
have a definition of AXFR.  Then see if we want change things.

What I think is valid is to define AXFR in such a way to allow 
individual implementations to go off and do their own thing.  So long 
as there's some semblance of a basic set of interopeable mechanisms.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Mark Andrews <[email-masked]>
Date: Sat, 19 Jan 2008 08:25:13 +1100

> the last gets there last?

	Ed, please look up the definition of multiplexing in any
	communications text book.  I'm not going to do communications
	theory 101.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Jan 2008 19:49:50 -0500

>                         zone transfers. [RT #13547]

After thinking this over, this isn't an issue affecting the 
definition of AXFR.  This is a domain name compression issue.  You'd 
face the same issue (protocol wise) in any response message unit.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Mark Andrews <[email-masked]>
Date: Sat, 19 Jan 2008 12:34:58 +1100

> face the same issue (protocol wise) in any response message unit.

	I said it was a general issue.  People however worry about
	it more with AXFR than with other queries as AXFR provides
	a much larger set of compression targets.  It gets realised
	rather than being potential.

	Mark

---

From: Brian Dickson <[email-masked]>
Date: Fri, 18 Jan 2008 21:34:11 -0500

Edward Lewis wrote:
>>     I said *allows* for innovation.
>
> When it comes to tightening up a requirement like you mention, I think 
> that we need to hear from more implementers that such a change is 
> desired.
>
Such a change is desired.
Correct me if I'm wrong, but it doesn't matter what the deployed base 
is, or the state of the software, or where or how it's used.
Anyone doing any kind of implementation, for any purpose, of RFC 
1034/1035/1995/1996 has a chip in the game. Like me.
I vote for tightening up requirements.

In 1034/1035, the language is "should" (lower case). At a minimum it 
should be "SHOULD", and preferably "MUST".
(The irony of the case comparison between "should" and "SHOULD" is not 
lost on me.)

I see no reason that the language describing the behavior (recommending 
against changing case on rdata) should be ignored,
and the RFC text near that language, even contemplates potential reasons 
for this.
> Which it already has done.  The worst next thing is to break the world 
> we built on a bad foundation.
>
Just like the data described in the protocols (like 822):
(IMHO) Maintainers of RFCs should be liberal in what they accept, and 
strict in what they send.

If you are updating an RFC, the worst thing you can do is weaken a 
specification. In fact, it could/should be argued, that when the opportunity
to tighten up language *known* to be ambiguous, that it SHOULD be done. 
RFCs do not get updated that often, and this RFC is rather important
to the health of the Internet.
> This is the first I have heard of it.  Anyone else?  And in that vein, 
> a soapbox moment:
>
> The goal is not to declare, by default, the BIND way of doing DNS as a 
> standard.  The goal is an interoperable definition.  The experience of 
> BIND yields a wealth of information to us, and that's valuable input.  
> The question is how can the document benefit from the BIND reports 
> without becoming BIND centric?  The answer is to have input and 
> reactions from other implementations.
I humbly disagree

The issue is strictly interoperability between implementations, which 
needs to be based on very strong RFCs.

Interoperability is particularly critical for AXFR and IXFR.

Inadequately specifications can (and will, and may in the past have) 
lead to problems directly as a consequence of implementation choices 
which are incompatible.
And just as important - tightening up the RFCs lowers the barriers to 
new implementations which will interoperate with existing implementations.
New implementations are important to ensuring a healthy diversity of 
available code for operators.

Diversity is critical to protecting infrastructure.

Single implementation populations are vulnerable to zero-day issues, 
which for DNS is not a reasonable situation.

Case in point:
AXFR/IXFR are special, because of the need/desire to achieve performance 
optimizations due to the volume of data, and the fact that both ends are 
authority servers.

Consider a small mesh of servers, which for redundancy reasons includes 
multiple implementations. Data originates at a true, hidden master "M". 
Servers use software implementations, call them "B" and "N".

It is quite conceivable that [AI]XFR paths could look like:

M-N-N-B
  \            \
    B-B-B-B(client)

If the software "B" includes optimizations to determine the fingerprint 
of the upstream XFR sender, and quite reasonably assumes that case will 
be preserved on the XFR, it can then do simple binary comparison of 
labels, rather than a much slower byte-by-byte case-insensitive comparison.

However, if "N" does case-smashing, then the two paths will contain XFR 
data which differs in case, but is otherwise identical.

This *will* break the optimization. At the "client", the data from "N" 
path will be compared against data from the non-"N" path. Binary 
comparison of different-case data will fail, and zone data corruption is 
likely to occur (duplicate rdata differing only by case, specifically).

(I will avoid naming names, but this exact situation *has* occurred in 
the past, in production zone data, so it's not just hypothetical.)

Having case preserved specifically on XFR, is something much more 
important than any normal query/answer data.

And, IMHO, special attention SHOULD be paid to this, possibly specifying 
case preservation as a "MUST".

The *proper* place to do case-smashing is on the master (e.g. when data 
is imported into the DNS system), after which the issue can be viewed as 
moot.

If the data prior to XFR is single-case, then problems can't be 
introduced by trying to optimize case, nor is there any *need* to do 
case optimizations.

Brian Dickson

---

From: Edward Lewis <[email-masked]>
Date: Sun, 20 Jan 2008 10:36:26 -0500

>	rather than being potential.

In that case, it should be mentioned as something to think about when 
writing code but does not place any requirements on the AXFR 
mechanism.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Sun, 20 Jan 2008 11:04:09 -0500

>>  that we need to hear from more implementers that such a change is desired.
>>

Specifically, what change?  Before expecting that a change is going 
to be made because it is suggested, keep in mind "it had better be a 
gooood, really good change."

>is, or the state of the software, or where or how it's used.

In my opinion, the deployed base rules in this case. I don't see any 
consumer of DNS services (such as web site hosters, tld operators, 
home hobbyists) howling that they cannot locate DNS implementations 
that do AXFR.  In my opinion, and why I am motivated to do this, is 
that it is the specification that is lacking.  Keep in mind my 
concern is addressing RFPs and not writing a new implementation.

The IETF is all about interoperability and I don't hear that this is 
lacking in the AXFR space.  That is why, to me, the current code base 
rules.

>Anyone doing any kind of implementation, for any purpose, of
>RFC 1034/1035/1995/1996 has a chip in the game. Like me.

I don't think this is a a point of contention but I want to set 
expectations by at least revealing my interpretation of the 
situation.  I am for tightening up the requirements in the sense that 
they reflect reality.  I am not for raising the bar on functionality.

>(The irony of the case comparison between "should" and "SHOULD" is not

Updating the language is a good thing, as the IETF has evolved from 
an engineering organization to a standards body over time.

>against changing case on rdata) should be ignored, and the RFC text near that
>language, even contemplates potential reasons for this.

I think the rationale for, and the case against, compression has 
already been laid out in previous documents.  Compression isn't an 
AXFR issue though, it's a general message processing issue.  Lip 
service is all I would put towards it in the document.

>strict in what they send.

I don't believe that.  What's true for code isn't true for prose. 
The purpose of an RFC is to provide necessary and sufficient 
information to allow multiple interoperable implementations.  That 
doesn't mean liberal in what is accepted.  It means to be clear on 
what has to be done and what is probably a pretty good idea unless 
the situation is unusual.

>to the health of the Internet.

There are two ways to read "worst thing you can do is weaken a 
specification."  I am not for strengthening the AXFR mechanism in the 
sense of making it more efficient, feature rich, etc.  But I am for 
strengthening the definition so that it is clear what someone means 
by saying "please provide AXFR access to the zone data."

What I am sensitive to is that the word "clarifications" has become a 
lightening rod.  Clarifications to some mean just making the meaning 
of the base clearer. To some clarifications can include extensions 
that are assumed to have been in the original design.  And so some 
clarifications can include feature creep.  Once a word has become a 
lightening rid, I like to steer clear of it.

>Having case preserved specifically on XFR, is something much more important
>than any normal query/answer data.

I don't think that it is as simple as that.

I can paint a scenario in which an "ordinary" response's mashing of 
capitalization results in more stub resolvers getting "incorrectly" 
capitalized answers than the mashing done in an zone transfer.

E.g., a lookup from a large consumer-serving ISP for a high-traffic 
on-line retainer will cause a cache entry that will get jillions of 
hits before it times out.  There are some TLDs that won't get even a 
smidgen-of-a-jillion queries in the same time.

This is why I say it's not particular to AXFR.

And yes, I agree it is how you define and measure "importance."  In 
the architectural hierarchy, AXFR comes before QUERY/RESPONSE.  But 
in operations, QUERY/RESPONSE is always there, AXFR(and IXFR, NOTIFY) 
is not.

---

From: Brian Dickson <[email-masked]>
Date: Sun, 20 Jan 2008 14:39:06 -0500

Edward Lewis wrote:
> Specifically, what change?  Before expecting that a change is going to 
> be made because it is suggested, keep in mind "it had better be a 
The clarification being discussed in this thread. For example, language 
consistent with the following:

"To clarify the intent of 1034/1035, which says that once data is in the 
domain name system, its case should be preserved. AXFR and IXFR are 
transfers *within* the domain name system, server-to-server, and as 
such, SHOULD preserve case."
"This is contrasted with client-server (true client to caching resolver, 
or recursive resolver to server), where query and DNS data are compared 
in a case-insensitive manner, and the responses to queries may differ in 
case. Clients MUST handle answers which differ in case from queries."
> that it is the specification that is lacking.  Keep in mind my concern 
> is addressing RFPs and not writing a new implementation.
>
RFPs may be *your* concern, but the membership of the WG will vote your 
document up/down based on *their* concerns, if I understand how things work.

IMHO, I believe that any clarification to an existing set of RFCs should 
reflect the general purpose of the WG, which is to produce RFCs which 
can be used by implementers.
This MUST include new implementations, if the WG is "active", rather 
than "maintenance". And that is the case for this WG.
> lacking in the AXFR space.  That is why, to me, the current code base 
I believe that Mark Andrews has already expressed the need for 
addressing the need for case-sensitivity for AXFR, and that suggests an 
interoperability specifically on AXFR and IXFR.
It is not possible to make a clarification on AXFR without addressing 
the interoperability related to IXFR.
> they reflect reality.  I am not for raising the bar on functionality.
If language tightening improves interoperability, and nothing else, then 
I do not believe that adds functionality.
> service is all I would put towards it in the document.
I don't see how tightening language on *how* one should or should not do 
compression, changes the arguments about compression itself.

The real question is, when should case differences be expected, and when 
should they not?

A query of any type other than AXFR or IXFR, will include a domain name. 
The answer necessarily will return data which may differ only in case.
The originator (who made the query) MUST handle that case issue, because 
the information regarding case is not know prior to making the query.

However, for an IXFR, there is no data in the query, other than the 
parent zone.
It should not be the case that case gets changed on zone data, and the 
*cost* of doing the comparison scale by the size of the data set.

And most importantly, interoperability requires either that case is 
preserved, or that case mangling gets handled.
Not specifying the requirement on case, makes the choice of these two 
ambiguous - but they are mutually exclusive.
Regardless of which way it *gets* clarified, it *needs* to be clarified.

> This is why I say it's not particular to AXFR.
Correct - but the client MUST handle the case difference (on non-AXFR or 
-IXFR) between the query and answer. Existing RFCs make this clear.

So, there are two issues I see:
* whether is is important to *clarify* that either case preservation 
must be done, or alternatively, may *not* be done (explicitly)
* if so, which it is: that case preservation MUST be done; or that case 
preservation MAY NOT be done.

Brian Dickson

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Jan 2008 09:57:52 +1100

> lacking in the AXFR space.  That is why, to me, the current code base 

	Really?  Users do notice the bugs in the AXFR implementations.
	The problem is that all of the *mostly* work.  It's only
	in specific cirumstances where they don't work.  By don't
	work I mean what's entered at one end of a AXFR/IXFR graph
	gets out the other end of a AXFR/IXFR graph.

	If you just have a single hop and don't have parent / child
	zones on the same servers it basically works for all
	implementations.  Once you go beyond that you start to see
	the interactions occuring which shouldn't be occuring.

> service is all I would put towards it in the document.

	It the case for doing complession in a case sensitive manner
	vs a case insensitive manner.  Compress on its own is not
	bad it just has to be done correctly.

	Your comment above is a perfect example of why it needs to
	be in the document as you are missing the nuances of the
	issue.

> by saying "please provide AXFR access to the zone data."

	I don't think anyone has ask for more feature.  Just a tighting
	of the exisiting specification.
 
> smidgen-of-a-jillion queries in the same time.

	People care about what their host is called.  In a reverse
	lookup there is almost zero probability that you will find
	the hostname ends in ARPA.  When you are transfering a
	reverse zone there is almost 100% probability that compression
	will be used on the PTR records.

	This results in individual queries no compression, case preserved.
	Axfr compression used case insensitively, case potentially not
	preserved.
	Axfr compression used case sensitively, case preserved.
 
> This is why I say it's not particular to AXFR.

	No one says it is.  But we don't want to wait for the document
	that clarifies compression to come out.  Document it as a issue
	here and now.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Jan 2008 12:37:47 +1100

> writing code but does not place any requirements on the AXFR 

	We are in this mess because people didn't apply the general
	requirements of RFC 1034 to AXFR.

	* message id's matching is a general requirement.

	* setting flag bits correctly is a general requirement.

	* setting rcode correctly is a general requirement.

	* that the answer is in the answer section and not the additional
	  or authority sections is a general requirement.

	* not mixing zone content is a general requirement.

	* preserving case is a general requirement.

	* multiple records that compare equal are treated as a single
	  record.

	If we don't want to re-iterate general requirement then we
	are done.

	The only thing that is special about AXFR is that it is
	restricted to a reliable streaming protocol (e.g. TCP) and
	that because there wasn't a general mechanism for splitting
	answers over multiple DNS messages a query specific framing
	method was required to identify when the AXFR was complete
	(SOA at start and end).  Strictly speaking only the final
	SOA is needed.

	Mark

---

From: Wouter Wijngaards <[email-masked]>
Date: Mon, 21 Jan 2008 10:29:43 +0100

Hi,

As an implementor of AXFR nameservers, I think it's fine to completely
specify the AXFR (and or IXFR) protocol element.

I like the idea (from Mark) to clean up the header specification for
followup messages, and implementations can then conform to that on the
sending side. Things like ID bits, flags. On the reading side those are
still not trustworthy.

About case preservation. DNS compares names case insensitively. Case
gets lost due to compression. Clients have to ignore case in results. We
choose to completely remove case (downcase), for ease and simplicity of
implementation. Storing the case-preserved names would mean double the
memory use for the names. We have no case-preservation requests from
clients.

AXFR seems to work well. I never understood the TCP requirement, as an
EDNS packet could easily be large enough to contain the entire response,
especially all those small website-only zones. (if it is too small, you
set the TC bit). For reliability we have TSIG now. I think it is not
something that can be changed, or useful in particular, I just think it
is not orthogonal.

Apart from AXFR, IXFR, people use scp and rsync for zone transfer.

The IXFR spec contains a protocol element that allows you to attach to
the IXFR UDP message (some of) the data that changed, sort of like a
dynamic-update message but differently. My implementation ignores it;
only handles attached 'SOA' data and looks at the serial number. It is a
protocol element to examine carefully if you include IXFR in your document.

Best regards,
~   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Jan 2008 23:59:03 +1100

> something that can be changed, or useful in particular, I just think it

	When RFC 1034 was written many UDP implementations did not
	generate UDP checksums.  TCP checksums were not optional.
 
	Mark

---

From: [email-masked]
Date: Mon, 21 Jan 2008 15:42:59 +0000

> Apart from AXFR, IXFR, people use scp and rsync for zone transfer.

	and ftp, smtp, and rcp....

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Jan 2008 16:08:08 +0000

> 	generate UDP checksums.  TCP checksums were not optional.

so, edns should have added an end-to-end application layer checksum?  damn.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 21 Jan 2008 15:00:00 -0500

> specify the AXFR (and or IXFR) protocol element.
In case it wasn't clear from my earlier comments in the thread:
+1 from me, too.
> sending side. Things like ID bits, flags. On the reading side those are
Also +1.

I think this helps provide context to where the need is strongest.

The most important issue is what the sender (of an AXFR) does,
or more specifically, that this be very clearly specified.

What the receiver does with an AXFR or IXFR is less important,
*except* in the case where the receiver is also a sender.
> About case preservation.
[snip]
> We choose to completely remove case (downcase), for ease and simplicity of
> memory use for the names.

Correct me if I'm wrong, but the latest version of NSD only supports IXFR
as a receiver, not as a sender, correct? (For AXFR it supports both.)

As for storing case:
There are certainly implementation tricks that can reduce the impact of 
being able
to reconstitute case sensitivity for doing AXFR.

Those are generally space/time trade-offs: more computation needs to be 
done, but
less memory gets used.

For example:
Track the case *changes* that occur, using one bit per byte. Store the 
modified value,
and store a one-bit value in a bit vector indicating whether the case 
was changed.

This allows reasonably efficient storage and reasonably fast 
reconstitution of case.

E.g. : "AbcDefgH" -> "abcdefgh",  plus 0b10010001 (0x91) as an unsigned 
char.
Have a fixed 256-element array of 8-byte strings, representing the 
corresponding
byte values to "OR" in (or XOR, whatever your preference is), to avoid 
the binary
arithmetic on reconstitution. Do a string-wise OR (or XOR) between the 
value stored,
"abcdefgh", and the array element at subscript 0x91, 0x3000003000000030 
(I think!).

The only times the bit vector would be used would be at AXFR or IXFR 
time, sending
and receiving of either.

This is not performance impacting to the main lookup threads, answering 
normal queries.
The memory footprint cost is 1/8th, 12.5%, much better than double.

Thoughts?

Brian Dickson

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Jan 2008 11:18:37 +1100

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 

	When a slave is first configured it assumes the headers
	will remain sane after a initial check.  If it detects that
	the header values change between messages it rejects the
	transfer.  The slave operator the marks the master as broken
	and informs the masters operator.  Alternatively the slave
	operator could just refuse to accept transfers from that
	master.

	That master would then not be a candidate for anything that
	requires differentiation of answer streams.

	One thing we don't have is the ability to signal that a
	transfer is being aborted other than closing the connection.
 
	Mark

---

From: Danny Mayer <[email-masked]>
Date: Mon, 21 Jan 2008 21:28:34 -0500

> 	generate UDP checksums.  TCP checksums were not optional.

For that matter when RFC 1034 was written, EDNS did not exist either.

Danny

---

From: [email-masked]
Date: Tue, 22 Jan 2008 02:53:45 +0000

> For that matter when RFC 1034 was written, EDNS did not exist either.

	na... it existed, just not written down. :)

---

From: Dean Anderson <[email-masked]>
Date: Tue, 22 Jan 2008 00:10:44 -0500 (EST)

> stalled almost 5 years ago.

I agree that AXFR clarification is an important subject.

The old draft indeed gives clues as to the ambiguities, but its contents
are completely bogus.  The AXFR protocol should be clarified as widely
implemented, not as it was altered by the Bind companies in 2000-2002.

> document.  

Short version: 

No offense to Ed, but I'd be gravely concerned about having anyone from
UltraDNS/Neustar, ISC or Nominum involved in producing this document.
New author, please.

Long version:

There were many improprieties involving this document and the so-called
"Bind companies"  (ISC, UltraDNS, Nominum) and, Randy Bush, et al.
Neustar/UltraDNS was one of the so-called "bind companies" involving
Paul Vixie's and Rodney Joffe's joint combined business interests.  [I
only recently learned that Vixie and Joffe were partners in a commercial
bulk email operation since about (at least) 1999.  At this time, Vixie
was also be running the MAPS blacklist blocking commercial bulk emailers
competing with Whitehat.  While Vixie originally told the community that
MAPS was non-profit, this charade was abandoned in 2002 when MAPS
announced it was "for-profit".]

Indeed, I frequently cite the AXFR-clarify events of 2002 as an example
of an improper effort by ISC to influence the community with improper
activities. And just recently (this July, 2007) Paul Vixie said he
opposed the document in 2002:
http://lists.arin.net/pipermail/ppml/2007-July/007985.html

  "it wasn't my clarification.  i never supported the draft since RFC
   1034 was quite clear on the matter as far as i was concerned.  which
   is, i think, what IESG ruled during last call.  if some other RFC has
   amended 1034 to cause BIND's behaviour to be noncompliant, please
   point it out.  i can't and won't try to imagine what scheme you
   thought this was part of, or what success or failure of that scheme
   would have meant to you."

I've been meaning to put up a web page on the events of AXFR clarify. To
briefly recount the events for those newcomers:

In about 2000, a draft was submitted to the DNSEXT WG. The working group
was assured that there is no wire change in the document. The WG was
assured that this is just clarifying something that was vague in the
AXFR protocol. These assurances turned out to be false.

There were lots of process shenanigans to rush the document without a
proper review, including a new "SHORT last call", in 2001.  

This document has a lot of Bernstein's substantial objections:
http://ops.ietf.org/lists/namedroppers/namedroppers.2001/msg00549.html
It shows that there is a wire change to the protocol, and gives a
timeline of events to that point.

Then, in 2002, messages from Dr. Dan Bernstein mysteriously began
failing to get to the list. Randy Bush, then WG Chair, repeatedly
published Dr. Bernstein's unsubsription address to the mailing list, and
used an old version of majordomo that was susceptible to forged
unsubscriptions. Email messages from Bernstein to the list were
improperly delayed or even deleted as a "non-subscriber":

http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01977.html

 "P.S. Out of my twelve messages, the five that were silently discarded
  are exactly the five that I would pick if I were a censor trying to
  bias the DNSEXT decisions in favor of the BIND company. Coincidence,
  right?

  "P.P.S. Bush's mailing-list software doesn't cryptographically confirm
  unsubscription requests. I kept my subscription address private until
  Bush revealed it a few days ago. I'm working on obtaining a 
  subscription through an address that Bush doesn't know is connected to
  me.

[John Levine, a partipant in DNSEXT at that time, recently told people
that unconfirmed unsubscriptions have never been a problem. Levine
is/was also a Board Member of (investor in?) Joffe and Vixie's
Whitehat.com commercial bulk email operation. Levine is also chair of
the Anti Spam Research Group (ASRG). More on Levine at
http://www.av8.net/IETF-watch/People/JohnLevine/index.html]

Numerous other bad things followed, including a challenged consensus
call approving the document.  (Look for subjects with "fraudulent
consensus call" subjects in Namedroppers archives around 2003)

The scheme worked as follows:

1. Bind 9 has code to check for the "old" AXFR scheme, but recognizes
other "clarified" servers. When transferring to Bind 9 (and "clarify"
servers, it uses a different AXFR protocol, the one documented in AXFR
clarify. There is switch code in Bind to detect when to do this.  
[Presumably, there is/was similar code on Nominum and UltraDNS servers,
but I don't have access to their source code.]

2. So next, someone (Nominum) proposes a clarification to the AXFR
protocol definition, and misleads the WG to think that it has no effect
on the wire protocol, and no effect on other implementations.  Anyone
who checks Bind _operation_ (as NANOG did at the time), notices no
problem with AXFR interoperation.

3. Those who know what is coming next (the so-called "bind companies":
ISC, Nominum, UltraDNS) can each change their code to check for
"clarify"/"no clarify".

4. After the IESG approves the new clarified standard, the Bind
companies can then remove the code to check for old AXFR protocol. Once
that is done, AXFR breaks with other vendors DNS servers. Anyone who
checks the documents, says Bind complies with the clarification, and
other servers don't comply with the standard. Too bad for them.

5. The bind companies can now say those other vendors just weren't
reading the standards properly and weren't compatible with the AXFR
protocol. Which is technically true, but not quite honest.

6. And the so-called "bind companies" clean up the DNS nameservice
market.

The scheme was interrupted at step 4 by Dr. Bernstein and, to a small
extent, myself. Retaliation followed on me, too.

Proof of the scheme can found in the changes to Bind 9 code. If there
was no wire change necessary, then Bind 9 would not require a change.  
Conversely, changing Bind 9 proves that ISC, etc knew of the wire change
and deceived the WG.

At one point, Mark Andrews of ISC asserted that AXFR needed to be
changed for IXFR. However, this claim doesn't stand examination: No such
change is necessary for IXFR, and a modified AXFR wire protocol then
wouldn't be compliant with existing implementations of AXFR. If truly
necessary, a standards action would be needed to change the AXFR
protocol for IXFR, with all the incumbent difficulties and transition,
etc. Mark Andrew's claim also contradicts the assurance that no wire
change was present in the AXFR clarify draft. If no wire protocol change
is present in the document, it can't be the necessary justification.

So, I think we need to review this document with great care, and select 
the authors very carefully. 

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Jan 2008 05:32:48 +0000

this is a load of rubbish.  and, old rubbish at that.

---

From: Wouter Wijngaards <[email-masked]>
Date: Tue, 22 Jan 2008 09:23:53 +0100

Brian Dickson wrote:
| What the receiver does with an AXFR or IXFR is less important,
| *except* in the case where the receiver is also a sender.

Well the receiver has to be compatible with the old implementations.

| Correct me if I'm wrong, but the latest version of NSD only supports IXFR
| as a receiver, not as a sender, correct? (For AXFR it supports both.)

Yes. We could support the IXFR fallback case where the IXFR query gets
an AXFR response, and although this would give 'to the letter
conformance', it is not what you would want.

| As for storing case:
| The memory footprint cost is 1/8th, 12.5%, much better than double.
Smart idea.

Best regards,
~   Wouter

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 22 Jan 2008 13:37:55 +0100

> UltraDNS/Neustar, ISC or Nominum involved in producing this document.

[dropped the IESG, this seems to me a WG issue]

Dear Dean,

I am not very judgmental and if I were to judge people than that would  
be on their arguments, merits and mistakes, not by their affiliation.

I would hope that if we follow a structured method it would be clear  
that the document is the output of the working group and not any-one- 
particular person, organization, or company. The method I have in mind  
is the one where technical issues are raised, tracked, and decided  
upon, one-by-one by rough consensus in the working group. An issue  
tracker is used to make sure we are not re spinning issues. With that  
method the editor clearly serves the working group and although the  
pen-holder can steer by proposing the initial text, the WG decides.

I trust Ed with the pen since I've seen him serve the working group in  
an fair, competent and neutral way. Having said that, when following  
the above method I would actually trust everybody with the pen.

--Olaf
   namedropper

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Thu, 24 Jan 2008 10:20:45 -0500

>UltraDNS/Neustar, ISC or Nominum involved in producing this document.

Dean, please give Ed a chance to make mistakes before complaining about him :-)

Just because he happens to work with someone you do not like/trust is 
not sufficient grounds for removal of editing token.

DNSEXT chair's looked hard for a person to edit this document.
In the group of qualified candidates and ones that did not have known
"conflict of interest" there where only few people available.

Number of people I (and Olaf) approached, over the last year or so,
have declined to take on this task on because they did not want to deal
with the venomous e-mail that this topic has generated in the past.

Over the years Ed, has shown ability to navigate difficult corner
cases in DNS and produce documents of high quality, see RFC3070 and RFC4592.

If there are issues with -06 send them to the WG and/or editor and judge
the process based on results.

For the record as I have "conflict-of-interest" on this document, I will have
hands off approach to it, I have given Ed full control of the document.

When/if time comes for an WGLC I will ask for a WG member to volunteer to
serve as a "special master" to run the WGLC process.

         Olafur