BIND 10 #2226: direct queries for RRSIG
BIND 10 Development
do-not-reply at isc.org
Thu Aug 30 10:17:34 UTC 2012
#2226: direct queries for RRSIG
-------------------------------------+-------------------------------------
Reporter: jelte | Owner:
Type: defect | Status: new
Priority: medium | Milestone: New
Component: Unclassified | Tasks
Sensitive: 0 | Keywords:
Sub-Project: DNS | Defect Severity: N/A
Estimated Difficulty: 0 | Feature Depending on Ticket:
Total Hours: 0 | Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Currently, our several datasources respond to direct RRSIG queries
differently; the sqlite3-based one returns them, the memory ds returns no
data.
AFAIK, there is no full consensus on what to do here:
- on the one hand, RRSIG should be closely coupled with their
corresponding RRsets, so querying for them separately might cause
unforeseen problems
- however, that is really up to the validator, and not the server (for
instance it might try to work around caches that strip them unless queried
directly)
- returning nothing is technically an invalid DNSSEC response (since the
NODATA response cannot be proven with an NSEC, as the NSEC shows there
should be data)
- and of course it would be good to be consistent.
There was a discussion on namedroppers a while ago:
http://www.ietf.org/mail-archive/web/dnsext/current/msg07123.html
Implementing the 'correct' return of RRSIGs is not entirely trivial for
the memory-backend, but it should not be too hard as long as we don't care
to much about efficiency for this case (do we have data on if and how much
these queries occur?)
If we decide that these queries should NOT be answered, it is probably
better to return something like REFUSED rather than a nodata answer.
--
Ticket URL: <http://bind10.isc.org/ticket/2226>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list