Ripe64 - ljubljana - dnssec - udp issues-20120418

476 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
476
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Ripe64 - ljubljana - dnssec - udp issues-20120418

    1. 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. 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. 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. 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. 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. 6. How big is the problem? #1 -- EDNS0 use:6 Well over 50% of querying hosts use EDNS0
    7. 7. How big is the problem? #2 -- EDNS0 advertised buffer size7 About 90% advertise (default) 4K buffer size
    8. 8. How big is the problem? #3 -- DNSSEC OK bit set:8 The vast majority sets DO=1
    9. 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. 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. 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. 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. 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. 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. 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. 16. roland.vanrijswijk@surfnet.nlQuestions? Comments? nl.linkedin.com/in/rolandvanrijswijkPlease contact me! @reseauxsansfil

    ×