On Fri, 9 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H wrote: > >> > 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?
This is exactly the cases I've described. (The third case is IMHO relevant in the case where you don't wish to maintain your own DNS server in the site; this could be the case e.g., if you happened to have a personal co-location box acting as DNS server for your forward domains located somewhere else as well, and you'd like to put the reverses there. Should one try to further clarify this? If so, I'm open to suggestions :-) (One thing that may be confusing that we're using the term "delegate" for both the prefix and the reverse tree..) -- 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
