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

[Pekka Savola <[e-mail]>]

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
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html