At 12:24 -0500 12/22/04, David Blacka wrote:

On one hand, the DS is the parent's data, and thus is allowed to set the TTL
to whatever it wants.

On the other hand, the child has a vested interest in the length of the TTL
because it factors into the time-to-recover from a SEP key compromise.

One one hand, the DNSSEC documents say this (protocol-09, section 2.4):

   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
   (that is, the NS RRset from the same zone containing the DS RRset).

On the other hand, I'm not sure that this advice makes much sense.

Your fourth hand's comment is quite interesting. The delegating NS RRset would be replaced in the cache by the delegated NS RRset per the credibility rules of RFC 2181 in a "normal" case today.


I (would) have to look to see where in the DNS protocol *documents* it is stated that a server MUST/SHOULD/MAY put the authoritative server set in the authority section. Given that one implementation has this as a configurable option, I assume that the inclusion is not mandated in definition. In which case, the recommendation the third hand points to would make sense.

I think we could spend many cycles trying to figure out that the Good RFCs mean in this case. (We've done so before on many topics.) Given that this is an M&O Area group, I'd like to get to what makes operational sense, even with the points your first two hands illustrate.

I'd propose this addition to the -epp-secdns-:

The addition of TTL as a mandatory to implement facet of a DS record element, optionally filled in. In the security extensions section urge adopters of this extension to seriously consider setting up business rules limiting the range of TTL values accepted to counter potential "subscriber fraud" situations.

This is a *sketchy* proposal...comments are desired.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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

Reply via email to