It has been long known that TTL's of delegation points sometimes don't work out as planned. By this I refer to the fact that if an iterative resolver seeks the address of www.example.net with nothing in the cache, it will first receive a referral from "." to "net." with the "."'s version of the "net." NS set. Asking a "net." server will give you a referral to "example.net." personified by the "example.net." NS set in the authority.
What's missing here is the iterative server's ever receiving the authoritative NS set for "net." Even though the copy of the "net." NS set is more credible (RFC 2181) when obtained from the child than when obtained from the parent, if the iterating server never sees the child's, the parent copy (and the parent TTL) is what is used.
Fortunately when the query cited above proceeds, the answer will likely have the AAAA record in the answer section and the "example.net." NS set in the authority section. In this case, the latter copy is more credible than the "hint" given by the "net." servers and will usurp the position in the cache. (Unless the "example.net." name server uses minimal responses - meaning that only the answer section is filled in. This option is implementation specific, for those that keep track of such things.)
This preamble is meant to lay a context of why a few of us sat to talk about the importance (or not) of including a TTL parameter in an EPP command to add or modify a DS record. (Looking at it, maybe it's not an important context, but it's what floats in the back of our minds - some of us anyway.)
Keep in mind that, unlike the NS set the preamble worried about, the DS set is authoritative in the parent zone and is not even in the child zone. This makes the parent's setting of the TTL more interesting. Or not.
So, here goes. The question is "should a DS request in EPP also allow the child to dictate to (or just ask) the parent the TTL?"
There are pro's, con's, and other considerations.
The "pro" is that the shorter a TTL is, the quicker a child can change the SEP key. A smooth transition ought to be wary of the persistence of DNS data, like images on a phosphorus CRT, which limits DNS's ability to turn on a, um, coin.
The "con" is that the TTL is a design consideration when setting up a DNS constellation. The shorter a TTL is, the stronger the authoritative service must be. A short TTL means caching will be bypassed more often.
If the EPP client (ultimately equivalent to the child zone operator) wants to really mess with the the EPP server organization's DNS constellation, a TTL of 1 second is set. This will cause a lot more traffic to hit the parent than if the TTL was for 48 hours given the same work load.
There's the issue of whether this matters at all. A DS set with a high TTL does not mean that an abuser of the DNSKEYs can extend the length of an attack. The child zone can always have a short validity period on the RRSIG covering the DNSKEY set, limiting the usefulness of the overly long TTL'd DS. The risk to the child of high TTL'd DS sets is, in reality - err - theory as we haven't set this up, a longer "mean time to recovery" because of the persistence (a la phosphorus) issue.
So, would it be beneficial for EPP to include the TTL? (I doubt that I've sufficiently covered the issue - I'm leaving the opportunity for others to chime in with points, kind of as a "gift of the season.")
As far as the apparent risk that a child can select an abusively low TTL, the parent can have a "business rule" setting the lower limit of the TTL to a certain number. Encoding a business rule per se would be a bad, bad thing in the protocol definition. But recommending that a registry adopt such a business rule ought to be in the security considerations section.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"A noble spirit embiggens the smallest man." - Jebediah Springfield . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
