Κατηγορία: DNS

Ξεκίνησα σήμερα διαβάζοντας το παρακάτω επείγον announcement του BIND ..

  URGENT URGENT URGENT URGENT URGENT URGENT URGENT URGENT URGENT URGENT URGENT
  URGENT                                                                URGENT
  URGENT    THIS ANNOUNCEMENT REFERS TO AN ISSUE THAT MAY AFFECT THE    URGENT
  URGENT           INTEGRITY OF YOUR RECURSIVE DNS SERVICE              URGENT
  URGENT                                                                URGENT
  URGENT URGENT URGENT URGENT URGENT URGENT URGENT URGENT URGENT URGENT URGENT

    Thanks to recent work by Dan Kaminsky of IOActive, ISC has become
    aware of a potential attack exploiting weaknesses in the DNS protocol
    itself to enable the poisoning of caching recurive resolvers with
    spoofed data.

    For additional information about this vulnerability, see US-CERT
    (CERT VU#800113 DNS Cache Poisoning Issue).  For more details on
    changes to BIND, see http://www.isc.org/sw/bind/forgery-resilience.php.

    IF YOU ARE RUNNING BIND AS A CACHING RESOLVER YOU NEED TO TAKE ACTION.

Προφανώς δεν είναι μόνο στο bind, αλλά και σε πολλά άλλα DNS implementations (Microsoft, Cisco, etc), aφού το πρόβλημα είναι «in the DNS protocol itself»..

Περισσότερες πληροφορίες για vulnerable systems στο CERT VU#800113 και για το συγκεκριμένο θέμα μετά το Black Hat Conference στις 7 Αυγούστου.

Προσοχή γιατί μπορεί να χρειαστεί αλλαγή στο firewall που έχετε αλλά και στο configuration (βλέπε debian security advisory dsa-1603).

Unbound, DSC, Heavy Hitters, Large-Scale DNS Caching Servers, Privacy issues in DNS.. Πολύ ενδιαφέρουσες αυτές και γενικά όλες οι παρουσιάσεις από το 2008 OARC DNS Operations Workshop ..

Μεταξύ άλλων στην παρουσίαση NSF DNSPERF Project Report (Brian Reid, ISC) εμφανίζουν νέα test data από το DNS Performance Testing Project πού είχαμε δει παλιότερα, όπου το Linux-Fedora αυτή τη φορά έχει περισσότερα queries/sec από το FreeBSD 7-RC1 (ρίχνω λάδι στη φωτιά ;))

Σήμερα ένας φίλος sysadmin μου είπε για το DNS Performance Testing Project του ISC. Λέει ότι είναι ακόμα work in progress, αλλά έχει πραγματικά ενδιαφέρον από πολλές απόψεις..

Κατ’ αρχήν μας δείχνει τη μεθοδολογία που χρησιμοποίησε το ISC για να διαλέξει το Server Hardware που θα τρέξει το BIND.

Our experience as authors of the BIND software is that the performance of BIND is limited primarily by the processor and memory performance of the server computer. […] We have identified several candidate server computer configurations based on price and availability and have measured the memory performance (bandwidth, latency, and cache performance) of each.

Και μας δίνει μια σειρά από software tools για να μετρήσουμε κι εμείς στα δικά μας συστήματα ακριβώς αυτά.. memtest86 για memory και cache transfer rates, Calibrator, lmbench και STREAM για (cache-) memory latency και TLB performance.

Μετά, για το Operating System Evaluation, κάνουν capture με tcpdump την κίνηση του F-root και με τη βοήθεια του queryperf το στέλνουν στο BIND που τρέχει σε διάφορα λειτουργικά..

Αφήνω το προφανές σχεδόν ασχολίαστο, γιατί δε θέλω να ξεκινήσουμε Holly War.. Δηλαδή ότι το BIND που έτρεξε σε linux kernel 2.6.x είχε περισσότερα queries/sec απ’ότι σε FreeBSD.. Είναι προφανές ότι δεν το περίμεναν και οι ίδιοι, γιατί λένε ότι θα επαναλάβουν τις μετρήσεις όταν βγει το FreeBSD 7.1.

Σημαντικές παρατηρήσεις είναι ότι

• Δεν έχει επίπτωση στο server performance το filesize του zone file (αρκεί να είναι μικρότερο από το μέγεθος της physical RAM).
• Επίσης δεν υπάρχει διαφορά σε performance αν το zone file είναι signed ή unsigned (βλέπε DNSSEC), εκτός του ότι στη signed υπάρχει περισσότερο συνολικό network traffic.
• Σ’έναν authoritative name server που θέλουμε top performance βάζουμε και τα options
  • check-sibling no;
  • fetch-glue no;
  • recursion no;
  • acache-enable yes;
  • max-acache-size 128M;

  (Για εξηγήσεις βλέπε στο BIND 9.4 Administrator Reference Manual)