Hi Ralf, We're a little unclear what you mean. My comments are inline with [WC]. Thanks, Bill
On 11/28/24, 10:26 AM, "Ralf Weber via Datatracker" <nore...@ietf.org <mailto:nore...@ietf.org>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Reviewer: Ralf Weber Review result: Almost Ready Moin! I am an assigned DNS Directorate reviewer for draft-ietf-regext-epp-delete-bcp. For more information about the DNS Directorate, please see https://secure-web.cisco.com/145O12g_MUjOFsIfglmUSZqcFXAban83hPl1f3-zt8JDBVsNrm6wR_U_GTttJM2GSbGADNlF0aMVXH79qOOI5ETzVO8B5OQ9cjh0lnwS1btEgn7Z1v52u4kc-SqI-XgV3cbPFz9gh7l9SACo986VgEEzknrm6NEXnJOZaFfOyp_QPopAmwfQuwTZcqfIyLsoCt1Vb789I4MxB49yNnjrBjfvRFxzv2830kQAlb9ZGij-YL5uOVhQLPNgbwwgsKUWBLcGm5ieqkc_zx0Jd0iS1iniYqfSF8iGCKMHuo59wOTE/https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Fdnsdir <https://secure-web.cisco.com/145O12g_MUjOFsIfglmUSZqcFXAban83hPl1f3-zt8JDBVsNrm6wR_U_GTttJM2GSbGADNlF0aMVXH79qOOI5ETzVO8B5OQ9cjh0lnwS1btEgn7Z1v52u4kc-SqI-XgV3cbPFz9gh7l9SACo986VgEEzknrm6NEXnJOZaFfOyp_QPopAmwfQuwTZcqfIyLsoCt1Vb789I4MxB49yNnjrBjfvRFxzv2830kQAlb9ZGij-YL5uOVhQLPNgbwwgsKUWBLcGm5ieqkc_zx0Jd0iS1iniYqfSF8iGCKMHuo59wOTE/https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Fdnsdir> Overall the draft does a great job explaining the problem space of host object deletion in EPP and uses a great structure for that. From a DNS perspective however I think there are some things that could be improved. First I think we need a more precise definition of what renaming means for the DNS referral answer. If e.g the name and not the IP that has different impact on DNS resolution than if a there is a name that is not resolvable or a renaming and giving an IP that actually responds. This should IMHO be added to the cases in section 5. I am not even sure on what the results are for all the cases, but would offer to help with text/examples on that once that is clear for all the cases. [WC] Can you clarify the question? I'm not sure how the IPs are relevant. When an object (e.g., ns1.to-be-deleted.com) is renamed, requests for the previous name should receive a non-existent response as the previous name is no longer in the zone. Do we need to specify that if ns1.to-be-deleted.com is renamed to ns1.sacrificial-ns.org, then here are no assurances that ns1.sacrificial-ns.org will resolve, offer DNS service, or respond to queries for to-be-deleted.com with a positive or negative response (see RFC 2308 and RFC 9520)? It seems like we are not introducing any new behavior there, but maybe I'm misunderstanding the question. Second on section 5.1.3.4 the text on if I should run an resolver or an authoritative answer for the sacrifical name server host and what the answer actually is. Now there might have been discussions about that that I am not aware of and there may be a reason for the text, but if so it should be noted. My rather simple view on this if I had to run such a server I would answer REFUSED to all the queries I got. [WC] We deliberately left it somewhat open to the operator: "The sacrificial name server should run a DNS resolution service capable of responding with an authoritative non-error, non-failure response for requests made for associated domains. The service SHOULD provide responses that indicate problems with a domain's delegation, such as non-existence or include controlled interruption IP addresses." REFUSED could be problematic (at least until all recursives are RFC 9520 compliant-see RFC 9520 §2.2). Not related to this draft, but I am happy that the so far proposed DELEG solutions will solve the problem as there no longer is a need for a host object, but as we are not there yet this document is badly needed, so please keep up the good work and if there is anything I can help please reach out. So long -Ralf _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
