O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Dns

DNS

  • Entre para ver os comentários

Dns

  1. 1. Introduction to DNS Naming network items
  2. 2. Hi  Julien PAULI  Programming in PHP since early 2000s  PHP Internals hacker and trainer  PHP 5.5/5.6 Release Manager  Working at SensioLabs in Paris - Blackfire  Writing PHP tech articles and books  http://phpinternalsbook.com  http://blog.jpauli.tech  @julienpauli - github.com/jpauli - jpauli@php.net  Like working on OSS such as PHP :-)
  3. 3. TOC  History of Internet and networks  The need to name things  The need to create a synchronized decentralized system  Domain Name Server  A hierarchical system  Names and zones  Practicing DNS with BIND  Zones creations and delegation  Zones master and slave propagation
  4. 4. State Of The Art  Each machine on a network is assigned an IP address  IPV4 : 32 bits  IPV6 : 128 bits  Computers are fast at treating numbers  Human brains are crap at treating and memorizing numbers  But human brains are good at memorizing names (letters)  There is a need of a global system which goal would be association of human-memorizable mnemonics (names) and computer assigned address numbers
  5. 5. Usage of a centralized file  In 1970, ARPANET only handles hundreds of hosts  ARPANET == Internet ancestor  Among those, one machine were hosting a file : HOSTS.TXT , associating every network machine names with their addresses  HOSTS.TXT were then copied/synchronized in each local machine's /etc/hosts file, which is used as the local UNIX hosts db  When HOSTS.TXT were modified, admins sent emails to each machine to have their user download the new HOSTS.TXT and update their own /etc/hosts
  6. 6. Problems showing  ARPANET grows, more and more hosts  Having one single HOSTS.TXT file to both update and transfer to everyone starts to be a pain.  That becomes unmaintainable  ARPANET searches for a system to replace HOSTS.TXT drawbacks  In 1984, the DNS first RFC were written
  7. 7. DNS  A distributed name database  Name servers contain a segment of the whole name database  Clients, called resolvers, can query servers  Some caches are setup to improve overall performances
  8. 8. DNS Structure  DNS has been structured like UNIX Filesystem  A reversed tree where root node is on top root node domain subdomain
  9. 9. A domain name  A domain name is the equivalent of an absolute path  But it is read in the reverse way  And it uses a dot as a separator and not a slash Reading the FS Reading the DNS
  10. 10. DNS decentralization  Each subdomain may be managed by a different entity, this is called a delegation ICANN NSI BSD University Local FS Remote NFS
  11. 11. DNS overview  This system solves the HOSTS.TXT problems  No more duplicate entry  Each domain name is unique  And can be administrated by a unique entity  Each zone can contain  Host names  Sub domains  The system is  distributed  redundant  delegated (no centralization)
  12. 12. DNS tree  The namespace may reach 127 deepness levels  Each tree name can be up to 63 chars  Separator is dot " . "  Root node has the null name ""
  13. 13. DNS structure  A domain is simply a subtree of the namespace  Each subtree node is owned by its parent  Hence, pa.ca.us is child of ca.us and of us us domain pa.ca.us node ca.us domain Top Level Domain Level one domain Level two domain Root
  14. 14. Zone and domain  A zone contains records and delegation informations about a name  A domain contains the merge of all its zones informations
  15. 15. Zone delegation  Zone delegation allows a domain administrator to delegate any information about a zone to someone else  Each zone can be seen as an AS
  16. 16. DNS ? Competitors ?  If you connect to Internet  DNS is a must-have  If you got your own internet network, based on TCP/IP (network of networks)  DNS can be used  If you got your own local network  DNS is an option  Competitors exists, like WINS or NIS  If you need distributed management and face consistency issues, DNS could be your solution
  17. 17. Resource Records (RR)  RR are DNS data (what is stored is called a "resource record")  Divided in classes : we'll use the TCP/IP Internet class mainly (IN)  Classes are divided by types  https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml  Most commonly used types are :  A : an IPV4 Address  AAAA : an IPV6 address  NS : A name server  SOA : A Start Of Authority  PTR : A reverse-DNS entry  MX : A mail server entry  TXT : Some textual information  Location : Geo Data  SRV : Service discovery (http, ftp, ldap ... offered by a domain)
  18. 18. Resource Records (RR)  Nowadays, there exists many RR  Postcodes can be stored in DNS ;-)  User/pass can be stored in DNS (ldap alternative)  DNS is a database, it is possible to add new "fields" , infinitely  DNS is expansible, and is updated to follow the overall Internet mutations through time  Big companies may hide opportunities in DNS entries ;-)
  19. 19. DNS clients and servers  Clients are called resolvers  Servers  May be authoritative on a zone  May be non-authoritative on a zone  May also be themselves clients  Authoritative servers must be at least two per zone  We usually call both the "master" and the "slave", but they both are authoritative on a zone  The "master" can update the zone infos, whereas the slaves can only copy it from the master (or another slave) and can't edit it.
  20. 20. Resolving names  A resolver is silly, and needs a server  A server can resolve a name  Resolving a name, is searching for an answer  "What is the IPV4 of foo.bar ?"  "foo.bar is at 10.5.49.6"  Each server is only authoritative for the zone its been setup for  Each server only knows a small piece of names from the whole namespace
  21. 21. Root servers  Root servers know every server of the upper level  spreaded worldwide  critical hardware for the overall Internet life  AnyCast routed
  22. 22. Resolving from root servers  Root servers know every server of the upper level  Every upper server  knows the answer if no delegation is performed  (The answer can be an error, like "no such domain")  OR  knows the upper server of the upper name if the zone is delegated  So a server whether  Knows your answer  OR  Knows who can know it  ...this, recursively
  23. 23. DNS resolution example  let's resolve foo.bar.baz.com
  24. 24. Here is the DNS local server foo.bar.baz.com ?? foo.bar.baz ?? foo.bar ?? com zone server infos baz zone server infos foo.bar.baz.com?? Root server com server bar zone server infos foo ?? foo is at 1.2.3.4 baz server bar server 1 2 4 3 foo bar baz com . . . . 1.2.3.4
  25. 25. Resolving a name  A recursive server will attempt to find the answer on its own. It follows server informations until it finds  A non-recursive server only gives answer to its zone information, and does not try to resolve anything by contacting anyone else
  26. 26. Recursive VS Iterative queries local server foo.bar.baz.com ?? foo.bar.baz ?? foo.bar ?? com zone server infos baz zone server infos foo.bar.baz.com?? Root server com server bar zone server infos foo ?? foo is at 1.2.3.4 baz server bar server foo bar baz com . . . . 1.2.3.4 IterativeRecursive
  27. 27. Resolver - server - recursion  A resolver always issues recursive queries, it has zero intelligence  A server usually issues non-recursive, aka iterative queries.  Iterative answers give a new server name  Recursive queries involve more work on the server DNS Server DNS Server DNS Server DNS Server Iterative Recursive Company A
  28. 28. Recursion in DNS  If a server receives a recursive query , it must answer it fully  If it does not have authority on the zone, it must then ask another server. If needed, it will ask from the root server  If a server receives a recursive query, it politely will issue iterative queries on its side, until forwarding DNS Server DNS Server DNS Server DNS Server Iterative Recursive Company A
  29. 29. DNS resolution DNS Server DNS Server DNS Server DNS Server Iterative Recursive Company A
  30. 30. DNS forward DNS Server DNS Server DNS Server DNS Server Iterative Recursive Company A DNS Server forwarding
  31. 31. Practice
  32. 32. Let's practice it :-)  A registrar is a company that interface with a registry  A registry is the one company that takes care of one TLD  Common TLD : com, net, org, fr, us, uk .. .. ...  Registry is the big-seller  Registrar is the detail-reseller  Registrar takes customers domain booking, and records them to the registry  It records the delegation servers for the new zone, there should be two of them
  33. 33. Find a registrar, and register  ghandi, ovh , godaddy, etc...  Buy your domain : foo.bar.  Here, the registrar will register (haha), your nameservers for the foo.bar. zone, against the TLD registry for .bar.  This registration can take time, but it is usually fast .bar zone.bar registry registrar Ans1 ns2 registrar B registrar C ns1/ns2 ns1/ns2 ns1/ns2
  34. 34. Domain Registration == delegation  TLD only delegates, TLD never registers hosts  You delegate foo into the bar. zone  That is you declare your servers (2 minimum) to the bar. zone  Each future resolution in bar., about foo.bar., will answer your servers : .bar. delegates to you foo.bar. management  Now you can register names : aka "baz.foo.bar."  Or you can delegate full zones, like *.wow.foo.bar." .bar zone.bar registry registrar Ans1 ns2 registrar B registrar C ns1/ns2ns1/ns2ns1/ns2
  35. 35. Done ! .bar zone.bar registry registrar Ans1 ns2 registrar B registrar C wow.foo.bar ? DNS server .bar zone wow.foo.bar ? ns1.foo.bar is here ns1 ns2 wow.foo.bar ? 10.5.88.3 .foo.bar zone 10.5.88.3
  36. 36. Tools and practice
  37. 37. DNS Tools  BIND is the defacto DNS server under Unix  https://www.isc.org  DIG is the defacto DNS debugger under Unix  nslookup is old, and nowadays unmaintained, use dig  libc is the defacto DNS resolver under Unix  <resolv.h> and the well known gethostbyname()/getaddrinfo()  It makes use of the /etc/resolv.conf file to find DNS servers to query  https://www.zonemaster.net - http://dnsviz.net  DNS brute force tools : dnsrecon / subbrute  DNS helpers : dnstop / dnswalk
  38. 38. A real example
  39. 39. A real example  I'm linked at home with other peers through private VPN  jp : me  uf : Ulysse  Instead of learning each other network's IP addresses, we managed to setup 2 delegations  jp.vpn : delegated to jp, slave uf  uf.vpn : delegated to uf , salves jp  The TLD .vpn is publicly unused (but the contrary wouldn't hurt much)
  40. 40. Setup uf jp Internet VPN
  41. 41. jp Internet VPN VPN srv.jp.vpn JP
  42. 42. JP example  I need a recursive server  Because I want to use it as my DNS server, for my home network  I need to have it safe from the Internet  I need to be authoritative on jp.vpn. , this is my zone  I thus need to declare a zone file in BIND  I need to sync, as a slave, zones from uf.vpn.  I will then be able to access my peers machines by resolving their names localy  I also need to allow transfer of my jp.vpn. zone to my peer, so that he will be able to query my hosts localy and serve as replicates
  43. 43. Put some BIND config options { directory "/var/cache/bind"; version "Guess"; recursion yes; allow-transfer { none; }; dnssec-validation auto; allow-query { "private"; }; notify yes; auth-nxdomain no; # conform to RFC1035 listen-on { any; }; }; zone "jp.vpn" { type master; allow-transfer { "private"; }; allow-query { "private"; }; file "/etc/bind/zones/db.vpn"; forwarders {}; }; zone "." { type hint; file "/etc/bind/db.root"; };
  44. 44. db.jp.vpn configuration $TTL 604800 $ORIGIN jp.vpn. @ IN SOA srv admin.srv ( 3 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS srv srv IN A 192.168.0.1 gaming IN A 192.168.0.4 nas IN A 192.168.0.2 mkt IN A 192.168.0.254 obs IN CNAME srv stat IN CNAME srv nd IN CNAME srv
  45. 45. BIND documentation ?  Every information about BIND and the DNS is here : http://www.zytrax.com/books/dns/
  46. 46. Zone configuration detailed  $TTL gives the default TTL of any entry that does not overwrite it (common use-case)  $ORIGIN is the delegated zone. Every '@' refers to it , every name not ended by a point "." will refer to $ORIGIN  A fully qualified name must end with a point  This is a pretty common mistake done in bind configuration $TTL 604800 $ORIGIN jp.vpn.
  47. 47. Zone configuration detailed  owner-name ttl class rr name-server email $TTL 604800 $ORIGIN jp.vpn. @ IN SOA srv admin.srv (
  48. 48. Zone configuration detailed  "jp.vpn. with TTL 604800 of class INternet has an SOA (Start Of Authority) delegated by srv.jp.ovpn. and managed by admin@srv.jp.vpn."  In email address of zone contact, '@' is replaced by a dot  That's the way of doing things !  A SOA resource record is mandatory ! You declare yourself as being authoritative on a dedicated zone $TTL 604800 $ORIGIN jp.vpn. @ IN SOA srv admin.srv (
  49. 49. Zone configuration detailed  It's serial number is 3 (used for slave sync)  slaves should try to refresh the zone every 604800s  If slaves fail to contact master, they should retry after 86400s  The zone expires after 2419200s , slaves should stop responding after this time if they did not refresh from master  If a negative answer is given its cache is 604800s $TTL 604800 $ORIGIN jp.vpn. @ IN SOA srv admin.srv (3 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL
  50. 50. Zone configuration detailed  @ replaces the $ORIGIN  jp.vpn. is managed by the srv.jp.vpn. name server  srv.jp.vpn. is at 192.168.0.1  obs.jp.vpn. is an alias of srv.jp.vpn. and will have IP 192.168.0. ... ... @ IN NS srv srv IN A 192.168.0.1 obs IN CNAME srv
  51. 51. Slave zones zone "uf.vpn" { type slave; allow-query { "private"; }; masters { 10.1.2.1; }; forwarders {}; };
  52. 52. Let's dig it dig foo.jp.vpn @192.168.0.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> foo.jp.vpn @192.168.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64753 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;foo.jp.vpn. IN A ;; AUTHORITY SECTION: jp.vpn. 604800 IN SOA srv.jp.vpn. admin.srv.jp.vpn. 3 604800 86400 2419200 604800 ;; Query time: 11 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Oct 05 16:38:12 CEST 2017 ;; MSG SIZE rcvd: 86
  53. 53. DIG flags and answer details  qr : always here, means "answer"  aa : authoritative answer  rd : recursivity demanded  ra : recursive answer  status : NXDOMAIN == "no such domain" == "foo.jp.vpn doesn't exist" dig foo.jp.vpn @192.168.0.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> foo.jp.vpn @192.168.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64753 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
  54. 54. Authoritative ? dig foo.jp.vpn @192.168.0.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> foo.jp.vpn @192.168.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64753 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 dig dl.free.fr @192.168.0.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> dl.free.fr @192.168.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32392 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 3
  55. 55. Recursive ?  By asking an iterative query on a non-authority server, this one will NOT recursively resolve.  It will answer what it can : the next NS found dig dl.free.fr @192.168.0.1 +norecurse ; <<>> DiG 9.10.3-P4-Ubuntu <<>> dl.free.fr @192.168.0.1 +norecurse ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24422 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; AUTHORITY SECTION: free.fr. 85526 IN NS freens2-g20.free.fr. free.fr. 85526 IN NS freens1-g20.free.fr.
  56. 56. Recursive ?  Now recursive : we got our answer dig dl.free.fr @192.168.0.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> dl.free.fr @192.168.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24422 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; AUTHORITY SECTION: free.fr. 85526 IN NS freens2-g20.free.fr. free.fr. 85526 IN NS freens1-g20.free.fr. ;; ANSWER SECTION: dl.free.fr. 85763 IN A 212.27.63.45 dl.free.fr. 85763 IN A 212.27.63.32
  57. 57. Let's ask for a trace  Let's trace all the resolution process dig dl.free.fr @192.168.0.1 +trace . 261197 IN NS g.root-servers.net. . 261197 IN NS e.root-servers.net. ;; Received 525 bytes from 192.168.0.1#53(192.168.0.1) in 40 ms fr. 172800 IN NS e.ext.nic.fr. fr. 172800 IN NS d.nic.fr. ;; Received 730 bytes from 192.112.36.4#53(g.root-servers.net) in 36 ms free.fr. 172800 IN NS freens2-g20.free.fr. free.fr. 172800 IN NS freens1-g20.free.fr. ;; Received 614 bytes from 192.5.4.2#53(d.ext.nic.fr) in 51 ms dl.free.fr. 86400 IN A 212.27.63.35 dl.free.fr. 86400 IN A 212.27.63.32
  58. 58. DNS caches  Each zone answer is cached.  The first DNS query for dl.free.fr will go to the root  Root gives .fr server address  The server then now memorize .fr server address and will reuse it for any further .fr resolution  Thus, the root server will NOT be queried again for any .fr further query  etc .... , recursively
  59. 59. DNS resolution caching  As a tree, the DNS resolution mechanism can cache the closest branch information and reuse it  Example : you ask for baz.foo.bar.com  If you asked before for hello.wow.bar.com  Your DNS server will start resolution from the bar.com NS zone  If you asked before for wow.foo.bar.com  Your DNS server will start resolution from foo.bar.com NS zone  If you asked before for hello.com  Your DNS server will start resolution from com NS zone
  60. 60. Dumping / flushing cache  Generating and dumping the cache  Flushing cache > rndc dumpdb -cache > cat /var/cache/bind/named_dump.db > rndc flush && rndc reload
  61. 61. Multiple records and perfs  Often, DNS is used as a basic Round Robin load balancer dig dl.free.fr @192.168.0.1 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> dl.free.fr @192.168.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24422 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; ANSWER SECTION: dl.free.fr. 85763 IN A 212.27.63.45 dl.free.fr. 85763 IN A 212.27.63.32
  62. 62. Multiple records and perfs  For iterative resolution, measures are performed by the server to ask the best responsive server among the full list dig dl.free.fr @192.168.0.1 +trace . 513067 IN NS i.root-servers.net. . 513067 IN NS m.root-servers.net. . 513067 IN NS h.root-servers.net. . 513067 IN NS a.root-servers.net. . 513067 IN NS b.root-servers.net. . 513067 IN NS f.root-servers.net. . 513067 IN NS c.root-servers.net. . 513067 IN NS d.root-servers.net. . 513067 IN NS g.root-servers.net. . 513067 IN NS j.root-servers.net. . 513067 IN NS l.root-servers.net. . 513067 IN NS k.root-servers.net.
  63. 63. Conclusions
  64. 64. Then ?  DNS is not very hard as soon as you understand its structure, and why it's been designed  Take however care about security  DNS has not been designed when security issues were in minds  Thus, vanilla DNS is pretty unsecure  No validation of hosts, of answers, no limits, no encryption, etc...  DNSSEC tries to answer some problems (also DNS over TLS)  Some other tools as well (BIND RPZ)  Don't jump into DNS without clearly knowing security risks  Do not open a recursive server to the world, it will be used as an attack vector in worldwide DNS attacks
  65. 65. Then ?  Try to start by setting up your own recursive server  Read bind doc ! http://www.zytrax.com/books/dns/  Trust it more than any server you used to use before  Your ISP server can lie, and can record any query you pass  Privacy of your information ?  Using your own recursive server is like keeping your day-to-day surf for yourself  Say bye bye to 8.8.8.8, 1.1.1.1 or 9.9.9.9 : DIY  Internet is decentralized, don't centralize it if you can prevent that
  66. 66. And after ?  After you can experiment managing your own zone and delegations  You buy a domain, and you fully manage it  Instead of letting it done by your registrar
  67. 67. Ha , and to sum things up  https://www.youtube.com/watch?v=oN7ripK5uGM
  68. 68. Thank you for listening !

×