| Hi James,
Thanks for the ping about this issue.
Transfers (specifically, those that involve changes to a DNS provider) are a complex issue, and are of a much bigger scope than what we can accomplish in 4310-bis. For a transfer involving glue (in which the IP address of the glue record would change), there is the issue of TTL on the glue record. Regardless of how well a registrant turns down the TTL for the RS and RRSIG records, it will still be subject to glue TTL, which, as I mentioned, is out of scope for us. Thus, the ability to set the TTL on DS and RRSIGs is not sufficient to ensure a smooth transfer.
There is also the ability for registrars (or registrants, through their registrar GUI) to misuse theTTL value. I would not want to see a TTL of 0, nor would I want to see $HUGE_VAL. In fact, short DS and RRSIG TTLs could cause an inordinate amount of queries to hit the parent name server, resulting in amplification attacks. This could, of course, be controlled by server policy, but that policy may hinder the ability of the registrant to turn down the TTL, which defeats the purpose.
Disclaimer: I have not gone back through the provreg archive to see the rationale for not providing TTLs in EPP proper, so I do not know if that reasoning extends to this issue, or if it was an oversight.
I'm interested in a counter argument to this, but for now, I am not in favor of adding TTL.
-Howard
On Feb 15, 2010, at 6:26 PM, James Gould wrote:
All,
I haven’t heard any feedback on the idea of adding a client specified ttl value and an optional server ttl returned in the info response used in a similar fashion as the maxSigLife element. The use case I see for this is allowing the client to determine what the ttl is for the DS RRset and the RRSIG resource record and for the client to have the option of decreasing the ttl in support of a DNS hosting transfer, which could be part of a sponsorship transfer. To enable the DNS hosting transfer of a DNSSEC enabled domain without going insecure by removing the DS records, the losing DNS hosting provider needs to be capable of accepting the gaining DNS hosting provider’s public keys and the gaining DNS hosting provider’s DS needs to be added to the parent zone. The switching of the name servers has to wait for the longest of the ttl’s (child and parent zone) to account for DNS caching, so having visibility of the ttl of the DNSSEC resource records of the server and to have the capability to adjust the ttl (down during the transfer) could help with the DNS hosting transfer process. If such a feature needs to be added to rfc4310bis, I need to receive feedback early this week to be included in the rfc4310bis 05 draft. I plan on publishing the rfc4310bis 05 draft on Wednesday that includes all of the feedback received so far.
Thanks,
--
JG
-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166
Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior written consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you.
From: James Gould <jgould@verisign.com>
Date: Fri, 12 Feb 2010 11:04:46 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review
Subject: Re: draft-gould-rfc4310bis-04.txt Submitted for Review
All,
I forgot about one item brought up by Klaus in a prior posting related to inclusion of ttl in rfc4310bis. What does the list feel about the need for adding support for an optional client specified ttl value and an optional server ttl returned in the info response used in a similar fashion as the maxSigLife, meaning directly under the secDNS:create, secDNS:infData, and under the secDNS:chg of the secDNS:update? From my perspective this might be useful in the handling of DNS hosting transfers, where the Registrant can request for a reduced ttl for the DS RRset and the RRSIG resource record when moving the DNSSEC enabled domain to another DNS hosting provider. The DNS hosting provider could obviously be another Registrar as part of a sponsorship transfer.
Any thoughts to this is greatly appreciated.
According to the AD the last call review period will be extended and should be on the IESG telechat agenda for March 4th, so I would like to incorporate as much feedback as possible to the 04 draft in a soon to follow 05 draft.
Thanks,
--
JG
-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166
Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior written consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you.
From: James Gould <jgould@verisign.com>
Date: Wed, 10 Feb 2010 23:07:31 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review
Subject: draft-gould-rfc4310bis-04.txt Submitted for Review
All,
I submitted 04 of the draft. The official draft is available at the URL below:
http://www.ietf.org/id/draft-gould-rfc4310bis-04.txt
There are many updates from 03 described in Appendix A based on the feedback on the list and privately. These changes are substantial, so please review it and provide me with your feedback as soon as possible.
I did not include anything in 04 related to Eduardo’s active flag request based on the variety of feedback on the provreg list that shows that it’s not ready for inclusion in rfc4310bis. I encourage that the discussions continue on the list for possible inclusion in a future draft.
Thanks,
--
JG
-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166
Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior written consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you.
|