Subject: Re: draft-ietf-dnsext-axfr-clarify-06

From: Edward Lewis <[email-masked]>
Date: Tue, 5 Feb 2008 15:48:11 -0500

Just a few notes...

At 13:02 +0100 1/24/08, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
>(3)  Section 2
>
>(3a)  3rd paragraph
>
>I suggest to make the style of quotations to other RFCs consistent
>within the document and with common use:

I made wholesale changes to that section, placing the titles of the
RFCs in the text.  Partly because I want to emphasize the meanings
behind the RFC numbers.
>
>Finally, I suggest moving the second pararaph (with message length
>considerations) behind this paragraph or to the end of the section,
>because it contains more specific information.

It's funny to read this because, after making all the changes above, 
I thought to myself that I needed to do this.  Then I read the 
suggestion.  Good timing.

>(9)  Section 3.2
>
>(9a)  1st paragraph
>
>    In RFC 1034, section 4.2.1, this text appears (keep in mind that the
>    word "should" in the quotation is now deemed to be a "SHOULD" subject
>    to the interpretation in section 1.1):
>       "The RRs that describe cuts ... should be exactly the same as the
>        corresponding RRs in the top node of the subzone."
>    There has been some controversy over this statement and the impact on
>    which NS resource records are included in a zone transfer.  Also,
>    DNSSEC [RFC4033] [RFC4034] [RFC4035] specifies particular Resource
>    Records to be inserted at delegation points in secure zones, and at
>    the apex of secure zones, respectively, which makes the above
>    statement inappropriate.

In this case I think your edits are reading too much into the 
situation.  The "RRs that describe the cuts" refers to the NS and 
glue only, generally, and I'll change text to make that explicit. 
Even before DNSSEC there are deviations between the cut point and the 
apex, e.g., the SOA record, possible MX, and in the older days, RP 
and other records.

The point was to hit at the issue of whether, given a server that has 
both parent and child, or can get the child, should insert the 
child's NS set if there is a difference from the parent's.  As far as 
I could figure, that was the root of the hottest debate on this 5 
years ago.  DJB wanted to "optimize" the safety of the network by 
automatically correcting any inconsistency and I understand his 
motivation.  OTOH, good protocol engineering tells me otherwise, that 
making the error explicit is better for maintenance, troubleshooting, 
etc.  It's a tug of war between theory and practice.

So, I don't want to drag DNSSEC in, but I'll have to explain better 
that this is the issue about differing NS sets.

Let me know if that isn't satisfactory.

>(11b)
>More importantly, I am in serious doubt whether the capability added
>by the final sentence is worth the protocol complications it requires.
>
>To my knowledge (admittedly a bit aged), typical AXFR client
>implementations anyway perform the AXFR and local database update
>in a dedicated process or thread that does not also perform other
>DNS queries.  Therefore, a dedicated TCP connection will be used
>for one or more AXFRs.

That was my general understanding too.  But Mark Andrews has been 
pounding down on me that the open TCP connection is to be used for 
anything.  I don't know why he's so adamant about it but he makes is 
sound like a matter of life and/or death.

I think he's just trying to find more fault with the practice of 
dropping TCP connections as a defense against unwanted AXFR queries. 
That's been attributed to DJB but come to think of it, I don't know 
if even his code does that.  I do know he won't answer when it's a 
lame situation, but that's over UDP.

>Serial reuse of a TCP connection for multiple AXFRs (AXFR chaining
>on a connection) or even using a (semi-)persistent TCP connection
>for other queries/responses in a serialized manner therefore might
>be a reasonable feature that can be supported without protocol
>complications and/or serious backwards compatibility issues.
>
>On the other hand, interleaving multi-message AXFR responses with
>other DNS query/response traffic seems to be unnecessary and
>unnecessarily complicated.  Keep in mind that query/response
>traffic over UDP can be sustained in parallel without a need
>for this extension.  Also, paragraph 2 of Section 5 indicates
>that regularly, the set of AXFR clients allowed will be restricted
>very much, and other queries between sibling authoritative servers
>needing TCP are considered less likely.
>
>That said, my subsequent change proposals nevertheless will carry
>on support for this protocol extension.

I agree with you.  Given a subsequent discussion (which I launched 
after you sent this but before I read this, i.e., I sat on this a 
while), I'm going to move the UDP to a separate document.

>(12)  Section 4.1

I've pretty much completely overhauled the transport text based on 
discussions, so most of your comments will be used when I prepare the 
AXFR over UDP document.

>(15)   Section 5
>
>(15a)  1st paragraph
>
>Please do not omit the most stringent and important restriction
>to be observed today: LAW !

I'm a little iffy on that because I'm not a lawyer and am not sure 
what a "legal requirement is."  But I added the change and see if 
anyone complains.

>(15b)  last paragraph
>
>I simply do not understand the sense and purpose of the last sentence:
>
>  An implementation SHOULD allow access to be open to all requests.
>
>Please supply more specific text, or drop this sentence.

It means that an implementation should give the the operator the 
option to say that anyone can request an AXFR.  Like "allow-transfer 
{ all; };"

>(17)  Section 12

>- Please use <ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt>
>   (or any mirrored or derived file) as the base for content, style,
>   and punctuation in entries of the References section.

That's what I did...I used the rfc-index file I guess.  That's what 
there are those insane "."'s all over the place. I'll take a look at 
that in the next
spin.  (I wanted to have another version out now before my other work hits.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Mail archives, backups.  Sometimes I think the true beneficiaries of
standards work are the suppliers of disk drives.

--
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: Wed, 06 Feb 2008 09:01:41 +1100

> etc.  It's a tug of war between theory and practice.

	It didn't make the network "safer".  It didn't "optimise"
	anything. It just makes everything worse as the nameservers
	were no longer doing what they were explicitly told to do.

	There is a difference between AXFR and NS queries.  The
	latter alway comes from the child zone and is what is
	required by RFC 1034 when you select the zone to answer the
	query from.

	AXFR preserves what it loaded / transfered in and returns
	this.  This includes records that are not below the zone
	apex.  If you don't do that you end up with records that
	exist only in slaves and in neither of the masters.

	Having to regularly recover from the effects of merging
	zone content (which both BIND 4 and BIND 8 did) I know what
	the correct answer is (and it isn't merge).

	S1			S2		S3
				PARENT	->	PARENT
	CHILD 	->		CHILD

	S3 would regularly end up with the wrong NS RRset or glue
	A records especially when the email informing the admins
	of S2 of the change arrived before the zone transfer happened.
	S2 was often a stealth slave so it's transfer was only
	controled by the SOA timers.

	I would regularly have to contact the S2's administators
	and get them to bump the SOA record for PARENT so that
	another AXFR would be triggered and so all the S3's would
	re-transfer.

	Note there were about 80 different S1's all run by different
	administators.

	BIND 8 atleast merged the content in a deterministic manner.
	BIND 4 merge depended on load order and could return different
	answer before and after reload.

	I've been there, done that and don't want to go back to chaos.

-- 
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: Tue, 5 Feb 2008 17:12:12 -0500

>	were no longer doing what they were explicitly told to do.

And I know *that* is your opinion.  What I wrote is my understanding 
of DJB's opinion.

>	I've been there, done that and don't want to go back to chaos.

Then let it go.  There's no need to repeat your view every time you 
hear a viewpoint that you do not agree with.

Wait and read what's in the -07, I just submitted it.  Make comments 
on the current document and not on history.

Let's be polite and civil.  Let others have their say.  The process 
of putting into words the definitions we all assume is hard enough 
without having to fear that someone is going to get angry or raise 
emotions over the work.  There are many rounds of review to go, many 
viewpoints to listen to.