Version 13 (modified by stephen, 8 years ago) (diff)


Review of

Review of #445: Recursor Cache API Design

Jelte: Need to see how it goes based on use.

Jeremy: Has anybody looked at it?

Jelte had briefly, Michal before switched to A-Team.

Left open.

Review of #449: Recursor Cache 'Quick & Dirty' Implementation

Likun: Not ready for review.

Recursor logic: determining components & interfaces, done

Review of recursor logic, awaiting review from Mark

Recursor logic: breaking components into tasks, complete

#438, Logging: API Design, done

#438, Logging: API Design review, done

#438, Logging: Implementation, not complete

#438, Logging: Test Code review, not complete

Outstanding Tickets

#426: review not done (but owned by Scott)

#427, #428: not done

#430, #432: ready for review

#424: done

Other Bugs

#258, #414, #425 - not done

#431: ready for review

Stephen: seem to be lax on review, so need to give priority to review tasks


Stephen: How to divide the time up?

Scott: We have 8 weeks really, if we assume 1 week hardening...

Stephen: 2x 4-week release cycles, or 1x 8-week release cycle

Michal: I think it would be nice to have a release before the end of the year, because every release finds bugs.

Jeremy: Yes, do a release in the middle.

Jinmei: I agree, but it depends on the overhead of releasing. My understanding is the overhead should be quite small. But this is based on the assumption of continuous integration.

Jelte: In my experience the overhead of releasing has decreased since we started doing Scrum.

Jinmei: So basically we should use the exact snapshot at the release date. If we could do that, the benefits should outweigh the overhead. Very much so.

Stephen: Release in 4 weeks time, candidate release in 8 weeks time, last week doing any hardening that is needed.

Priorities for Delivery

  1. Define Root
  2. Iteration
  3. Cache
    • TTL limits
    • Deepest zone cut
    • Trust level
  4. Hook up cache to iterator
  5. Hook up NSAS to iterator/cache
  6. Check if timeouts present
  7. Data scrubbing
  8. CNAME
  9. CNAME loop detection
  10. TCP
  11. Query tracing
    • Design
    • Implementation



#384 bindctl printing #445 API Design #438 Logging

Bug Reviews

#427, #428, #430, #431, #432, #479

Outstanding Tasks

#449 Cache (Quick & Dirty)

#449 Cache review

Task List for Recursor

Goal: list of tasks we can open tickets for that will get us closer to goal

  1. Define root
    • Configuration item with list of IP addresses to query (task A, 2)
    • Access IP addresses (task A, 2)
  1. Iteration
    • Clean up skeleton for very basic form of iteration, and merge in (task B, 5)
      • Build query context structure (restructure lookup provider & answer provider APIs)
    • Encapsulate sending fetch out which will be put into demux thing later (task C, BASELINE 8)
      • Create packet for arbitrary name
      • Send existing packet to different server (or re-create)
      • Interface to coroutines
      • De-duplication (task D, 5-20)
    • Handle query response from authoritative server (task E, 3)
      • Detect error
      • Detect answer
      • Detect referral
      • Detect CNAME
    • Handle referral (task F, 3)
    • Config timeouts: receiving response, stop trying, stop for specific client
      • need timer to stop trying (task G, 2)
    • Handle packet errors from clients (task H, 2)
    • Connect DNS cache (task J, 4)
      • Ask cache for exact RR
      • Put information into cache
    • Minimal responses (no additional section)
      • No task - idea is to do no work regarding additional section handling
    • Search cache for closest enclosing name NS (task M, 1)
    • Negative cache (possibly large task) (task N, 5)
      • Quick & dirty hack
  1. Hook up NSAS to iterator/cache (TBD later this week)
    • Asking NSAS for IP address
    • Interface to resolver
    • Update NSAS based on child response (optional?)
  1. Check if timeouts are present (task P)
    • DONE!
  1. Data scrubbing
    • checking Q.I.D. (task Q, 3)
    • additional glue (task Q, 3)
    • zone must be authoritative for data (task R, 3)
    • exclude out of bailiwick data (task R, 3)
  1. CNAME processing / 9. CNAME loop detection
    • storing CNAMEs encountered (task S, 3)
    • check count of CNAMEs (task S, 3)
    • initiate new query based on CNAME (task T, 2)
  1. TCP (as a client) (task U, 5)
    • detect TC bit
    • TCP fetcher
  1. Query tracing
    • design (task V)
    • configuration ???
    • ... implementation ... ???

The following task was discussed at the meeting the following day, and is needed to resolve a possible problem in the resolve where the TTL of glue has been set to zero.

  1. NSAS Glue Corrections
    • Add relevant glue as information to queries between Resolver and NSAS
    • Add method to resolver to tell it to return glue if information is not in the cache