Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side
Hello, (re-sending to list) I would like to find a solution which covers other possible failure modes than SERVFAIL, too. Looking at BIND 9.9, it sometimes can return NXDOMAIN or even NOERROR when validation fails for some obscure reasons. E.g. an attempt to invent private TLD like 'mycompany' without proper trust anchor configuration / negative trust anchor can yield NXDOMAIN answer and one line in log, but not a SERVFAIL. Similarly, an attempt to 'shadow'/'hijack' an existing domain which has DS records in the parent might result in returning NOERROR with data from the real parent while ignoring 'spoofed' data. I agree that this behavior makes sense from security stand point but it would be tremendously handy to get information that something like that happened. Maybe https://tools.ietf.org/html/draft-hunt-dns-server-diagnostics-00#section-2.2 could be relaxed to allow the server to send ESD option even in non-SERVFAIL responses? Maybe there will be other use-cases for ESD option too. E.g. GSS-TSIG errors could be accompanied with detailed error codes and/or human-readable error messages from GSS libraries and so on. GSS-TSIG is sometimes quite hard to debug so this extension could be a tremendous help! (Yes, all this may require some configurable policy to specify clients who can use ESD option.) I will be in Prague so I'm more than happy to discuss it there if there is enough interest. -- Petr Spacek @ Red Hat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side
On 3.6.2015 17:00, Evan Hunt wrote: > On Wed, Jun 03, 2015 at 08:40:16AM +0200, Petr Spacek wrote: >> Could this be added to agenda for IETF 93? Does it make sense to discuss >> it there? > > Unfortunately I won't be in Prague, but I do expect to be in Yokohama. > If you or someone else would like to push the idea forward in my absence, > that's fine. Today I spent half a day writing diagnostics for weird corner cases so I'm very interested in the idea :-) Hopefully I should be in Prague - please let me know if I can do something to push the discussion forward. > There were a couple of review comments that I'll need to dig out and > address if the draft is coming back to life. I'm willing to help if you need to borrow a pair of hands. -- Petr Spacek @ Red Hat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side
On Wed, Jun 03, 2015 at 08:40:16AM +0200, Petr Spacek wrote: > Could this be added to agenda for IETF 93? Does it make sense to discuss > it there? Unfortunately I won't be in Prague, but I do expect to be in Yokohama. If you or someone else would like to push the idea forward in my absence, that's fine. There were a couple of review comments that I'll need to dig out and address if the draft is coming back to life. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side
On 11.2.2015 17:08, Evan Hunt wrote: > On Wed, Feb 11, 2015 at 03:44:31PM +0100, Pier Carlo Chiodi wrote: >>> Wild idea: Could it be solved by adding more information to SERVFAIL >>> answer? >> >> a draft was proposed with this very topic, but it's expired now: >> >> https://datatracker.ietf.org/doc/draft-hunt-dns-server-diagnostics/ > > I'd be happy to revive it, especially now that it's explicitly within > dnsop's remit. I don't recall anyone objecting to the idea; it just > wasn't high-urgency and I had other business to attend to. Could this be added to agenda for IETF 93? Does it make sense to discuss it there? -- Petr Spacek @ Red Hat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side
On Wed, Feb 11, 2015 at 05:36:22PM +0100, Petr Spacek wrote: > In other words, I do not think we can prevent people from doing crazy things > just by obscuring format of diagnostics data. I'm sure somebody will try to > parse free-form string 'signature expired 1 week ago' and do some decisions > from that :-) I wasn't thinking of obscuring anything, just mentioning my one major concern about including diagnostics with SERVFAIL responses: I fear it will be a tempting target for someone to attempt misguided cleverness. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side
On 11.2.2015 17:08, Evan Hunt wrote: > On Wed, Feb 11, 2015 at 03:44:31PM +0100, Pier Carlo Chiodi wrote: >>> Wild idea: Could it be solved by adding more information to SERVFAIL >>> answer? >> >> a draft was proposed with this very topic, but it's expired now: >> >> https://datatracker.ietf.org/doc/draft-hunt-dns-server-diagnostics/ > > I'd be happy to revive it, especially now that it's explicitly within > dnsop's remit. I don't recall anyone objecting to the idea; it just > wasn't high-urgency and I had other business to attend to. > > It's important that diagnostic signaling only be used for human > troubleshooting purposes and not as input to a policy decision, such > as "ignore DNSSEC failures due to expired signatures" or something, > because the diagnostic messages would be trivial to spoof. I generally agree but the data format itself should be easy to parse: My main goal is to make diagnostics as automatic as possible. (Yes, it will be very interesting when we start considering active attacks.) In other words, I do not think we can prevent people from doing crazy things just by obscuring format of diagnostics data. I'm sure somebody will try to parse free-form string 'signature expired 1 week ago' and do some decisions from that :-) -- Petr Spacek @ Red Hat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side
On Wed, Feb 11, 2015 at 03:44:31PM +0100, Pier Carlo Chiodi wrote: > >Wild idea: Could it be solved by adding more information to SERVFAIL > >answer? > > a draft was proposed with this very topic, but it's expired now: > > https://datatracker.ietf.org/doc/draft-hunt-dns-server-diagnostics/ I'd be happy to revive it, especially now that it's explicitly within dnsop's remit. I don't recall anyone objecting to the idea; it just wasn't high-urgency and I had other business to attend to. It's important that diagnostic signaling only be used for human troubleshooting purposes and not as input to a policy decision, such as "ignore DNSSEC failures due to expired signatures" or something, because the diagnostic messages would be trivial to spoof. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side
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 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
Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side
Hello, On 2015-02-11 15:18, Petr Spacek wrote: 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. ... Wild idea: Could it be solved by adding more information to SERVFAIL answer? ... Maybe this was discussed in the past and rejected, in that case please refer me back to archives so I can understand the reasoning. a draft was proposed with this very topic, but it's expired now: https://datatracker.ietf.org/doc/draft-hunt-dns-server-diagnostics/ Regards, -- Pier Carlo Chiodi http://pierky.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Debugging DNSSEC SERVFAILs on resolver side
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! -- Petr Spacek @ Red Hat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
