On Fri, Oct 30, 2020 at 10:03 AM Roy Arends <[email protected]> wrote: > Dear DNS Operations folk, > > Matt Larson and I wrote up a method that warns a domain owner of an issue > with their configuration. The idea is loosely based on DMARC (RFC7489), and > on Trust Anchor signalling (RFC8145). > > The method involves an EDNS0 exchange, containing an “agent” domain, send > by the authoritative server that the resolver can send reports to in case > of a failure. > > Please see https://tools.ietf.org/html/draft-arends-dns-error-reporting-00 >
I have a few comments (some were made in the jabber room at IETF-110), mostly suggestions. First, what about a "sampling" field, treated as 1/N for a field value of N. Do rand(N), and report only if you get a value of 0. A value of N=1 would always succeed (not sampled), and a value of N=0 is "don't send a report". Second, what about a "fire drill" field, which is applied with a similar 1/N logic, but triggers a report even if no error occurs. This would be useful for testing the reporting functionality without requiring deliberate errors be introduced. Third, what about actually sending a response to the "report" query? If noerror, nodata, the reporting agent does nothing. However, if some particular response is received, use that in processing future errors. The idea is to have some value returned, with a TTL used for how long to ignore errors, or that specific error. (Maybe use logic similar to the class and type fields from UPDATE?) That way, if the authoritative server has a problem that can't or won't be fixed for some duration, it can suppress reports until that error is fixed. Finally, what about an optional field for resolver operator contact info (e.g. vCard or similar), so the authority operator can follow up with a human if appropriate? BTW, I like this and hope it sees widespread adoption in the operator community. Brian
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
