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