Hi Petr, This has been discussed in the past a few times and died as people could not agree on what the format of the record was going to be, if it was going to be useful for human or computers etc.
The first idea was probably presented in 1987 by Robert Watson and myself https://tools.ietf.org/html/draft-watson-dns-error-00 Reading that draft over again the only thing I would change is to add a 16 bit field that was an index to a registry of error codes. I think something like this is needed and we have a much better handle of what kind of errors we are going to see. Olafur > On Feb 11, 2015, at 9:18 AM, Petr Spacek <pspa...@redhat.com> wrote: > > Hello dnsop, > > while implementing DNSSEC validation into Fedora/RHEL distributions we face > problems with debugging SERVFAILs seen by stub resolvers because different > causes of SERVFAILs are indistinguishable. > > Even in cases where we have access to server logs (e.g. because the validating > resolver runs on the same machine as the stub resolver) we have to grep > validator logs which makes the whole system validator-dependent, which is > undesirable. > > Wild idea: Could it be solved by adding more information to SERVFAIL answer? > > Is there a standard which forbids adding a meta-RRs to SERVFAIL answer? > > How likely will it break something? What about middleboxes? > > > I envision meta-RR with information like: > - signature will be valid in xxx seconds (validator's clock is in past) > - signature expired xxx seconds ago (validator's clock is in future) > - signature expected but was not received (perceived downgrade attack) > - locally generated SERVFAIL y/n > - unspecified (upstream server did not return detailed information) > - forwarder IP address/ID (when applicable) > etc. > > dnssec-roadblock-avoidance draft contains interesting list of problems which > could be reported in some way. > > My hope is to get enough information to distinguish cases where there is a > problem with validator (clock out of sync, wrong keys etc.) or upstream cache > used by validator (downgrade attack/missing EDNS suport) etc. to make > debugging easier. > > > Maybe this was discussed in the past and rejected, in that case please refer > me back to archives so I can understand the reasoning. > > Thank you for your time! _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
