• Save
Ripe64 - ljubljana - dnssec - udp issues-20120418
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Ripe64 - ljubljana - dnssec - udp issues-20120418

on

  • 442 views

 

Statistics

Views

Total Views
442
Views on SlideShare
442
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Ripe64 - ljubljana - dnssec - udp issues-20120418 Presentation Transcript

  • 1. DNSSEC: dealing with hosts that don’t get fragments RIPE 64 DNS wg, Ljubljana, April 18th 2012 Roland van Rijswijk roland.vanrijswijk@surfnet.nl
  • 2. Introducing the issue -In 2010 and in March last year we had “issues” with a very large ISP in The Netherlands -Customers of the ISP were unable to resolve names in surfnet.nl -The cause turned out to be an issue with the ISP’s firewall2 SURFnet. We make innovation work cb
  • 3. A picture to make it clearer ;-) Authoritative Name Server ➀ ➁ min(MTU) = 1500 bytes Internet (somewhere in transit) ➂ ➄ Firewall ➃ ➅ Recursive Caching Name Server3 (resolver)
  • 4. Serious business -Even though we do everything by the book w.r.t. DNSSEC, and even if people don’t validate they still have trouble resolving host names in our zone -We are a research network, so a few bumps in the road don’t scare us -But think of the big enterprises we are trying to convince to start deploying DNSSEC! -Also: the ISP was unable/unwilling to change the firewall setting (“It’s almost Christmas”)4 SURFnet. We make innovation work cb
  • 5. Research at SURFnet -Short student assignment to confirm the problem http://bit.ly/dnssec-frags -Student research confirmed: FRTE messages show up when UDP fragments are dropped -Currently: M.Sc. student working on problem mitigation options and better detection5 SURFnet. We make innovation work cb
  • 6. How big is the problem? #1 -- EDNS0 use:6 Well over 50% of querying hosts use EDNS0
  • 7. How big is the problem? #2 -- EDNS0 advertised buffer size7 About 90% advertise (default) 4K buffer size
  • 8. How big is the problem? #3 -- DNSSEC OK bit set:8 The vast majority sets DO=1
  • 9. Mitigation approaches -Two approaches to mitigation -One: lowering the EDNS0 buffer size on one of the authoritative name servers in the NS set of a domain -Two: detecting problem hosts with a sensor and adapting name server behaviour (dynamically adjusting EDNS0 buffer size)9 SURFnet. We make innovation work cb
  • 10. Real detection -ICMP may be blocked by a firewall -How to detect problem hosts that aren’t allowing ICMP through? -Heuristic approach, 5 rules #1 ICMP FRTE is seen #2 EDNS0 header toggled on/off by querying host #3 (Excessive) retries within TTL of record #4 Changing EDNS0 buffer size in queries #5 Fallback to TCP without truncation10 SURFnet. We make innovation work cb
  • 11. Experiments -Experiment #1: Lowering the EDNS0 buffer size on one authoritative name server to 1232 bytes, so below IPv6 minimum MTU -Experiment #2: Selectively modify advertised EDNS0 buffer size in queries originating from “problem” hosts before they reach the name server11 SURFnet. We make innovation work cb
  • 12. Problem hosts detected Problem(Hosts(per(Case(Type( 100,00%$ 80,00%$ 60,00%$ 40,00%$ 20,00%$ 0,00%$ Case$1$ Case$2$ Case$3$ Case$4$ Case$5$ Problem(Hosts(with(Case(Types( 25000! 20000! 15000! 10000! 5000! 0! ! ! ! ! ! 1!case!type! 2!case!types! 3!case!types! 4!case!types! 5!case!types! Pct.! 0,538605791! 0,386232935! 0,072760914! 0,00240036! 0! Occ.! 21541! 15447! 2910! 96! 0! Analysis shows: ≥2% confirmed problem host12 SURFnet. We make innovation work cb
  • 13. ICMP FRTE behaviour 5,00%$ 4,50%$ 4,00%$ Normal$Opera>ons$IPv4$ 3,50%$ maxCudpCsize=1232$IPv4$ 3,00%$ 2,50%$ Using$DNSRM$IPv4$ 2,00%$ Normal$Opera>ons$IPv6$ 1,50%$ maxCudpCsize=1232$IPv6$ 1,00%$ 0,50%$ Using$DNSRM$IPv6$ 0,00%$ FRTE$sending$hosts$ 7,00# 6,00# Normal#OperaAons#IPv4# 5,00# maxFudpFsize=1232#IPv4# 4,00# Using#DNSRM#IPv4# 3,00# Normal#OperaAons#IPv6# 2,00# maxFudpFsize=1232#IPv6# 1,00# Using#DNSRM#IPv6# 0,00# FRTE#messages/FRTE#Sending#Host# Bottom line: both approaches tackle the problem13 SURFnet. We make innovation work cb
  • 14. Some side-effects 2,00%$ 1,80%$ 1,60%$ Normal$Opera>ons$IPv4$ 1,40%$ maxBudpBsize=1232$IPv4$ 1,20%$ 1,00%$ Using$DNSRM$IPv4$ 0,80%$ Normal$Opera>ons$IPv6$ 0,60%$ maxBudpBsize=1232$IPv6$ 0,40%$ 0,20%$ Using$DNSRM$IPv6$ 0,00%$ Truncated$UDP$messages$ 3,00%$ 2,50%$ Normal$Opera?ons$IPv4$ 2,00%$ maxDudpDsize=1232$IPv4$ 1,50%$ Using$DNSRM$IPv4$ Normal$Opera?ons$IPv6$ 1,00%$ maxDudpDsize=1232$IPv6$ 0,50%$ Using$DNSRM$IPv6$ 0,00%$ Hosts$falling$back$to$TCP$ Note: long bars, but very low percentages14 SURFnet. We make innovation work cb
  • 15. Conclusion -This seems to be a serious issue for DNSSEC- signed zones -There are ways to ameliorate the problem -We are considering writing a best-practice paper (or even an informational RFC) -Expect a paper in IEEE CC Review or ACM Transactions on Networking -Check your firewall settings if you start doing DNSSEC validation on your resolvers!15 SURFnet. We make innovation work cb
  • 16. roland.vanrijswijk@surfnet.nlQuestions? Comments? nl.linkedin.com/in/rolandvanrijswijkPlease contact me! @reseauxsansfil