Scaling
DNS
Requirements
●   Large domain registrar
●   A few hundred thousand domains using our
    DNS.
    –   Nearly a million dom...
●   Why use a database?
●   Choosing an option
    –   Stability
    –   Performance
    –   Support
●   Options considere...
Flat files don't always rock
●   Flat files rock for system administrators
    –   DNS administrators may not have root ac...
Flat files don't always rock
●   Flat files cause a startup time delay on the
    server process
    –   For BIND, this pe...
BIND
●   Native BIND has “some” support.
    –   One connection to the backend for each domain
    –   Low performance
BIND-DLZ
●   Patch to BIND
    –   See http://bind-dlz.sourceforge.net/
●   One/Two connections to the backend for all
   ...
BIND-DLZ architecture




BIND   DLZ    DBMS
DLZ schema
●   BENEFITS
    –   Single connection to database
    –   Single table needed to store all records
         ● ...
PowerDNS
●   DNS server written in C++
●   Separate authoritative and recursive servers
●   Strong focus on security
PowerDNS architecture


             Cache




PowerDNS
 frontend                 Database




             Database
     ...
PowerDNS
●   BENEFITS
    –   One or more connections to the database
    –   Two tables needed
    –   Internal in-memory...
MyDNS
●   Not maintained – last update was 2006
●   Hardcoded schema
    –   We have our own.
Lies, damn lies and statistics
●   Actually, performance benchmarks
●   Native BIND wasn't going to be very useful to
    ...
Testing
●   Test infrastructure was a single host with two
    dual core Xeon CPUs at 2.something GHz and
    16 GB of RAM...
Results
BIND-DLZ with BDBHPT, 2 queryperf clients, transaction
mode                                                     40...
Same numbers, as a graph
50000



45000



40000



35000



30000



25000                              qps



20000



1...
Operational architecture
  PowerDNS
                     Slony
             Slave            Master
  PowerDNS   DC1      ...
Software
●   Master database is PostgreSQL 8.2.x
●   Read-only slaves have some tables replicated
    from the master data...
In Practice
●   Maximum database replication lag is 10
    seconds.
●   PowerDNS has peaked at ~ 10000 qps during a
    Dd...
Questions?
Upcoming SlideShare
Loading in …5
×

Scaling DNS

2,981 views

Published on

Published in: Technology
1 Comment
6 Likes
Statistics
Notes
  • Thank you for sharing this information - it was very useful in the decision making process last year when laying out the architecture for dnshat.com - ran across it again today researching a different topic and just wanted to drop a note to say Thanks!
    -Scott
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,981
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
78
Comments
1
Likes
6
Embeds 0
No embeds

No notes for slide

Scaling DNS

  1. 1. Scaling DNS
  2. 2. Requirements ● Large domain registrar ● A few hundred thousand domains using our DNS. – Nearly a million domains ● Still growing ● Need fast updates on the authoritative servers – Especially when a new domain is added – Or removed
  3. 3. ● Why use a database? ● Choosing an option – Stability – Performance – Support ● Options considered – BIND – BIND-DLZ – PowerDNS – MyDNS
  4. 4. Flat files don't always rock ● Flat files rock for system administrators – DNS administrators may not have root access – Editing flat files from the web is ... insane ● Delegating single zone management is difficult ● Edits and reloads have to be batched ● Startup times for nameserver processes
  5. 5. Flat files don't always rock ● Flat files cause a startup time delay on the server process – For BIND, this penalty is huge ● A single host, with 113K small zones took slightly over an hour to start with flat files ● It then served data at about 30K qps – PowerDNS is “optimised” for this task ● It took over 6 minutes to parse 113K small zones and start serving data ● This served data at about 26K qps
  6. 6. BIND ● Native BIND has “some” support. – One connection to the backend for each domain – Low performance
  7. 7. BIND-DLZ ● Patch to BIND – See http://bind-dlz.sourceforge.net/ ● One/Two connections to the backend for all domains ● User defined queries, including stored procedures ● Supports MySQL, PostgreSQL, OpenLDAP, BDB
  8. 8. BIND-DLZ architecture BIND DLZ DBMS
  9. 9. DLZ schema ● BENEFITS – Single connection to database – Single table needed to store all records ● Keeps it simple ● DISADVANTAGES – No caching – Bad performance – Third party patch to BIND
  10. 10. PowerDNS ● DNS server written in C++ ● Separate authoritative and recursive servers ● Strong focus on security
  11. 11. PowerDNS architecture Cache PowerDNS frontend Database Database abstraction layer
  12. 12. PowerDNS ● BENEFITS – One or more connections to the database – Two tables needed – Internal in-memory cache makes responses fast – Low memory footprint ● DISADVANTAGES – Cache management – DNSSEC (partial support, WIP) and views (no support) – http://www.powerdnssec.org/
  13. 13. MyDNS ● Not maintained – last update was 2006 ● Hardcoded schema – We have our own.
  14. 14. Lies, damn lies and statistics ● Actually, performance benchmarks ● Native BIND wasn't going to be very useful to us. We didn't test it at all, except as a baseline statistic.
  15. 15. Testing ● Test infrastructure was a single host with two dual core Xeon CPUs at 2.something GHz and 16 GB of RAM with one disk, running the nameserver and the database ● The clients were three pentium boxes with 1 GB of RAM connected over a 100 Mbps network. ● We used the commandline queryperf tool to run queries. – queryperf -q 20 -s <IP> -d <FILE>
  16. 16. Results BIND-DLZ with BDBHPT, 2 queryperf clients, transaction mode 4000 BIND-DLZ with BDBHPT, 2 queryperf clients, transaction mode, RAMDisk 5600 BIND-DLZ with PostgreSQL, raw queries 1800 BIND-DLZ with PostgreSQL, Stored procedures 2000 BIND-DLZ with PostgreSQL, SP, 8 DLZ threads 4800 Nominum ANS, default cache size 25200 Nominum ANS, cache size 512 MB 30000 Raw BIND 21700 PowerDNS, hash as cache, 115K domains 20000 PowerDNS, hash as cache, 3M domains 7000 PowerDNS, RBT with single threaded cache, 3M domains 21000 PowerDNS, RBT w/ single threaded cache, 10M domains 23000 PowerDNS, RBT w/ multi-threaded cache, 10M domains, 2.9.22 46000
  17. 17. Same numbers, as a graph 50000 45000 40000 35000 30000 25000 qps 20000 15000 10000 5000 0
  18. 18. Operational architecture PowerDNS Slony Slave Master PowerDNS DC1 DC1 Slave PowerDNS DC2 Web UI Slave DC3 PowerDNS Management Script
  19. 19. Software ● Master database is PostgreSQL 8.2.x ● Read-only slaves have some tables replicated from the master database via Slony. ● Cache maintainance is a homegrown script.
  20. 20. In Practice ● Maximum database replication lag is 10 seconds. ● PowerDNS has peaked at ~ 10000 qps during a DdoS – This would have brought down the previous BIND- DLZ installations – We didn't notice the blip ● Yes, monitoring needs improvement ;)
  21. 21. Questions?

×