Build Dynamic DNS server from scratch in C (Part1)
5 likes3,822 views
The document outlines the process of building a dynamic DNS server from scratch using C, detailing the prerequisites, project aims, and the challenges faced during development. It emphasizes the importance of understanding DNS concepts through practical implementation while referencing key RFC documentation. The author aims to create an efficient, uniform, and RFC-compliant server that enhances educational insights into DNS functionalities.
Build Dynamic DNS server from scratch in C (Part1)
- 1. Build Dynamic DNS Server from Scratch in C (Part 1) SITCON 2017
- 2. yenWu(吳彥寬) ● NCKU CSIE (Master, Now) ● NCKU Mathematics(Bachelor) ● C ● Robotic ● RTOS ● Microkernel 2
- 3. DDNS ● Project Link: https://github.com/yenWu/DDNS ● DDNS = Dynamic DNS ● In order to figure out what's DNS and how it work, I would Implement Dynamic DNS server in User-level. 3
- 4. Outline 1. Story Time 2. Introduction 3. Prerequisites 4. Aims 5. Cautions 4
- 5. Story Time 5
- 6. Story Time Project “Build your own DNS Server in FreeBSD” 6
- 7. Story Time Can I build one from scratch to be my final project? 7
- 8. Story Time Sure. But you should try more difficult one, “Dynamic DNS Server”. 8
- 9. Story Time OK. That’s better than building one. 9
- 10. Story Time OK. That’s better than building one. I took three days long to fix the lowercase bug when building AMP. 10
- 11. Lots of documents ... ● rfc1033 ● rfc1034 ● rfc1035 ● rfc2136 11
- 12. An Episode! 12
- 13. An Episode! I said that I want to build a TCP/IP Stack at first time ... 13
- 14. Build TCP/IP Stack from Scratch in C (Part 1) SITCON 2017
- 15. Most frequently asked questions and comments ● Why do you try to build from scratch? I already have BIND(FreeBSD)! ● Your project doesn’t more better than BIND. Why do you still do that? 15
- 16. Most frequently asked questions and comments ● Why do you try to build from scratch? I already have BIND(FreeBSD)! ○ Writing one is the best pratice for me to understand the concept of DNS. ● Your project doesn’t more better than BIND. Why do you still do that? 16
- 17. Most frequently asked questions and comments ● Why do you try to build from scratch? I already have BIND(FreeBSD)! ○ Writing one is the best pratice for me to understand the concept of DNS. ● Your project doesn’t more better than BIND. Why do you still do that? ○ If you have wrote one, you can have more idea to improve it. 17
- 18. Introduction 18
- 20. Internet ● The Internet maintains two principal namespaces ○ Domain name hierarchy ○ Internet Protocol (IP) address spaces 20
- 21. What is DNS server? 21
- 22. What is DNS server? 22
- 23. What is DNS server? ● Hierarchical decentralized naming system ● Distributed database ● A little similar to Phonebook ● Translate readily memorized domain name to IP address ● DNS client v.s. DNS server ● Two category of the DNS server ○ Recursive DNS server ○ Iterative DNS server 23
- 24. Hierarchy of DNS servers “www.yahoo.com” 24
- 25. Hierarchy of DNS servers “www.yahoo.com.” 25
- 26. Hierarchy of DNS servers “www.yahoo.com.” 26
- 27. Hierarchy of DNS servers “www.yahoo.com.” 27
- 28. Let’s take it deeply That’s all I knew before I started this. 28
- 29. What is DNS server? ● DNS client v.s. DNS server ○ DNS Server ⊇ { Resolver, Database, Cache} ○ DNS Client ⊇ { Resolver} ● Unlike a phonebook, DNS can be quickly updated, allowing a service's location on the network to change without affecting the end users, who continue to use the same host name. ● Responds with answers to queries against its database. ● Port 53 29
- 30. What is DNS server? ● The most common types of records ○ Start of Authority (SOA) ○ IP addresses (A and AAAA) ○ SMTP mail exchangers (MX) ○ Name servers (NS) ○ Pointers for reverse DNS lookups (PTR) ○ Domain name aliases (CNAME) ● Different reaction depend on the type of record 30
- 31. Glance 31
- 32. Resolver A Resolver maps a name to an address and vice versa. Query Response Resolver Name Server 32
- 33. Iterative Resolution client edu 2 root 3 com 4 NS: google.com 5 iterative request “What is the IP address of www.google.com?” ncku 1 iterative response “The IP address of www.google.com is 216.239.37.99.” 6 33
- 34. Iterative Resolution client edu 2 root 3 com 4 NS: google.com 5 iterative request “What is the IP address of www.google.com?” ncku 1 iterative response “The IP address of www.google.com is 216.239.37.99.” 6 Iterative Query 34
- 35. Recursive Resolution client edu 2 root 3 com 4 google 5 recursive request “What is the IP address of www.google.com?” ncku 1 recursive response “The IP address of www.google.com is 216.239.37.99.” 6 35
- 36. Recursive Resolution client edu 2 root 3 com 4 google 5 recursive request “What is the IP address of www.google.com?” ncku 1 recursive response “The IP address of www.google.com is 216.239.37.99.” 6 Recursive Query 36
- 38. ● Why hierarchy? ○ More efficient than heterarchy. ○ Update could be immediately showed. Questions 38
- 39. ● Why hierarchy? ○ More efficient than heterarchy. ○ Update could be immediately showed. ● Does it always waste a lot of time on process of lookup? Questions 39
- 40. ● Why hierarchy? ○ More efficient than heterarchy. ○ Update could be immediately showed. ● Does it always waste a lot of time on process of lookup? ○ Right! So caching! Questions 40
- 41. ● Why hierarchy? ○ More efficient than heterarchy. ○ Update could be immediately showed. ● Does it always waste a lot of time on process of lookup? ○ Right! So caching! ● Is it true that react immediately when we update the informaition(RR)? Questions 41
- 42. ● Why hierarchy? ○ More efficient than heterarchy. ○ Update could be immediately showed. ● Does it always waste a lot of time on process of lookup? ○ Right! So caching! ● Is it true that react immediately when we update the informaition(RR)? ○ Probably not … because of the cache. Questions 42
- 43. ● Why hierarchy? ○ More efficient than heterarchy. ○ Update could be immediately showed. ● Does it always waste a lot of time on process of lookup? ○ Right! So caching! ● Is it true that react immediately when we update the informaition(RR)? ○ Probably not … because of the cache. ● Is it easy to update the information(RR)? Questions 43
- 44. ● Why hierarchy? ○ More efficient than heterarchy. ○ Update could be immediately showed. ● Does it always waste a lot of time on process of lookup? ○ Right! So caching! ● Is it true that react immediately when we update the informaition(RR)? ○ Probably not … because of the cache. ● Is it easy to update the information(RR)? ○ Maybe not. In RFC 1035, we would load zone and startup file into database at local. Questions 44
- 45. ● Why hierarchy? ○ More efficient than heterarchy. ○ Update could be immediately showed. ● Does it always waste a lot of time on process of lookup? ○ Right! So caching! ● Is it true that react immediately when we update the informaition(RR)? ○ Probably not … because of the cache. ● Is it easy to update the information(RR)? ○ Maybe not. In RFC 1035, we would load zone and startup file into database at local. ● Can we update the information on remote DNS Server? Questions 45
- 46. ● Why hierarchy? ○ More efficient than heterarchy. ○ Update could be immediately showed. ● Does it always waste a lot of time on process of lookup? ○ Right! So caching! ● Is it true that react immediately when we update the informaition(RR)? ○ Probably not … because of the cache. ● Is it easy to update the information(RR)? ○ Maybe not. In RFC 1035, we would load zone and startup file into database at local. ● Can we update the information on remote DNS Server? ○ No. We need another mechanism to do that. In RFC 2136, we could name DNS to DDNS with remote updating mechanism. ● That’s why we need a Dynamic DNS Server. Questions 46
- 47. Process flow 47
- 48. 48 Client DHCP Server Primary DNS Server Zone File IP Address? IP Address Update Dynamic DNS
- 49. Fine ! We know the concept of DNS. Can we start it ? 49
- 50. Prerequisites 50
- 51. IP header UDP header DNS message IP header TCP header DNS message 2-byte DNS msg. length ● DNS messages are encapsulated in UDP by default. ● If the resolver expects the response to exceed 512 bytes, the resolver encapsulates the query in TCP instead. ● If a request is sent over UDP and the response is longer than 512 bytes, the server sends the first 512 bytes of the response using UDP and sets the TC (truncated) flag. The resolver then re-sends the query using TCP. max. 512 bytes no limit (up to max. TCP payload size) 51 Transport
- 52. DNS Protocol 52
- 53. Message Format ● Header Section ● Question Section ● RR Section 53
- 54. Header Section ● ID := identification of DNS transaction ● FLAG ● QDCOUNT := questions record count ● ANCOUNT := answer record count ● NSCOUNT := authority record count ● ARCOUNT := additional record count 54
- 55. Flag ● QR ● Opcode ● RCODE 55
- 56. Flag Query 0 Respond 1 Query 0000 OpCode Retired 0001 Status 0010 reserved 0011 Notify 0100 Update 0101 56
- 57. Flag NoError No Error 0000 FormErr Format Error 0001 ServFail Server Failure 0010 NXDomain Non-Existent Domain 0011 NotImp Not Implemented 0100 Refused Query Refused 0101 YXDomain Name Exists when it should not 0110 YXRRSet RR Set Exists when it should not 0111 NXRRSet RR Set that should exist does not 1000 NotAuth Server Not Authoritative for zone 1001 NotZone Name not contained in zone 1010 57
- 58. Message Formate ● Header Section ● Question Section ● RR Section 58
- 59. Message Formate ● Header Section ● Question Section ● RR Section 59
- 60. RR Section ● The most common Type ○ Start of Authority (SOA) ○ IP addresses (A and AAAA) ○ SMTP mail exchangers (MX) ○ Name servers (NS) ○ Pointers for reverse DNS lookups (PTR) ○ Domain name aliases (CNAME) 60
- 61. RR Section ● The most common TYPE ○ Start of Authority (SOA) ○ IP addresses (A and AAAA) ○ SMTP mail exchangers (MX) ○ Name servers (NS) ○ Pointers for reverse DNS lookups (PTR) ○ Domain name aliases (CNAME) ● RDATA depends on TYPE 61
- 62. RR Section IN Internet 0x0001 CH Chaos 0x0003 HS Hesiod 0x0004 QCLASS Only Any 0x00FF 62
- 63. Aims of this Project 63
- 64. Aims 1. Efficiency 2. Uniform Protocol Access Interface 3. Consistency with RFC standard 4. Pluggable Database and DNS Complement 5. Benchmark 6. Education 64
- 65. Efficiency Is it good enough ? 65
- 66. Efficiency In order to send message rapidly, we should maintain continous memory buffer! 66
- 67. Uniform Protocol Access Interface ● MACRO ● Hard to debug 67
- 68. Uniform Protocol Access Interface 68
- 69. Consistency with RFC standard 69
- 70. Pluggable Database and DNS Complement 70
- 71. Pluggable Database and DNS Complement Object-Orien Programming in C !? 71
- 72. Education ● A pioneer have shared all of the pitfalls he met at protocol level. ● Provide uniform protocol access interface. ● Easy to change implementation. 72
- 73. Benchmark ● Follow the assignment(phonebook) of Embedded System Course in NCKU ● Mission: You need to optimize the building and searching time on phonebook. ● Assignment Link: https://hackmd.io/s/rJYD4UPKe 73
- 75. Great ! It time to work! 75
- 76. Cautions 76
- 77. Pitfalls!!! 77
- 78. Notice !!! ● If you start to build it, maybe you would be trapped in this three pitfalls: ○ Domain Name Format in Message Format ○ Message Compression ○ Endian Transfer 78
- 79. Domain Name in Message Format class of network (1 = Internet) 12 5 2 1 Address – IPv4 Name Server (authoritative) Canonical Name (alias) Pointer – reverse lookup 15 Mail Exchange 28 Address - IPv6 252 Zone Transfer PTR CNAME NS A MX AAAA AXFR sent in query; repeated in response w w w . g o o g l e . c o m Query Name Query Type Query Class 16 bit 16 bit Variable Length 79
- 80. Domain Name in Message Format class of network (1 = Internet) 12 5 2 1 Address – IPv4 Name Server (authoritative) Canonical Name (alias) Pointer – reverse lookup 15 Mail Exchange 28 Address - IPv6 252 Zone Transfer PTR CNAME NS A MX AAAA AXFR sent in query; repeated in response w w w . g o o g l e . c o m . Query Name Query Type Query Class 16 bit 16 bit Variable Length 80
- 81. Domain Name in Message Format class of network (1 = Internet) 12 5 2 1 Address – IPv4 Name Server (authoritative) Canonical Name (alias) Pointer – reverse lookup 15 Mail Exchange 28 Address - IPv6 252 Zone Transfer PTR CNAME NS A MX AAAA AXFR sent in query; repeated in response 3 w w w 6 g o o g l e 3 c o m 0 count Query Name Query Type Query Class 16 bit 16 bit Variable Length 81
- 82. Question Section Answer Section 3 w w w 6 g o o g l e 3 c o m 0 1 1 000 ... 1 1 0 0 2 bit 30 bit 16 bit Query Name Query Type Query Class Header Domain Name 16 bit 16 bit Variable Length Variable Length 12 byte C0 0C PointerCompression flag Compression 82
- 83. Question Section Answer Section 3 w w w 6 g o o g l e 3 c o m 0 1 1 000 ... 1 1 0 0 2 bit 14 bit 16 bit Query Name Query Type Query Class Header Domain Name C0 0C PointerCompression flag Compression 11 Reserve 10 Reserve 01 Normal 00 Compression 83
- 84. Question Section Answer Section 3 w w w 6 g o o g l e 3 c o m 0 1 1 000 ... 1 1 0 0 2 bit 30 bit 16 bit Query Name Query Type Query Class Header Domain Name C0 0C PointerCompression flag Compression 11 Reserve 10 Reserve 01 Normal 00 Compression 84
- 85. The difficult one for Endian transfer 0 0 0 1 0 1 0 1 0 1 0 1 0 1 0 0 QR Opcode AA TC RD RA Z AD CD RCODE 85
- 86. As I've said ………………………………….. 0 0 0 1 0 1 0 1 0 1 0 1 0 1 0 0 QR Opcode AA TC RD RA Z AD CD RCODE 1 0 1 0 0 1 0 0 0 1 0 0 0 0 1 0 86
- 87. struct in C ● make sure continuous memory space 87
- 88. Reference ● Request For Comments(RFC) ○ rfc1033 ○ rfc1034 ○ rfc1035 ○ rfc2136 ● INACON's protocol help ○ DNS Protocol ● University of Delaware ○ https://www.eecis.udel.edu/~amer/856/dns.04f.ppt ● University of Nebraska–Lincoln ○ http://cse.unl.edu/~ylu/csce855/notes/DNS.ppt ● Wikipedia DNS 88
- 90. Project would continous when I have free time (... graduated paper) 90
- 91. Contact me ● Github: yenWu ● LinkedIn: Yen-Kwan Wu ● NCKU CSIE WIKI: yenWu ● E-Mail: [email protected] 91
- 92. Q & A 92