DNSSEC & fragmentation a prickly combination Roland van - - PowerPoint PPT Presentation

dnssec fragmentation a prickly combination
SMART_READER_LITE
LIVE PREVIEW

DNSSEC & fragmentation a prickly combination Roland van - - PowerPoint PPT Presentation

DNSSEC & fragmentation a prickly combination Roland van Rijswijk - Deij roland.vanrijswijk@surfnet.nl The problem in 1 slide Authoritative Name Server Firewall Recursive Caching Name Server (resolver) 2 SURFnet:


slide-1
SLIDE 1

DNSSEC & fragmentation a prickly combination

Roland van Rijswijk - Deij roland.vanrijswijk@surfnet.nl

slide-2
SLIDE 2

SURFnet: we make innovation work

The problem in 1 slide

2 Recursive Caching Name Server (resolver) Authoritative Name Server

➀ ➁ ➃ ➂

Firewall

slide-3
SLIDE 3

SURFnet: we make innovation work

Extent of the problem

  • 9% of all internet hosts may have problems

receiving fragmented UDP messages [1];

  • 2% – 10% of all resolving name servers

experience problems receiving fragmented DNS responses [2]

[1] Weaver, N., Kreibich, C., Nechaev, B., and Paxson, V.: Implications of Netalyzr’s DNS

  • Measurements. In: Proceedings of the First Workshop on Securing and Trusting Internet Names

(SATIN), Teddington, United Kingdom, (2011). [2] Van den Broek, J., Van Rijswijk, R., Pras, A., Sperotto, A., “DNSSEC and firewalls - Deployment problems and solutions”, Private Communication, Pending Publication, (2012).

3

slide-4
SLIDE 4

SURFnet: we make innovation work

The problem biting us for real

  • SURFnet deployed DNSSEC for surfnet.nl in

2010 (first secure delegation in .nl)

  • Within a week we had problems
  • Cause: largest ISP (2.5M users) in the country

blocks fragments on service network edge

  • Helpdesk:

“SURFnet is doing something wrong” :-(

4

slide-5
SLIDE 5

SURFnet: we make innovation work

Solutions

  • Resolving name servers SHOULD advertise a

proper max. response size to avoid fragmentation issues [RFC 2671BIS (DRAFT)]; Not explicitly stated in standards yet, nor widely implemented;

  • Until then: set maximum response size at some

authoritative name servers

5

slide-6
SLIDE 6

SURFnet: we make innovation work

Resolver experiments (1) Normal operations

6

109$ 785$ 687$ 281$ 83$ 105$ 150$ 388$ 381$ 0$ 100$ 200$ 300$ 400$ 500$ 600$ 700$ 800$ 900$ Windows(Server(2012( Unbound( BIND( Time((ms.)(

Response(>me((ms.)(

slide-7
SLIDE 7

SURFnet: we make innovation work

Resolver experiments (2) Blocking fragments

7

1.175% 4.463% 465% 2.524% 760% 3.435% 0% 1.000% 2.000% 3.000% 4.000% 5.000% 6.000% Windows(Server(2012( Unbound( BIND( Time((ms.)(

Response(>me((ms.)([0/5(altered(Authorita>ve(Name(Servers](

[24,195;12,167] x̅=17,787

Time x2 Time x10 (!) Time x100+ (!!!)

slide-8
SLIDE 8

SURFnet: we make innovation work

Resolver experiments (3)

  • Max. resp. size on 1 authNS

8

1.169% 2.126% 109% 117% 173% 4.889% 638% 1.118% 0% 1.000% 2.000% 3.000% 4.000% 5.000% 6.000% Windows(Server(2012( Unbound( BIND( Time((ms.)(

Response(>me((ms.)([1/5(altered(Authorita>ve(Name(Servers](

  • Max. ¡= ¡16,162
slide-9
SLIDE 9

SURFnet: we make innovation work

Resolver experiments (4)

  • Max. resp. size on 2 authNS

9

3.295& 1.036& 1.408& 290& 99& 126& 1.756& 513& 651& 0& 500& 1.000& 1.500& 2.000& 2.500& 3.000& 3.500& Windows(Server(2012( Unbound( BIND( Time((ms.)(

Response(>me((ms.)([2/5(altered(Authorita>ve(Name(Servers](

Time x1.5 Time x2 Time x10

slide-10
SLIDE 10

SURFnet: we make innovation work

Experiment on live authNS

10

Traffic (IPv4 + IPv6) Normal Operations

  • Max. response

size 1232 bytes Fragmented responses 28.9% 0.0%* Fragment receiving resolvers 57.3% 0.0%* Truncated UDP responses 0.8% 0.9% ICMP FRTE messages 5649/h < 1/h* ICMP FRTE sending resolvers 1.3% 0.0%* Total retries 25.8% 25.5% *Statistically significant difference between experiments

slide-11
SLIDE 11

SURFnet: we make innovation work

Rise in truncated answers

  • Experiment:

– Querying 995 zones in .com, .edu, .mil, .net and .nl – All zones are signed and have a www-node – Results:

– 30% truncations were expected for a maximum response size of 1232 bytes by Rikitake, K., Nogawa, H., Tanaka, T., Nakao, K. and Shimojo, S. “An Analysis of DNSSEC Transport Overhead Increase”, IPSJ SIG Technical Reports 2005-CSEC-28, Vol. 2005, No. 33,

  • pp. 345-350, ISSN 0919-6072, 2005

11

  • Max. response

A for www AAAA for www DNSKEY 4096 0.0% 0.0% 0.0% 1472 1.8% 1.8% 8.1% 1232 2.9% 3.5% 40.0%

slide-12
SLIDE 12

SURFnet: we make innovation work

How to move forward?

  • Working on a recommendation in the RIPE DNS

working group (http:/ /bit.ly/ripe-draft-frag)

  • Make sure your resolver(s)

set the maximum response size to something that actually works! Learn how: http:/ /bit.ly/sn-dnssec-vali

12

slide-13
SLIDE 13

nl.linkedin.com/in/rolandvanrijswijk @reseauxsansfil roland.vanrijswijk@surfnet.nl

Questions? Remarks? Read our blog: https:/ /dnssec.surfnet.nl/