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
