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 firewall
2 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 Server
3 (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 detection
5 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 size
7 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 truncation
10 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 server
11 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 host
12 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 problem
13 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 percentages
14 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.nl
Questions? Comments?
nl.linkedin.com/in/rolandvanrijswijk
Please contact me! @reseauxsansfil