>>>>> On Fri, 9 Apr 2004 08:32:12 +0300 (EEST),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
>> 2.2 Temporary Addresses
>>
>> but this is not a strong opinion.
> I'd rather keep it in, to make it clearer to not confuse them with
> non-RFC3041 addresses which just happen to be temporary, but as
> RFC3041 is to be revised in any case, I think this may be better off
> from the title, so I've removed it.
Okay.
>> >> 4. Section 4.5 (Behaviour of Glue in Mixed IPv4/IPv6 Environments)
>>
>> For me, adding "name" to "the query" is enough (in fact, I'm not sure
>> what "other reasons" are referring to). But again, it's not a strong
>> opinion and is up to you.
> Kept as is; "other reasons" may be due to e.g., the number of DNS
> record for the name that would have to be returned (in the
> *authorative* section) to be too large or inclusion of DNSSEC records
> for which either query name or additional records may not be
> appropriate. (However, as I don't know the details, I'm just being
> vague ;-).
Okay.
>> >> 6. Section 7.5 (DDNS with Dynamic Prefix Delegation)
>>
>> (snip)
>>
>> > The wording "at the site where the prefixes are delegated" seems to be
>> > unclear. I've reworded it to "at the site where the prefixes are
>> > delegated to" to make it clearer. I've also tried to clarify the
>> > parentheses by spelling it out:
>>
>> > 7.5 DDNS with Dynamic Prefix Delegation
>>
>> > In cases where a prefix, instead of an address, is being used and
>> > updated, one should consider what is the location of the server where
>> > DDNS updates are made. That is, where the DNS server is located:
>>
>> > 1. At the same organization as the prefix delegator.
>>
>> > 2. At the site where the prefixes are delegated to.
>>
>> > 3. Elsewhere, as specified by the delegated site; this is
>> > security-wise typically equivalent to the previous case.
>>
>> > On one hand, securing the DDNS relationship for prefix delegation is
>> > simpler if DNS server and the prefix delegator are in the same
>> > administrative domain, and may be more difficult otherwise.
>>
>> > On the other hand, if the DNS server resides where the prefixes are
>> > delegated to, it is easier to manage reverse DNS updates as they can
>> > be done within a single administrative entity. Similarly, then
>> > configuring the reverse DNS is typically simpler as well (e.g., if
>> > one wanted to insert a wildcard record).
>>
>> The revised text basically looks okay except for one point: I'm not
>> sure about the rationale of the latter part of case 3: "this is
>> security-wise typically equivalent to the previous case."
> OK, let me try to clarify. If you delegate the DNS delegation for a
> prefix to someone else, that someone else must configure the DNS
> server to accept such a delegation. Because they don't just take
> delegations from strangers, we must assume that there is some form of
> relationship between the two. Such relationship should be easily
> extendable to be a security relationship as well.
Hmm...I'm now feeling that I've been confused from the beginning. So
before going further, please let me make the scenario.
Let's assume a site is delegated an IPv6 prefix P:x::/48. Also assume
the prefix delegator has the authority of the DNS reverse tree for
P::/32. Then,
In the above case 1, the prefix delegator does not delegate P:x::/48
in terms of DNS reverse tree. Someone in the delegated site might
want to update RRs in the P:x::/48 part of the P::/32 zone at the
delegator.
In the above case 2, the prefix delegator does delegate P:x::/48 to
the (prefix) delegated site in terms of DNS reverse tree, too.
Someone in the delegated site might want to update RRs in the P:x::/48
zone managed in the same site.
In the above case 3, the prefix delegator does delegate P:x::/48 in
terms of DNS revers tree to some different organization which is not
the delegator or the delegated site. Someone in the delegated site
might want to update RRs in the P:x::/48 zone managed in the different
organization.
Is my understanding correct?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
