← Back to branch summary

~ubuntu-branches/ubuntu/raring/maradns/raring

« back to all changes in this revision

Viewing changes to deadwood-2.4.10/doc/internals/TODO

  • Committer: Bazaar Package Importer
  • Author(s): Kai Hendry
  • Date: 2010-01-24 12:17:40 UTC
  • mfrom: (1.1.13 upstream) (10.1.4 sid)
  • Revision ID: james.westby@ubuntu.com-20100124121740-a4e1fjobwaouz443
Tags: 1.4.02-1
New upstream release

Show diffs side-by-side

added added

removed removed

Lines of Context:
deadwood-2.4.10/doc/internals/TODO
 
1
OK, we have basic UDP-only caching (with the ability to read and write
 
2
the cache to disk).  Let's improve that:
 
3
 
 
4
* If the server sends us "truncated", just give the user this reply
 
5
  without caching it. (DONE; caching disabled for tuncated replies)
 
6
  Make sure we fully validate a truncated packet.
 
7
 
 
8
* Bugfix: The Google problem.  Google.com's DNS reply is in the form
 
9
  "Cache for one day: Google.com is a CNAME for www.l.google.com;
 
10
   Cache for one hour: www.l.google.com has the ip 192.168.1.55"
 
11
  Deadwood 2 only looks at the first TTL for a DNS packet and use that
 
12
  to determine how long to cache a reply; Deadwood 2 should look at the
 
13
  first 2 (or first N) TTLs and cache the entire reply for the minimum 
 
14
  TTL Deadwood sees (right now Deadwood 2 caches Google.com for one week
 
15
  when it really should only cache it for one hour) (DONE)
 
16
 
 
17
* RFC compliance: Records with a TTL of 0 should not be cached. (DONE
 
18
  by Neeo)
 
19
 
 
20
* Safe cache writing: Write to a temporary file and rename the file to 
 
21
  the name of the cache file when the write is done.
 
22
 
 
23
* Timed cache writing: Allow Deadwood to write to the cache every N minutes;
 
24
  this will allow Windows users to have cachefiles. (The Windows port just
 
25
  writes the cache when the service is stopped)
 
26
 
 
27
* Windows support: (Windows is important because MaraDNS is the only 
 
28
  open source DNS server I know of, besides BIND, to run on Windows)
 
29
  How does Windows do signals, so writing the cache to a file works
 
30
  in Windows? (DONE; Deadwood now Windows service)
 
31
 
 
32
* OK, once all of that is done, another wishlist item: Handle DNS-over-TCP
 
33
  correctly.  Instead of having TCP connections handled by a separate
 
34
  non-caching daemon, have the main daemon get TCP connections, 
 
35
  convert them in to UDP connections.  Also, should we get a truncated 
 
36
  UDP packet, try again using TCP. (DONE)
 
37
 
 
38
* OK, another wishlist item: Synthetic replies.   If they ask for an A
 
39
  record, and we can't talk to upstream -or- upstream gives us a 
 
40
  not there/NXDOMAIN, we give them a synthetic A record.  Think "You're
 
41
  not logged on to our network" pages. (I've done the opposite: If you 
 
42
  have an ISP with an annoying page with ads when you mistype a domain 
 
43
  name, Deadwood can make the DNS reply "not there" instead).
 
44
 
 
45
* Wishlist item: TTL aging.  Not really sure how I'll pull this off
 
46
  (give each hash entry an "atime" entry?; make it so each entry has the
 
47
   same TTL for all DNS entries?) (DONE)
 
48
 
 
49
Some thoughts about the cache design.
 
50
 
 
51
* The code that retries may end up trying to contact the same dead upstream
 
52
  server again.  We should change this; when making a connection upstream,
 
53
  we should note which server we tried to contact, and have it so we don't
 
54
  contact that server the next time we try to make a connection.  Maybe even
 
55
  have an array of the number of times we have failed to connect to a given
 
56
  upstream server, and have the code use a heuristic to try less connections
 
57
  with an unreliable server.
 
58