Measuring Query Latency of Top Level DNS Servers Jinjin Liang 1 , - - PowerPoint PPT Presentation

▶
measuring query latency of top level dns servers
SMART_READER_LITE
LIVE PREVIEW

Measuring Query Latency of Top Level DNS Servers Jinjin Liang 1 , - - PowerPoint PPT Presentation

Dec 31, 2022 843 likes •1.28k views

Measuring Query Latency of Top Level DNS Servers Jinjin Liang 1 , Jian Jiang 1 , Haixin Duan 1 , Kang Li 2 and Jianping Wu 1 Tsinghua University, China 1 University of Georgia 2 PAM 2013 DNS Overview Domain Name System Translate domain

slide-1
SLIDE 1

Measuring Query Latency

  • f Top Level DNS Servers

Jinjin Liang1, Jian Jiang1, Haixin Duan1, Kang Li2 and Jianping Wu1

Tsinghua University, China1 University of Georgia2

PAM 2013

slide-2
SLIDE 2

DNS Overview

  • Domain Name System

–Translate domain names to IP addresses –Initial step for most Internet applications

  • Top Level Zones

–Start points of resolutions –Even with local cache

ROOT COM ORG GOOGLE.COM IANA.ORG

slide-3
SLIDE 3

Replication: State of the art

  • Root Zone

–Zone Replications

  • 13 Roots (A~M)
  • Uneven QoS
slide-4
SLIDE 4

Replication: State of the art

  • Root Zone

–Zone Replications

  • 13 Roots (A~M)
  • Uneven QoS

–Anycast

  • 319 instances
  • All over the world
slide-5
SLIDE 5

Replication: State of the art

  • Root Zone

–Zone Replications

  • 13 Roots (A~M)
  • Uneven QoS

–Anycast

  • 319 instances
  • All over the world
slide-6
SLIDE 6

What to measure

  • What is the actual effect of replications?

–Efficient enough? –Uneven QoS improved?

  • We need a technical survey all around the

world

slide-7
SLIDE 7

How to measure : using resolvers

User Resolver Name Server

slide-8
SLIDE 8

How to measure : using resolvers

User

Non-Recursive Query

Resolver Name Server

slide-9
SLIDE 9

How to measure : using resolvers

User

Non-Recursive Query Recursive Query

Resolver Name Server

slide-10
SLIDE 10

How to measure : using resolvers

User

Non-Recursive Query Recursive Query

Resolver Name Server

slide-11
SLIDE 11

How to measure : using resolvers

  • Advantage

– No need for direct control of vantage points, thus easy to scale up

User

Non-Recursive Query Recursive Query

Resolver Name Server

slide-12
SLIDE 12

Method: Collecting Open Resolvers

  • 19593 open resolvers

– Query log from an authority name server (42%) – Authority servers of Alexa top 1M sites (42%) – Help from other researchers (16%) – Exclude forwarders

slide-13
SLIDE 13

Method: NXDOMAIN-Query

  • Force a resolver to stop at a specific domain level

– www.{NXDOMAIN}: latency to root – www.{NXDOMAIN}.com : latency to .com TLD

  • Don’t forget to cache .com name server first

ROOT COM ORG GOOGLE.COM IANA.ORG Recursive Resolver User/Stub Resolver

slide-14
SLIDE 14

Method: NXDOMAIN-Query

  • Force a resolver to stop at a specific domain level

– www.{NXDOMAIN}: latency to root – www.{NXDOMAIN}.com : latency to .com TLD

  • Don’t forget to cache .com name server first

ROOT COM ORG GOOGLE.COM IANA.ORG Recursive Resolver

www.{NXDOMAIN} ?

User/Stub Resolver www.{NXDOMAIN} ?

slide-15
SLIDE 15

Method: NXDOMAIN-Query

  • Force a resolver to stop at a specific domain level

– www.{NXDOMAIN}: latency to root – www.{NXDOMAIN}.com : latency to .com TLD

  • Don’t forget to cache .com name server first

ROOT COM ORG GOOGLE.COM IANA.ORG Recursive Resolver

www.{NXDOMAIN} ? NXDOMAIN Response

User/Stub Resolver www.{NXDOMAIN} ? NXDOMAIN Response

slide-16
SLIDE 16

Method: NXDOMAIN-Query

  • Force a resolver to stop at a specific domain level

– www.{NXDOMAIN}: latency to root – www.{NXDOMAIN}.com : latency to .com TLD

  • Don’t forget to cache .com name server first
  • Advantage && Limitation

– Not affected by the cache – Observe latency to a domain rather than a specific server

ROOT COM ORG GOOGLE.COM IANA.ORG Recursive Resolver

www.{NXDOMAIN} ? NXDOMAIN Response

User/Stub Resolver www.{NXDOMAIN} ? NXDOMAIN Response

slide-17
SLIDE 17

Method: The King Technique

  • Measure latency from a resolver to a specific server

– Require a controllable domain – Trick resolver to visit a fake name server

slide-18
SLIDE 18

Method: The King Technique

  • Measure latency from a resolver to a specific server

– Require a controllable domain – Trick resolver to visit a fake name server

User Resolver king.ccert.edu.cn 1.1.1.1

slide-19
SLIDE 19

Method: The King Technique

  • Measure latency from a resolver to a specific server

– Require a controllable domain – Trick resolver to visit a fake name server

User Resolver king.ccert.edu.cn 1.1.1.1

1 2

  • 1. NS? a-root.king.ccert.edu.cn
  • 2. Same as (1)
slide-20
SLIDE 20

Method: The King Technique

  • Measure latency from a resolver to a specific server

– Require a controllable domain – Trick resolver to visit a fake name server

User Resolver king.ccert.edu.cn 1.1.1.1

1 2 3 4

  • 1. NS? a-root.king.ccert.edu.cn
  • 2. Same as (1)
  • 3. Addr: 1.1.1.1
  • 4. Same as (3)
slide-21
SLIDE 21

Method: The King Technique

  • Measure latency from a resolver to a specific server

– Require a controllable domain – Trick resolver to visit a fake name server

User Resolver king.ccert.edu.cn 1.1.1.1

1 2 3 4 5

  • 1. NS? a-root.king.ccert.edu.cn
  • 2. Same as (1)
  • 3. Addr: 1.1.1.1
  • 4. Same as (3)
  • 5. A? test.a-root.king.ccert.edu.cn
slide-22
SLIDE 22

Method: The King Technique

  • Measure latency from a resolver to a specific server

– Require a controllable domain – Trick resolver to visit a fake name server

User Resolver king.ccert.edu.cn 1.1.1.1

1 2 3 4 5 6

  • 1. NS? a-root.king.ccert.edu.cn
  • 2. Same as (1)
  • 3. Addr: 1.1.1.1
  • 4. Same as (3)
  • 5. A? test.a-root.king.ccert.edu.cn
  • 6. Same as (5)
slide-23
SLIDE 23

Method: The King Technique

  • Measure latency from a resolver to a specific server

– Require a controllable domain – Trick resolver to visit a fake name server

User Resolver king.ccert.edu.cn 1.1.1.1

1 2 3 4 5 6 7 8

  • 1. NS? a-root.king.ccert.edu.cn
  • 2. Same as (1)
  • 3. Addr: 1.1.1.1
  • 4. Same as (3)
  • 5. A? test.a-root.king.ccert.edu.cn
  • 6. Same as (5)
  • 7. Error
  • 8. ServFail Response
slide-24
SLIDE 24

Latency of Root and TLD hierarchy

  • Using NXDOMAIN-Query; root, .com/.net, .org
  • 500 queries in two days; get median values
slide-25
SLIDE 25

Latency of Root and TLD hierarchy

  • Using NXDOMAIN-Query; root, .com/.net, .org
  • 500 queries in two days; get median values
  • Results

– root (20.26ms) – org (39.07ms) – com/net (42.64ms)

slide-26
SLIDE 26

Latency of Root and TLD hierarchy

  • Using NXDOMAIN-Query; root, .com/.net, .org
  • 500 queries in two days; get median values
  • Results

– root (20.26ms) – org (39.07ms) – com/net (42.64ms) – Large query latency?

  • Around 4, 6, 12, 18 seconds
slide-27
SLIDE 27

Latency of Root and TLD hierarchy

  • Differences among various continents

– Europe and North America (Best) – South America and Africa

  • 3 to 6 times worse

– Oceania and Asia

  • Median values
  • Quartile values
slide-28
SLIDE 28

Latency of 13 root servers

  • Using King technique
  • 300 queries in two days; get median values
slide-29
SLIDE 29

Latency of 13 root servers

  • Using King technique
  • 300 queries in two days; get median values
slide-30
SLIDE 30

Latency of 13 root servers

  • Using King technique
  • 300 queries in two days; get median values
  • Differences for roots

– Best: F, J, L ( < 200ms for continents) – Worst: B ( > 300ms except NA)

slide-31
SLIDE 31

Latency of 13 root servers

  • Using King technique
  • 300 queries in two days; get median values
  • Differences for roots

– Best: F, J, L ( < 200ms for continents) – Worst: B ( > 300ms except NA)

  • Differences for continents

– Best: Europe & North America – Poor: Africa, Oceania, South America

slide-32
SLIDE 32

Proximity of root anycast

  • What is proximity of anycast?

– Evaluate the effect of anycast – Difference between anycast address latency and the minimum unicast address latency

slide-33
SLIDE 33

Proximity of root anycast

  • What is proximity of anycast?

– Evaluate the effect of anycast – Difference between anycast address latency and the minimum unicast address latency

slide-34
SLIDE 34

Proximity of root anycast

  • What is proximity of anycast?

– Evaluate the effect of anycast – Difference between anycast address latency and the minimum unicast address latency

slide-35
SLIDE 35

Proximity of root anycast

  • What is proximity of anycast?

– Evaluate the effect of anycast – Difference between anycast address latency and the minimum unicast address latency – Tproximity=Tanycast – min(Tunicast)

slide-36
SLIDE 36

Proximity of root anycast

  • What is proximity of anycast?

– Evaluate the effect of anycast – Difference between anycast address latency and the minimum unicast address latency – Tproximity=Tanycast – min(Tunicast)

  • Use King Technique; measure F and L root
  • Repeat 200 times in 2 days; get the median values
slide-37
SLIDE 37

Proximity of root anycast

  • F root && L root

– 40% resolvers, Tproximity > 50ms

  • Due to routing policy or

hierarchical deployment

– 2%, 1% for F and L, Tproximity < -30ms

  • Errors in results, different routing

paths, missing some unicast nodes

slide-38
SLIDE 38

Proximity of root anycast

  • F root && L root

– 40% resolvers, Tproximity > 50ms

  • Due to routing policy or

hierarchical deployment

– 2%, 1% for F and L, Tproximity < -30ms

  • Errors in results, different routing

paths, missing some unicast nodes

  • L root Proximity in continents

– Best: Oceania, Europe – Worst: Asia (65%, > 50ms)

slide-39
SLIDE 39

Analyzing large latency

  • Totally 664 resolvers (3.2% of all) constantly

show large latency ( > 2s)

  • Root: 6s, 18s; com/net: 4s, 6s; org: 6s, 12s
  • Analysis methods:

– fpdns: get fingerprint of resolvers – Set up a testing domain with 3 servers to observe resolvers behavior

slide-40
SLIDE 40

The cause of large latency

  • Cause 1: buggy implementation on IPv4/IPv6

dual-stack

– Software: BIND 9.2.x – Root: 18s; com/net: 4s; org: 12s – Patch: BIND (>= 9.3)

  • Cause 2: filtering of DNSSEC response

– Software: most are BIND 9.3.x – root, com/net, org : 6 seconds

slide-41
SLIDE 41

Conclusion

  • Massive deployments of server replications

improve the overall DNS performance

  • Quality of DNS service is still uneven among

different regions

– More anycast instances? – More flexible deployment policy?

  • Pay more attention to the filtering of large DNSSEC

packets

slide-42
SLIDE 42

Thanks! Questions?