On 2012-04-11, at 12:09, Wes Hardaker wrote: >>>>>> On Wed, 11 Apr 2012 06:28:49 -0700, Nicholas Weaver >>>>>> <nwea...@icsi.berkeley.edu> said: > > NW> a) If end-time is specified as a date, not an interval, you can set > NW> the date to be 'end of epoch', so you can basically have it 'stay > NW> forever', even if thats not advised > > That's why I suggested the upper limit, and the config would need to be > time based. IE: > > NTA example.com Thu Apr 12 09:06:42 PDT 2012
I realise this is just a thought experiment, but if there are dates to be specified in the presentation of new RRs then they should probably be in the same format as those used in RRSIGs. I would have liked to say RFC3339, but consistency with the rest of the DNSSEC spec (which unfortunately did not use 3339) is probably more important. I agree that negative trust anchors ideally need an expiration date. I confess I have not been following this thread very closely, and the discussion of resource records seems like something that has arisen outside the text being reviewed. I presume that someone has had the idea is to publish an NTA (or whatever) in a lookaside zone that a resolver could be configured to use, rather than in a parent zone (since a parent could just remove a DS RRSet). Such a lookaside zone could be provisioned using dynamic updates or static data or whatever suits the administrator. If negative trust anchors (or, more generally, signalling to instruct a validator to ignore a bad signature) is to be published in the DNS, then the NTA (or whatever) records SHOULD be signed such that a relying validator can trust the signalling. From the point of view of troubleshooting, it'd also be nice to have the option of encoding a reason (e.g. so that NTAs left in a zone beyond their expiry could be viewed by others for diagnostic purposes). And if there was an inception date also specified, that would surely also help. ; Hopcount's resolvers are configured to look for NTAs in the zone nta.hopcount.ca. $ORIGIN nta.hopcount.ca. ; example.com's DNSSEC is broken, let's not use it for a day example.com NTA 20120412162716 20120411162716 "ticket [HOPCOUNT-12345] jab...@hopcount.ca" example.com RRSIG ... I might also wonder whether such a record might usefully be returned in the additional section of a response that is a result of a signature being ignored. This would allow a stub resolver to tell that signatures are being deliberately ignored by the validator, without having to know explicitly what lookaside zone the validator is using. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45786 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.com. IN SOA ;; ANSWER SECTION: example.com. 3462 IN SOA dns1.icann.org. hostmaster.icann.org. 2011063333 7200 3600 1209600 3600 ;; ADDITIONAL SECTION: example.com.nta.hopcount.ca. 3462 IN NTA 20120412162716 20120411162716 "ticket [HOPCOUNT-12345] jab...@hopcount.ca" Joe
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
