On Wed, 7 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H wrote:
> >>>>> On Wed, 7 Apr 2004 11:38:34 +0300 (EEST),
> >>>>> Pekka Savola <[EMAIL PROTECTED]> said:
>
> >> 2. Section 2.2 (Privacy (RFC3041) Address)
>
> (snip)
>
> > Good point. Revised as follows:
>
> > <t>Temporary addresses defined in <xref
> > target="RFC3041">RFC3041</xref> (sometimes called "privacy addresses")
> > use a random number as the interface identifier. Publishing DNS
> > records relating to such addresses would defeat the purpose of the
> > mechanism and is not recommended. If absolutely necessary, a mapping
> > could be made to some non-identifiable name, as described in <xref
> > target="RFC3041"/>.</t>
>
> Forks for me. I'd also remove "RFC3041" from the section title:
>
> 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.
> >> 4. Section 4.5 (Behaviour of Glue in Mixed IPv4/IPv6 Environments)
> >>
> >> (second paragraph)
>
> (snip)
>
> > Yes, the intent was "query name", as the additional length of the
> > packet for other reasons was also discussed a bit. Possibly this
> > would call for more text?
>
> > <t>Consider the cases where the query name is so long, the
> > number of he additional records (originated from "glue") is so high,
> > or for other easons that the response must either be runcated (leading
> > to a retry with TCP) or some of the additional data emoved from the
> > reply. [...]
>
> > I added "query name" there and "or for other reasons" -catchall, but
> > if you have better ideas what to add here, I'm all ears :)
>
> 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 ;-).
> >> 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.
However, the difference which is not explicit is that as the DDNS
packets cross the public Internet, there is probably higher need to
secure the DDNS updates coming to the server (as rather, when the
server is at the same site, you could just use IP address-based
"authentication" if you call it that).
I changed this to:
<t>Elsewhere; this implies a relationship betwen the
site and where DNS server is located, and such a relationship should
be rather straightforward to secure as well.</t>
How does this sound?
--
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
