A place to cache linked articles (think custom and personal wayback machine)
Ви не можете вибрати більше 25 тем Теми мають розпочинатися з літери або цифри, можуть містити дефіси (-) і не повинні перевищувати 35 символів.

4 роки тому
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
  1. title: A warm welcome to DNS
  2. url: https://powerdns.org/hello-dns/
  3. hash_url: 32c925bdf02776ae768591623d257bcb
  4. This series of documents attempts to provide a correct introduction to the
  5. Domain Name System as of 2018. The original RFCs remain the authoritative
  6. source of normative text, but this document tries to make this venerable
  7. protocol more accessible, while maintaining full alignment with all relevant
  8. and useful RFCs.
  9. This effort is developed cooperatively on GitHub, the repository can be
  10. found [https://github.com/ahupowerdns/hello-dns/](here) and help is highly
  11. welcome! Feedback can also be sent to bert.hubert@powerdns.com or
  12. [@PowerDNS_Bert](https://twitter.com/PowerDNS_Bert).
  13. Although we start from relatively basic principles, the reader is expected
  14. to know what IP addresses are, what a (stub) resolver is and what an
  15. authoritative server is supposed to do. When in doubt: authoritative
  16. servers 'host' DNS data, 'resolvers' look up things over at authoritative
  17. servers and clients run 'stub resolvers' to look things up over at
  18. resolvers. This document is aimed at developers, but may also be of aid for
  19. administrators.
  20. DNS was originally written down in August 1979 in '[IEN
  21. 116](https://www.rfc-editor.org/ien/ien116.txt)', part of a parallel
  22. series of documents describing the Internet. IEN 116-era DNS is not
  23. compatible with today's DNS. In 1983, RFC 882 and 883 were released,
  24. describing a version of the DNS very similar but not quite interoperable
  25. with the one we have today.
  26. DNS attained its modern form in 1987 when RFC 1034 and 1035 were published.
  27. Although much of 1034/1035 remains valid, these standards are not that easy
  28. to read because they were written in a very different time. There are 100s
  29. of pages of updates that can only be found in later documents.
  30. The main goal of this effort is not to contradict the DNS RFCs but to
  31. provide an easier entrypoint into understanding the Domain Name System.
  32. If you will, the goal is to be a mini "[TCP/IP
  33. Illustrated](https://en.wikipedia.org/wiki/TCP/IP_Illustrated)" of DNS. For
  34. more about the philosophy of these documents, and how to contribute, please read
  35. [meta.md](meta.md.html).
  36. Your help & insights are highly welcome!
  37. I want to thank Ólafur Guðmundsson and Job Snijders for their input and
  38. enthusiasm for improving the state of DNS.
  39. ## Layout
  40. The content is spread out over several documents:
  41. * [The core of DNS](basic.md.html)
  42. * [Relevant to stub resolvers and applications](stub.md.html)
  43. * [Relevant to authoritative servers](auth.md.html)
  44. * [tdns: a 'from scratch' teaching authoritative server, implementing all of basic DNS in 1100 lines of code](tdns/README.md.html)
  45. * [Relevant to resolvers](resolver.md.html)
  46. * Optional elements: [EDNS, TSIG, Dynamic Updates, DNAME, DNS Cookies](optional.md.html)
  47. * [Privacy related](privacy.md.html): QName minimization, DNS-over-TLS, DNS-over-HTTPS, EDNS Padding
  48. * [DNSSEC](dnssec.md.html)
  49. * [non-IETF standards](non-ietf.md.html): RRL and RPZ
  50. * [Rare parts of DNS](rare.md.html) - not obsolete, but not frequently encountered in production
  51. We start off with a general introduction of DNS basics: what is a resource
  52. record, what is an RRSET, what is a zone, what is a zone-cut, how are packets
  53. laid out. This part is required reading for anyone ever wanting to query a
  54. nameserver or emit a valid response.
  55. We then specialize into what applications can expect when they send
  56. questions to a resolver, or what a stub-resolver can expect.
  57. The next part is about what an authoritative server is supposed to do. On
  58. top of this, we describe in slightly less detail how a resolver could
  59. operate. Finally, there is a section on optional elements like EDNS, TSIG,
  60. Dynamic Updates and DNSSEC
  61. RFCs, especially earlier ones, tend to describe servers that perform both
  62. authoritative and resolver functions. This turns out to make both code and
  63. troubleshooting harder. Therefore, in these documents, the authoritative and
  64. caching functions are described separately.
  65. Next up: [DNS Basics](basic.md.html).