Opened 9 years ago

Closed 5 years ago

#692 closed defect (wontfix)

response with NSEC3 for class ANY queries

Reported by: jinmei Owned by: UnAssigned
Priority: medium Milestone: DNS Outstanding Tasks
Component: data source Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 0.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

This is a remaining task for #80. We first need to add tests about
query logic (in general) for NSEC3 responses, and then make the same
fix as the one we did for #80.

Subtickets

Change History (15)

comment:1 Changed 9 years ago by stephen

  • Milestone A-Team-Task-Backlog deleted

Milestone A-Team-Task-Backlog deleted

comment:2 follow-up: Changed 8 years ago by shane

  • Defect Severity set to N/A
  • Owner set to jinmei
  • Status changed from new to assigned
  • Sub-Project set to DNS

Jinmei, I'm thinking that we can close this ticket. Please let me know.

comment:3 in reply to: ↑ 2 Changed 8 years ago by jinmei

  • Milestone set to New Tasks

Replying to shane:

Jinmei, I'm thinking that we can close this ticket. Please let me know.

In the sense it will be moot with the migration to the new datasource
API, possibly. But we should probably create a ticket about handling
class ANY queries in the new framework.

comment:4 Changed 8 years ago by jinmei

  • Owner changed from jinmei to shane

comment:5 follow-up: Changed 8 years ago by shane

  • Milestone New Tasks deleted
  • Owner changed from shane to jinmei

Jinmei, sorry for taking so long to reply.

I'm not sure what work you mean we need when you say we should create a ticket. Can you explain?

comment:6 in reply to: ↑ 5 Changed 8 years ago by jinmei

Replying to shane:

Jinmei, sorry for taking so long to reply.

I'm not sure what work you mean we need when you say we should create a ticket. Can you explain?

How we handle class ANY query in general. The current code only
accepts the case of exact match:

        const ConstQuestionPtr question = *message.beginQuestion();
        if (memory_client_ && memory_client_class_ == question->getClass()) {

(and simply changing this condition to "or getClass is ANY" may not
work if there's strict class matching within the data source code).

comment:7 Changed 8 years ago by jinmei

  • Owner changed from jinmei to shane

comment:8 follow-up: Changed 7 years ago by shane

  • Owner changed from shane to jinmei

Jinmei, I'm being lazy, and wondering what the status of ANY queries is now that we've adopted the new data source code...

comment:9 in reply to: ↑ 8 Changed 7 years ago by jinmei

Replying to shane:

Jinmei, I'm being lazy, and wondering what the status of ANY queries is now that we've adopted the new data source code...

You might be confused, so first: Note that this is about *class* ANY,
not type. And, as far as I can see the new implementation still
doesn't support it correctly (although I'm not even 100% sure about
what is "correct"). But in any event, the new implementation
shouldn't have subtle issues like the one discussed in this ticket.

So, at this point, we can probably just close this ticket, and maybe
open a new generic ticket (with a lower priority) for handling
class-ANY query.

comment:10 Changed 7 years ago by jinmei

  • Owner changed from jinmei to shane

comment:11 follow-up: Changed 7 years ago by shane

Interesting. Is the behavior of class ANY unspecified in the RFCs? Is there any BCP outside of those? Presumably we could consider BIND 9 behavior a starting point...

comment:12 in reply to: ↑ 11 Changed 7 years ago by jinmei

Replying to shane:

Interesting. Is the behavior of class ANY unspecified in the RFCs? Is there any BCP outside of those? Presumably we could consider BIND 9 behavior a starting point...

From a quick search of RFC1035, there doesn't seem to be a clear
specification.

Regarding the BIND 9 behavior, it'd depend on how we want to handle
views, because the class selection in BIND 9 is highly coupled with
views.

comment:13 Changed 7 years ago by shane

  • Owner changed from shane to UnAssigned

comment:14 Changed 6 years ago by stephen

  • Milestone set to DNS Outstanding Tasks

comment:15 Changed 5 years ago by tomek

  • Resolution set to wontfix
  • Status changed from assigned to closed

DNS and BIND10 framework is outside of scope for Kea project.
The corresponding code has been removed from Kea git repository.
If you want to follow up on DNS or former BIND10 issues, see
http://bundy-dns.de project.

Closing ticket.

Note: See TracTickets for help on using tickets.