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

Re: WGLC for draft-huston-6to4-reverse-dns-04.txt

Hi,
I'm adding v6ops to Cc: because it'd be useful to get some input on from the 6to4 operational experience here to gauge whether the mechanism addresses sufficiently large subset of the problem.
Based on your note, which I agree with, I guess the questions we should be asking are: 

 1) "who are the target users of this spec?"
    1.b)  "is the mechanism good enough for _them_?"

 2) "is there a sufficiently important subset of 6to4 users for which
    this is not an appropriate solution?"
    2.b) "do we need to have a solution for them?"

My answers to these would be,
 1) 6to4 power users with static IPv4 address
  1.b) yes
 2) "regular" 6to4 users and/or 6to4 users w/ dynamic IPv4 address
  2.b) unknown at the moment.  Not sure if a scalable one could exist
       (and anyone would have enough steam to create one)

Inline..

On Fri, 10 Mar 2006, Mark Andrews wrote:

	While I am happy enough for draft-huston-6to4-reverse-dns-04.txt
	to proceed it should be pointed out that this is a suboptimal
	solution to the problem.

	1. It requires rapid establishment of a the child zone on
	multiple servers.  There currently is no standardised method
	for doing this.
Yes, it's not clear whether this is considered a bug or feature: the mechanism is basically unusable (requiring a lot manual config) in all the sane authoritative server DNS configurations if you have a dynamic IP address (even if the dynamic IP address changed only infrequently) due to the manual overhead.
But this may also discourage folks w/ dynamic IPs from participating, which might lessen the scalability concerns. 


	2. It does not use DNS itself as the update mechanism.

	A all DNS solution would be to use a DNAME record rather
	an NS RRSet to perform the delegation funtion in the method
	described in RFC 2874.  This remove the need for rapid
	establishment of the child zone as it will already exist
	and be populated.

....

	This method was presented to the author several years ago
	but was not listed in the alterative rejected.  It would
	be interesting to know why it was not listed as a alternative
	and as to why it was rejected.
I agree this could possibly be mentioned; the cause it has been omitted may be that that it wasn't listed in the original draft discussing the alternatives; did you send comment to Keith Moore while he still updated the document? 

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings