Something I wonder about, certainly after the interim, is how do we discuess with the wider DNS community the trade-offs that are available in de design of DELEG such that we get good feedback about priorities.
For example, the current design used two contraints: 1) no creative (ab)use of DS records 2) no extra queries. The net effect in the current design is that current auth. servers cannot serve DELEG because they don't know that have to include DELEG records in referrals. So a zone can only start delegating using DELEG if all its auth. servers (and any other part that might answer queries) has been upgraded. In a similar way, a validating resolver that lives behind other resolvers or forwarders cannot support DELEG until all upstream resolvers support DELEG (the same issue, DELEG records have to be treatet special because they don't live in the child zone). For validators on roaming devices such as laptops it can take essentially forever until all upstream resolvers support DELEG. Alternatives are: 1) just put it in DS. Certainly if we expect that alias mode will be most common. 2) Store DELEG somewhere else. For example for child.parant store the DELEG record in child._child.parent. This may require an extra query, that may or may not be optimized in some way. Note I'm not saying that the current design is wrong. It is certainly the most elegant way of doing things from a protocol perspective. But one question is how do we deploy DELEG. And then some of the alternatives might become more attractive. So at this stage, when we talk about DELEG, we should talk about alternatives as well and collect feedback on what operators consider more important. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
