1 / 16

Recursive DNS Cache Auditing

Recursive DNS Cache Auditing. Jose Avila III Founder, ONZRA. Who Am I?. One of the founders of ONZRA Security Researcher Previous Lead Developer at NeuStar for the Managed Internal DNS and SiteBacker2 products. Cache Poisoning Is Not New!.

cgorman
Download Presentation

Recursive DNS Cache Auditing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Recursive DNS Cache Auditing • Jose Avila III • Founder, ONZRA

  2. Who Am I? • One of the founders of ONZRA • Security Researcher • Previous Lead Developer at NeuStar for the Managed Internal DNS and SiteBacker2 products

  3. Cache Poisoning Is Not New! • We find out we were poisoned when services start failing! • There is a need for a notification system • Why aren’t there solutions to detect this?

  4. Where Does ONZRA Fit In? • Developing a Cache Verification Tool • Verifies changes seen in cache • Alert on potential Cache Poisoning Events • Similar to DoX concept

  5. How Does It Work? • Takes a dump of the in-memory cache • Finds differences with an old dump • Verifies the changes • Checks authoritative servers • Checks peer recursive servers • Alerts if results could not be verified

  6. Features • Recordset comparison • Content Delivery Network detection • Record type based comparison • Threshold based peer approval • History tracking • Alerting based on percentage of change

  7. Content Delivery Network Detection • Detected by comparing the record sets amongst the peers • Can lower the alert level

  8. Record Comparison • Ordering of records does not matter • We don’t have to verify everything • What we do not verify: • MX Record: Preference • SOA Record: Serial, etc.

  9. Threshold Based Peer Approval • Based on the threshold of required peers we need to alter our probing interval. • If too much time passes we will not be able to verify with peers

  10. Probe Interval • Verify Freq. = TTL-(THRESHxTTL/PEERS) • Verifying against: • 20 Peers • 10% Threshold • 120s Min TTL • Need to verify cache every 108 seconds

  11. History Tracking • Stores a history of prior record sets • If the record is not verified by peers its verified against historic values

  12. Detecting Fast Flux • Value changing quicker than the TTL • Peers will have multiple values represented • Screws up prior formula • How can we verify these? • Shared DB of historic data?

  13. Tool Components • TCP Daemon (Listens for Cache Dumps) • Cache Dump Parsers • Cache Compare • Application Cache • CDN / Fast Flux Detection • Alerter (Currently only SYSLOG)

  14. What Resolvers Are Supported? • Currently Supported • Microsoft DNS • Bind • Supported eventually • DJB DNS w/ custom Patch • PowerDNS

  15. Future Features • Cache Verification Service? • More Research Data • Multiple Query Nodes • Better CDN Detection • Use peer cache dumps instead of querying • Interaction with other DNS Projects

  16. Questions? Jose.Avila@ONZRA.com Keith.Myers@ONZRA.com

More Related