0% found this document useful (0 votes)
118 views22 pages

Unbound in C: San Diego - 2006 Wouter Wijngaards (Wouter@Nlnetlabs - NL)

The document discusses the design of the Unbound DNS resolver, including server design options using threads or queues, module design and inputs, caching approaches, handling local zones, and other technical details.

Uploaded by

lokpres
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
118 views22 pages

Unbound in C: San Diego - 2006 Wouter Wijngaards (Wouter@Nlnetlabs - NL)

The document discusses the design of the Unbound DNS resolver, including server design options using threads or queues, module design and inputs, caching approaches, handling local zones, and other technical details.

Uploaded by

lokpres
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 22

Unbound in C

San Diego - 2006


Wouter Wijngaards
([email protected])

http://www.nlnetlabs.nl/
© Stichting NLnet Labs
page 2

Outline

Goals

Design

Server design

Module design

Major Issues

Threads

Local zone server

Compression

Detail Issues

Data Store

Spoofing Prevention

Overload Handling
http://www.nlnetlabs.nl/
page 3

Goals

Validating recursive DNS resolver

Another alternative open source implementation

DNSSEC, RFC compliant, high performance

Elegant design

Portable C

BSD License(?)

NOT

an authoritative server

Feature bloat – difficult for a resolver

http://www.nlnetlabs.nl/
page 4

Server design options


•How to thread and do the workflow?
– Looked into literature
•Event driven
– Select() and events drive state machines
– Every thread has all modules
•SEDA
– Staged event driven arch
– Queues to threadpools that do one module
•Discussion of these two options on next slides

http://www.nlnetlabs.nl/
page 5

threadpool
SEDA threadpool
Next
clients Accept queue Module
queue...
queue/pool manager
thread
• Positive
– Queues reordered for cache
– Unequal validation load could be moved
• Negative
– Queues add enormous latency to requests
– Queue and thread management problem
– Slight downfall on DoS
– Queue growth memory problem
http://www.nlnetlabs.nl/
page 6

Event driven
threadpool
clients Worker event Module

• Main routine blocks in select() call


– Every module has a state, event-driven
– Process every request until finished or blocked.
• Positive
– Good characteristics under heavy load
• Requests are finished instead of queued up.
– Less overhead in queuing, locks, thread scheduling
• Negative
– Complicated due to stateful modules
– Validation load falls to thread that accepted request
http://www.nlnetlabs.nl/
page 7

Workflow
•Clean modules can be used for any design
•Modules to call another – from Unbound Java

Network Network
Validator Iterator
accept query to servers

clients Other
Cache
servers

http://www.nlnetlabs.nl/
page 8

Server design
Query Clients
packet
•Server main puts
Request list
requests in queue
•Handler Scheduler
– Look in msg cache
next
– Calls modules Module
done
– Send reply if done Server
Pending list
•Messages from reply
network can wake up Other
a suspended request servers
http://www.nlnetlabs.nl/
page 9

Module Design – input!


State Input Callbacks
• Request
• Results from: Custom alloc
Per request • Module call
• qname, type, class • Network / timeout RRset cache
• Module state var • Subrequest
Msg cache
• No buffers (plz!)
module_activate() Network query

Per module Create subreq


Output
• Module caches • Finished: result (ptr to msg) Subreq to what module?
• HandOver: Call next module • First, next, same
• Module config • Suspended (subreq, network)
• Module callbacks More callbacks ?

http://www.nlnetlabs.nl/
page 10

Link and Compile


• Every module can be linked on its own
against a main program
• Main program provides callback services
• Different main programs to make
– Unit test programs
– Resolver library
– Remote (TCP) module connections
– Server
• Valid, iter are clean modules but cache is still
special.
http://www.nlnetlabs.nl/
page 11

Threading and forks



Threads Main process

Speed advantage on shared
memory cache

As little locks as possible proc 1 proc n

Work without threads too
thread 1 thread m

Every thread

Listens on port 53

Listens to own port(s)

Own query list • Shared - locked

Own local cache (called L1) – shared cache (called L2)
– Request counts
– malloc/free service

http://www.nlnetlabs.nl/
page 12

Caches – Need input!



Caches • Clean cache design?

RRset – Generic L1-L2

Msg-reply fallback

Trusted-key – Generic by datatype,

Infrastructure module.

Where? L1(local), – Some caches do
L2(shared). • static config
• Localzone serve

http://www.nlnetlabs.nl/
page 13

Local Cache
•L1: rbtree, hashtable.
– LRU double linked list woven in, delete items to
make room if at max size of the cache.
– Timeout checked when access an item - refetch
Tree+LRU Hashtable+LRU
LRU
Lookup

http://www.nlnetlabs.nl/
page 14

Shared Caches
•L2: hashtable, locks per bucket.
– Read: Copy data out – no locks per entry
– LRU? Write/Delete? Avoid deadlock.
• Separate double linked LRU list?
– Find an item to delete – snip off LRU list. Then delete in
hashtable (get lock on buckets).
• LRU updated on reads – how locking?
– Unlock bucket, get lock on entire LRU list to update.
• One big lock on LRU list. Bad. (input!)

http://www.nlnetlabs.nl/
page 15

Local zone server



Need a local zone served (.localdomain)

AS112 zones, do not leak

Unbound not authoritative server!

Options

NXDOMAIN (default for AS112)

Forward to (NSD) on host:port

Basic service

No CNAME, DNAME, wildcards, NSEC ...

This is authoritative service!

Do it right or don't.
http://www.nlnetlabs.nl/
page 16

Compression

Never uncompress incoming data:

Hard to store RRsets separately

sendmsg/writev gather of uncompressed data

Use header,qname and rrset data without copying (!)

Have to update TTL values before send

Canonical rrset format ready for validation crypto

copy&compress: use rbtree in L1 rrset cache for offsets

As a config option; copy=less cpu, compress=less bytes.

Keep Rrsets locally compressed

Have to update compression ptrs and TTLs before send

Not canonical format

Imperfect compression ratio
http://www.nlnetlabs.nl/
page 17

Data store
•Packed RRset
– Keeps wireformat RRset, ptrs to RRs, TTL.
– Could keep RRSIG over the RRset as well
•TTL in absolute times
– Use min TTL for RRsets, messages.
•Cache entries have validation status
•Store hashvalue in cache objects.
•dnames kept in wireformat, label offsets
•Ldns: No need to do all DNS constants again
http://www.nlnetlabs.nl/
page 18

Msg-RRset pointers

Msg(q+reply) consists of RRsets

Keeping RRset inside msg is waste memory

Rrset*: hard to find/lock msg on rrset delete

First 64bits in RRset are creation ID.

thread_num (16bit), seq_number (48bit).

seq_number wraps: clear cache / abort

Keep RRset* and ID, check ID on use.

Reuse RRset memory only for RRsets

Zero ID means RRset is not in use.

Copy RRset from/to cache gets new ID.
http://www.nlnetlabs.nl/
page 19

Spoof Prevention
•Random IDs:
– Random() with initstate(256 bytes)
•port ranges:
– Needed per thread (to listen easily)
– Kqueue, kpoll() sys calls
•Scrubber for incoming messages
– Routine in Iterator? Or Validator?
– Spoofed NS additionals confuse iterator
• But get caught by validator afterwards
– Scrubber as a module? Valid. Iter. Scrub.
• Between iterator and network.
http://www.nlnetlabs.nl/
page 20

Overload handling
•On overload answer from cache
•Detect overload
– Request list is full
– One thread: stop listen port 53
– All threads: overload mode
• Answer from cache or drop query.
•Schedule 1:2 ratio for port 53 : other ports
– Does not depend on number of other ports
– Drives towards completion of waiting queries
– Every select: perform 0/1 port 53 and round
robin the other ports handle at most 2.
http://www.nlnetlabs.nl/
page 21

Concept Module:
Remote Cache module
A remote server Cache module

Runs with a cache – Checks msg cache
module only – If not: network msg

Store/Retrieve msg to cache server
and reply (suspend)

Like remote msg – If not: next module
cache – Result next module

Localhost cache for • Store on server
nonthreaded pcs • Finished(result).

For a resolver farm

http://www.nlnetlabs.nl/
page 22

Unbound-C
Summary
•Event driven
•Modular design
– Callbacks – minimal OO Family of
– Modules can call next module Unbound-Java
– Suspend waiting for network reply
•Threads: minimal, cache a copy
•Needs tweaks
– Compression choice
– Cache code
– Module interfacing
http://www.nlnetlabs.nl/

You might also like