Extended DNS Errors a la RFC8914 #504
Conversation
This reverts commit b3f60db.
when refusing to answer authoritatively. Also remove TODO comments that were already done
…fluous todo comments
…nto features/rfc8914-ede
…nto features/rfc8914-ede
daemon/worker.c
Outdated
|
|
||
| // // stale answer? | ||
| // if (worker->env.cfg->serve_expired && | ||
| // *worker->env.now >= ((struct reply_info*)e->data)->ttl) { | ||
| // // EDE Error Code 3 - Stale Answer | ||
| // EDNS_OPT_LIST_APPEND_EDE(&edns.opt_list_out, worker->scratchpad, | ||
| // LDNS_EDE_STALE_ANSWER, ""); | ||
| // } | ||
|
|
There was a problem hiding this comment.
I thought I add commented about this earlier, but I don't seem to find that message again.
Is there any plan to have stale answers EDE handled from the get go of the RFC support?
|
Not sure if I forgot to submit my previous comment a couple of weeks ago, or if it got overridden as the diff took shape. TL;DR I am looking forward this making in into the main branch and was wondering if EDE stale answer (code 3) was going to be supported from the get go as the current diff has it commented out. |
|
Hi @chantra, please don't let the commented-out code dishearten you, this is very much WIP 😄 |
…nd default EDE code for a zone
…d manpage entry for local-zone-do-ede, local-zone-default-ede, and ede-local-zones
…re specific EDE codes
…nd fix typo in the unbound.conf
…d EDE option text
TCY16
force-pushed
the
features/rfc8914-ede
branch
from
8941175
to
9ae988c
Compare
Still TODO:
log-val-level:config options influences the returned EDE option textFor future iterations, we would like to have cached EDEs and add DNSSEC indeterminate with a configuration option,