Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Paul Vixie <[e-mail]>]

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