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
