Stephane Bortzmeyer arbeitet für AFNIC (Domain Name registriert in Frankreich) und kennt sich mit DNS aus. Er ist Teilnehmer von IETF, und hat zwei RFC geschrieben (über DNS privatssphäre). Er überwacht seine Maschinen mit Icinga auf einem Rasberry Pi, und ist ein großer Fan von RIPE Atlas (weitere Artikel unter labs.ripe.net)

1. DNS monitoring from
several vantage points
Stéphane Bortzmeyer
bortzmeyer@nic.fr
1 / 17

2. 2 / 17

3. Small reminder on DNS
3 / 17

4. Small reminder on DNS
Distributed and decentralized database
3 / 17

5. Small reminder on DNS
Distributed and decentralized database
Maps domain names to various data
3 / 17

6. Small reminder on DNS
Distributed and decentralized database
Maps domain names to various data
Crucial infrastructure (remember the Dyn attack on 21
october?)
3 / 17

7. Small reminder on DNS
Distributed and decentralized database
Maps domain names to various data
Crucial infrastructure
”Loosely consistent”. Data may be temporarily different.
3 / 17

8. Small reminder on DNS
Distributed and decentralized database
Maps domain names to various data
Crucial infrastructure
”Loosely consistent”
Two kinds of servers: resolvers and authoritative
3 / 17

9. Monitoring with dig or check_dig
4 / 17

10. Monitoring with dig or check_dig
You can test the DNS with a client like dig (or drill, or
kdig. . . )
4 / 17

11. Monitoring with dig or check_dig
You can test the DNS with a client like dig
You can use the monitoring plugin check_dig
4 / 17

12. Monitoring with dig or check_dig
You can test the DNS with a client like dig
You can use the monitoring plugin check_dig
Both give you only the local view. The rest of the world may
see it differently!
4 / 17

13. Why we need several vantage points
Because permanent, stable, results depend on where you are
5 / 17

14. Why we need several vantage points
Because permanent, stable, results depend on where you are
Geolocation
5 / 17

15. Why we need several vantage points
Because permanent, stable, results depend on where you are
Geolocation
Routing problems (16 november, Orange resolvers down in
France, could not reach the outside)
5 / 17

16. Why we need several vantage points
Because permanent, stable, results depend on where you are
Geolocation
Routing problems
Censorship (lying resolvers)
5 / 17

17. Why we need several vantage points
Because permanent, stable, results depend on where you are
Geolocation
Routing problems
Censorship (lying resolvers)
Unsynchronized name servers
5 / 17

18. Why we need several vantage points
Because permanent, stable, results depend on where you are
Geolocation
Routing problems
Censorship (lying resolvers)
Unsynchronized name servers
Cache poisoning (if you are too lazy to use DNSSEC)
5 / 17

19. A funny case: censorship glitch
6 / 17

20. A funny case: censorship glitch
In France, mandatory blocking of “terrorist” domains, without
oversight by a judge
6 / 17

21. A funny case: censorship glitch
In France, mandatory blocking of “terrorist” domains
The police sends the list to the ISPs, they install it in their
resolvers
6 / 17

22. A funny case: censorship glitch
In France, mandatory blocking of “terrorist” domains
The police sends the list to the ISPs
17 october 2016: Orange installs a wrong list, redirecting
Google and Wikipedia to the police Web site
6 / 17

23. Solutions for distributed DNS monitoring
The most obvious one is to buy/rent servers around the world
Expensive, doesn’t scale
7 / 17

24. Open resolvers
8 / 17

25. Open resolvers
An open resolver is a resolver accepting requests from anyone
8 / 17

26. Open resolvers
An open resolver is a resolver accepting requests from anyone
At a time, that was the rule
8 / 17

27. Open resolvers
An open resolver is a resolver accepting requests from anyone
At a time, that was the rule
Now frowned upon, because of reflection attacks (RFC 5358)
8 / 17

28. Open resolvers
An open resolver is a resolver accepting requests from anyone
At a time, that was the rule
Now frowned upon, because of reflection attacks
Typically unmanaged and orphan machines
8 / 17

29. Open resolvers
An open resolver is a resolver accepting requests from anyone
At a time, that was the rule
Now frowned upon, because of reflection attacks
Typically unmanaged and orphan machines
Millions of them. Often used for scientific papers and
operational debugging as well
8 / 17

30. Open resolvers
An open resolver is a resolver accepting requests from anyone
At a time, that was the rule
Now frowned upon, because of reflection attacks
Typically unmanaged and orphan machines
Millions of them
Pros: you can use regular DNS to query them. Many servers.
Lists exist http://public-dns.info/nameservers.txt
Tools exist (dnsyo https://github.com/YoSmudge/dnsyo)
8 / 17

31. Open resolvers
An open resolver is a resolver accepting requests from anyone
At a time, that was the rule
Now frowned upon, because of reflection attacks
Typically unmanaged and orphan machines
Millions of them
Pros: you can use regular DNS to query them. Many servers.
Lists exist Tools exist
Cons: unstable, the list always change. No metadata attached
so you cannot select a subset on the criteria you dream on.
Not good when you want to test “regular” resolvers.
Questionable legality and morality.
8 / 17

32. Public resolvers
9 / 17

33. Public resolvers
Unlike the open resolvers, the public resolvers know what
they do: they are deliberately open
9 / 17

34. Public resolvers
Unlike the open resolvers, the public resolvers know what
they do
Rate-limiting, professional supervision. . .
9 / 17

35. Public resolvers
Unlike the open resolvers, the public resolvers know what
they do
Rate-limiting, professional supervision. . .
Google Public DNS, Yandex DNS, Verisign Public DNS, Cisco
OpenDNS. . .
9 / 17

36. Public resolvers
Unlike the open resolvers, the public resolvers know what
they do
Rate-limiting, professional supervision. . .
Google Public DNS, Yandex DNS. . .
Pros: always on and available, you can use regular DNS to
query them, no legal or moral issue.
9 / 17

37. Public resolvers
Unlike the open resolvers, the public resolvers know what
they do
Rate-limiting, professional supervision. . .
Google Public DNS, Yandex DNS. . .
Pros: always on and available, you can use regular DNS to
query them, no legal or moral issue.
Cons: not always present where you need them. Not good
when you want to test “regular” resolvers. Can be blocked or
hijacked (Google DNS in Turkey)
9 / 17

38. DNS looking glasses
10 / 17

39. DNS looking glasses
Inspired by the BGP looking glasses
10 / 17

40. DNS looking glasses
Inspired by the BGP looking glasses
Services you can query from any place. Not a resolver, a
simple proxy
10 / 17

41. DNS looking glasses
Inspired by the BGP looking glasses
Services you can query from any place. Not a resolver, a
simple proxy
Typically Web-based and/or REST with structured output
10 / 17

42. DNS looking glasses
Inspired by the BGP looking glasses
Services you can query from any place. Not a resolver, a
simple proxy
Typically Web-based and/or REST with structured output
Pros: when using the Web, make DNS accessible for normal
users. When using REST, make DNS accessible for normal
programmers (those who do JavaScript and not C). Source
code to install your own
https://github.com/bortzmeyer/dns-lg
http://www.dns-lg.com/
10 / 17

43. DNS looking glasses
Inspired by the BGP looking glasses
Services you can query from any place. Not a resolver, a
simple proxy
Typically Web-based and/or REST with structured output
Pros: when using the Web, make DNS accessible for normal
users. When using REST, make DNS accessible for normal
programmers.
Cons: no comprehensive and up-to-date list. Not always
present where you need them. Do not use DNS, but
non-standard REST protocols. Not yet successful attempts at
IETF to standardize output formats draft-bortzmeyer-dns-json
draft-hoffman-dns-in-json
10 / 17

44. DNS looking glass with Web
11 / 17

45. DNS looking glass with REST + JSON
% curl -q http://dns.bortzmeyer.org/netways.de/NS?format=json
{
...
"AnswerSection": [
{
"Name": "netways.de.",
"Type": "NS",
"Target": "ns1.netways.de.",
"TTL": 4270
},
...
],
"ReturnCode": "NOERROR",
"QuestionSection": {
"Qclass": "IN",
"Qtype": "NS",
"Qname": "netways.de."
}
} 12 / 17

46. The ring
13 / 17

47. The ring
A “ring” of servers maintained by network operators
https://ring.nlnog.net/
13 / 17

48. The ring
A “ring” of servers maintained by network operators
https://ring.nlnog.net/
You can submit requests through SSH to all the other servers
(ring-all dig +short -t SOA ring.nlnog.net)
13 / 17

49. The ring
A “ring” of servers maintained by network operators
https://ring.nlnog.net/
You can submit requests through SSH to all the other servers
Pros: Full servers, lot of programs available.
13 / 17

50. The ring
A “ring” of servers maintained by network operators
https://ring.nlnog.net/
You can submit requests through SSH to all the other servers
Pros: Full servers, lot of programs available.
Cons: No public access
13 / 17

51. Atlas probes
14 / 17

52. Atlas probes
Small hardware probes installed by volunteers on their
networks and managed by the RIPE-NCC.
14 / 17

53. Atlas probes
Small hardware probes installed by volunteers on their
networks and managed by the RIPE-NCC.
Perform active measurements, for instance with DNS
14 / 17

54. Atlas probes
Small hardware probes installed by volunteers on their
networks and managed by the RIPE-NCC.
Perform active measurements, for instance with DNS
API to start measurements, select probes
14 / 17

55. Atlas probes
Small hardware probes installed by volunteers on their
networks and managed by the RIPE-NCC.
Perform active measurements, for instance with DNS
API to start measurements, select probes
Pros: 10 000 probes, in many places in the world. Great API.
Stable and reliable service. For DNS, a lot of options available.
14 / 17

56. Atlas probes
Small hardware probes installed by volunteers on their
networks and managed by the RIPE-NCC.
Perform active measurements, for instance with DNS
API to start measurements, select probes
Pros: 10 000 probes, in many places in the world. Great API.
Stable and reliable service. For DNS, a lot of options available.
Cons: Unequal distribution. Some limitations (no DNS
requests without the RD bit). Require “credits” (obtained
from the RIPE-NCC)
14 / 17

57. Atlas tests
% atlas-resolve --requested 10 --type AAAA www.afnic.fr
[2001:67c:2218:30::24] : 10 occurrences
Test #6939593 done at 2016-11-24T10:53:01Z
% atlas-resolve --requested 20 --country FR www.thepiratebay.se
[ERROR: SERVFAIL] : 4 occurrences
[104.31.18.30 104.31.19.30] : 10 occurrences
[ERROR: NXDOMAIN] : 2 occurrences
[127.0.0.1] : 3 occurrences
Test #6939617 done at 2016-11-24T11:22:49Z
15 / 17

58. Issues
16 / 17

59. Issues
If you send a request with the RD (Recursion Desired) bit,
you fill the cache. If there is a problem/hijacking going on,
you “poison” the cache
16 / 17

60. Issues
If you send a request with the RD bit, you fill the cache. If
there is a problem/hijacking going on, you “poison” the cache
Lack of standards, specially for the looking glasses
16 / 17

61. Issues
If you send a request with the RD bit, you fill the cache. If
there is a problem/hijacking going on, you “poison” the cache
Lack of standards, specially for the looking glasses
Lack of “authoritative” lists of public resolvers / looking
glasses
16 / 17

62. Call to the people
You can help
Please set up looking glasses, RIPE Atlas probes and similar tools
17 / 17

63. www.afnic.fr
contact@afnic.fr
Merci !