I don’t think there is a TTL issue because, as we proposed it, the record is
never returned in a query. The TTL could always be set to 0 for our purposes
since it never leaves the authoritative servers.
Tom
> On Aug 23, 2018, at 11:44 PM, Tom Pusateri <pusat...@bangj.com> wrote:
>
> Paul,
>
> Thanks for the feedback!
>
> An RRset isn’t granular enough because the components of the set could come
> from different clients with different timeout values.
> Therefore, a unique identifier is needed for each record. The hash provides
> that unique identifier since it is calculated over the entire record
> including the unique RDATA.
>
> The contents of the TIMEOUT RDATA field are not encrypted. The list of hashes
> are the list of unique identifiers. If each record had a unique identifier,
> we could use that instead but because they don’t, we create one with the hash.
>
> The AAAA._TIMEOUT.FSI.IO idea is a neat one that we hadn’t thought of but it
> isn’t unique to a record with a potentially different timeout value from a
> different client and only works if all the members of the RRset have the same
> timeout.
>
> We’ll take a look at your TTL concern and your previous draft.
>
> Thanks!
>
> Tom
>
>
>> On Aug 23, 2018, at 9:23 PM, Paul Vixie <p...@redbarn.org> wrote:
>>
>> tom, tim, thanks for this. i have two concerns, and three observations.
>>
>> concern #1 is about this text:
>>
>>> 3. TIMEOUT resource records are not automatically sent in AXFR, IXFR
>>> zone transfer requests. Both primary and secondary servers
>>> should be configured on a per zone basis to transfer TIMEOUT
>>> resource records to ensure they are supported.
>>
>> this is impractical given the high automation usually now involved in
>> primary/secondary AXFR and IXFR relationships. i suggest negotiating for
>> this with an OPT RR in the AXFR or IXFR request, indicating whether the
>> initiator ("secondary" in this document) supports TIMEOUT or not.
>>
>> concern #2:
>>
>> you don't appear to have addressed TTL overrun here. it's necessary for a
>> record which will expire to have a declining TTL as that expiry time nears.
>> if it's always been 3600, then when you're within one hour of expiry time,
>> returned TTL has to be reduced to whatever time remains.
>>
>> observation #1:
>>
>> none of the crypto seems nec'y. i would not quibble about it except that
>> since it is crypto it will have to morph over time to become stronger
>> against growing brute-force attacks and vuln research. this puts a
>> maintainance burden on the community every time we encode crypto into a
>> protocol. can you explain why the TIMEOUT RDATA isn't in clear text?
>>
>> observation #2:
>>
>> might you arrange for an _-related schema, so that each RRset having a
>> TIMEOUT can have those records as a niece/nephew domain? for WWW.FSI.IO
>> AAAA, the TIMEOUT would be at AAAA._TIMEOUT.FSI.IO, in this case.
>>
>> observation #3:
>>
>> this was all considered previously. most recently it was the subject of an
>> apple patent (EP1759516) by cheshire and sekar. first and foremost it was
>> proposed in the old DNSIND working group by myself, in 1996. you don't have
>> to worry about the patent, due to my prior art. since the draft is expired,
>> i've put a copy online here:
>>
>> http://family.redbarn.org/~vixie/defupd.txt
>>
>> the IETF DNSIND WG rejected this draft on the basis of its complexity. the
>> idea of a zone having timers inside it, for self-modification, was just a
>> bridge too far at that time. given what is now called "the camel" i think
>> pendulum has swung _well_ away from that point of view, but is now in the
>> process of swinging back. if i had hope, i would submit DEFUPD again,
>> exactly as it was in 1996, because it still deftly threads the needle posed
>> by UPDATE. your needs may differ.
>>
>> "good luck storming the castle, boys!" (_The Princess Bride_)
>>
>> vixie
>>
>> re:
>>
>> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-00.txt
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
