about summary refs log blame commit diff
path: root/lisp/dns/message.lisp
blob: d4120da387604db1d99e26643ee9311280ae2755 (plain) (tree)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
                 













































































































































































































































































































































































































































































































































































                                                                           
















                                                                     





                                                                      
                                                                       
                                  
 
                                            



                                                                       













                                                                       



                                                                      


                                                                    







                                                                 



                                                                      
                                                    







                                                          
                                                           
                                       
                                                   













                                                                              













                                                                          
                                                     

                                                          


                                                                  
                                  



















                                                                      



                                                                                                 
 
                                                          



                                                                                         
                                                                      
                                                                                 
                                                                                    
                                                   
                                                                                      
(in-package :dns)

;; 3.2.2. TYPE values

;; TYPE fields are used in resource records.  Note that these types are a
;; subset of QTYPEs.

;; TYPE            value and meaning

;; A               1 a host address

;; NS              2 an authoritative name server

;; MD              3 a mail destination (Obsolete - use MX)

;; MF              4 a mail forwarder (Obsolete - use MX)

;; CNAME           5 the canonical name for an alias

;; SOA             6 marks the start of a zone of authority

;; MB              7 a mailbox domain name (EXPERIMENTAL)

;; MG              8 a mail group member (EXPERIMENTAL)

;; MR              9 a mail rename domain name (EXPERIMENTAL)

;; NULL            10 a null RR (EXPERIMENTAL)

;; WKS             11 a well known service description

;; PTR             12 a domain name pointer

;; HINFO           13 host information

;; MINFO           14 mailbox or mail list information

;; MX              15 mail exchange

;; TXT             16 text strings

;; 3.2.3. QTYPE values

;; QTYPE fields appear in the question part of a query.  QTYPES are a
;; superset of TYPEs, hence all TYPEs are valid QTYPEs.  In addition, the
;; following QTYPEs are defined:

;; AXFR            252 A request for a transfer of an entire zone

;; MAILB           253 A request for mailbox-related records (MB, MG or MR)

;; MAILA           254 A request for mail agent RRs (Obsolete - see MX)

;; *               255 A request for all records

;; 3.2.4. CLASS values

;; CLASS fields appear in resource records.  The following CLASS mnemonics
;; and values are defined:

;; IN              1 the Internet

;; CS              2 the CSNET class (Obsolete - used only for examples in
;;                 some obsolete RFCs)

;; CH              3 the CHAOS class

;; HS              4 Hesiod [Dyer 87]

;; 3.2.5. QCLASS values

;; QCLASS fields appear in the question section of a query.  QCLASS values
;; are a superset of CLASS values; every CLASS is a valid QCLASS.  In
;; addition to CLASS values, the following QCLASSes are defined:

;; *               255 any class

;; 3.3. Standard RRs

;; The following RR definitions are expected to occur, at least
;; potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
;; will be used in all classes, and have the same format in all classes.
;; Because their RDATA format is known, all domain names in the RDATA
;; section of these RRs may be compressed.

;; <domain-name> is a domain name represented as a series of labels, and
;; terminated by a label with zero length.  <character-string> is a single
;; length octet followed by that number of characters.  <character-string>
;; is treated as binary information, and can be up to 256 characters in
;; length (including the length octet).

;; 3.3.1. CNAME RDATA format

;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     /                     CNAME                     /
;;     /                                               /
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

;; where:

;; CNAME           A <domain-name> which specifies the canonical or primary
;;                 name for the owner.  The owner name is an alias.

;; CNAME RRs cause no additional section processing, but name servers may
;; choose to restart the query at the canonical name in certain cases.  See
;; the description of name server logic in [RFC-1034] for details.


;; 3.3.11. NS RDATA format

;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     /                   NSDNAME                     /
;;     /                                               /
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

;; where:

;; NSDNAME         A <domain-name> which specifies a host which should be
;;                 authoritative for the specified class and domain.

;; NS records cause both the usual additional section processing to locate
;; a type A record, and, when used in a referral, a special search of the
;; zone in which they reside for glue information.

;; The NS RR states that the named host should be expected to have a zone
;; starting at owner name of the specified class.  Note that the class may
;; not indicate the protocol family which should be used to communicate
;; with the host, although it is typically a strong hint.  For example,
;; hosts which are name servers for either Internet (IN) or Hesiod (HS)
;; class information are normally queried using IN class protocols.

;; 3.3.12. PTR RDATA format

;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     /                   PTRDNAME                    /
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

;; where:

;; PTRDNAME        A <domain-name> which points to some location in the
;;                 domain name space.

;; PTR records cause no additional section processing.  These RRs are used
;; in special domains to point to some other location in the domain space.
;; These records are simple data, and don't imply any special processing
;; similar to that performed by CNAME, which identifies aliases.  See the
;; description of the IN-ADDR.ARPA domain for an example.

;; 3.3.13. SOA RDATA format

;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     /                     MNAME                     /
;;     /                                               /
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     /                     RNAME                     /
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     |                    SERIAL                     |
;;     |                                               |
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     |                    REFRESH                    |
;;     |                                               |
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     |                     RETRY                     |
;;     |                                               |
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     |                    EXPIRE                     |
;;     |                                               |
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     |                    MINIMUM                    |
;;     |                                               |
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

;; where:

;; MNAME           The <domain-name> of the name server that was the
;;                 original or primary source of data for this zone.

;; RNAME           A <domain-name> which specifies the mailbox of the
;;                 person responsible for this zone.

;; SERIAL          The unsigned 32 bit version number of the original copy
;;                 of the zone.  Zone transfers preserve this value.  This
;;                 value wraps and should be compared using sequence space
;;                 arithmetic.

;; REFRESH         A 32 bit time interval before the zone should be
;;                 refreshed.

;; RETRY           A 32 bit time interval that should elapse before a
;;                 failed refresh should be retried.

;; EXPIRE          A 32 bit time value that specifies the upper limit on
;;                 the time interval that can elapse before the zone is no
;;                 longer authoritative.

;; MINIMUM         The unsigned 32 bit minimum TTL field that should be
;;                 exported with any RR from this zone.

;; SOA records cause no additional section processing.

;; All times are in units of seconds.

;; Most of these fields are pertinent only for name server maintenance
;; operations.  However, MINIMUM is used in all query operations that
;; retrieve RRs from a zone.  Whenever a RR is sent in a response to a
;; query, the TTL field is set to the maximum of the TTL field from the RR
;; and the MINIMUM field in the appropriate SOA.  Thus MINIMUM is a lower
;; bound on the TTL field for all RRs in a zone.  Note that this use of
;; MINIMUM should occur when the RRs are copied into the response and not
;; when the zone is loaded from a master file or via a zone transfer.  The
;; reason for this provison is to allow future dynamic update facilities to
;; change the SOA RR with known semantics.


;; 3.3.14. TXT RDATA format

;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     /                   TXT-DATA                    /
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

;; where:

;; TXT-DATA        One or more <character-string>s.

;; TXT RRs are used to hold descriptive text.  The semantics of the text
;; depends on the domain where it is found.

;; 3.4. Internet specific RRs

;; 3.4.1. A RDATA format

;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     |                    ADDRESS                    |
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

;; where:

;; ADDRESS         A 32 bit Internet address.

;; Hosts that have multiple Internet addresses will have multiple A
;; records.


;; A records cause no additional section processing.  The RDATA section of
;; an A line in a master file is an Internet address expressed as four
;; decimal numbers separated by dots without any imbedded spaces (e.g.,
;; "10.2.0.52" or "192.0.5.6").

;; 3.4.2. WKS RDATA format

;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     |                    ADDRESS                    |
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;;     |       PROTOCOL        |                       |
;;     +--+--+--+--+--+--+--+--+                       |
;;     |                                               |
;;     /                   <BIT MAP>                   /
;;     /                                               /
;;     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

;; where:

;; ADDRESS         An 32 bit Internet address

;; PROTOCOL        An 8 bit IP protocol number

;; <BIT MAP>       A variable length bit map.  The bit map must be a
;;                 multiple of 8 bits long.

;; The WKS record is used to describe the well known services supported by
;; a particular protocol on a particular internet address.  The PROTOCOL
;; field specifies an IP protocol number, and the bit map has one bit per
;; port of the specified protocol.  The first bit corresponds to port 0,
;; the second to port 1, etc.  If the bit map does not include a bit for a
;; protocol of interest, that bit is assumed zero.  The appropriate values
;; and mnemonics for ports and protocols are specified in [RFC-1010].

;; For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
;; 25 (SMTP).  If this bit is set, a SMTP server should be listening on TCP
;; port 25; if zero, SMTP service is not supported on the specified
;; address.

;; The purpose of WKS RRs is to provide availability information for
;; servers for TCP and UDP.  If a server supports both TCP and UDP, or has
;; multiple Internet addresses, then multiple WKS RRs are used.

;; WKS RRs cause no additional section processing.

;; In master files, both ports and protocols are expressed using mnemonics
;; or decimal numbers.

;; 3.5. IN-ADDR.ARPA domain

;; The Internet uses a special domain to support gateway location and
;; Internet address to host mapping.  Other classes may employ a similar
;; strategy in other domains.  The intent of this domain is to provide a
;; guaranteed method to perform host address to host name mapping, and to
;; facilitate queries to locate all gateways on a particular network in the
;; Internet.

;; Note that both of these services are similar to functions that could be
;; performed by inverse queries; the difference is that this part of the
;; domain name space is structured according to address, and hence can
;; guarantee that the appropriate data can be located without an exhaustive
;; search of the domain space.

;; The domain begins at IN-ADDR.ARPA and has a substructure which follows
;; the Internet addressing structure.

;; Domain names in the IN-ADDR.ARPA domain are defined to have up to four
;; labels in addition to the IN-ADDR.ARPA suffix.  Each label represents
;; one octet of an Internet address, and is expressed as a character string
;; for a decimal value in the range 0-255 (with leading zeros omitted
;; except in the case of a zero octet which is represented by a single
;; zero).

;; Host addresses are represented by domain names that have all four labels
;; specified.  Thus data for Internet address 10.2.0.52 is located at
;; domain name 52.0.2.10.IN-ADDR.ARPA.  The reversal, though awkward to
;; read, allows zones to be delegated which are exactly one network of
;; address space.  For example, 10.IN-ADDR.ARPA can be a zone containing
;; data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
;; MILNET.  Address nodes are used to hold pointers to primary host names
;; in the normal domain space.

;; Network numbers correspond to some non-terminal nodes at various depths
;; in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
;; 2, or 3 octets.  Network nodes are used to hold pointers to the primary
;; host names of gateways attached to that network.  Since a gateway is, by
;; definition, on more than one network, it will typically have two or more
;; network nodes which point at it.  Gateways will also have host level
;; pointers at their fully qualified addresses.

;; Both the gateway pointers at network nodes and the normal host pointers
;; at full address nodes use the PTR RR to point back to the primary domain
;; names of the corresponding hosts.

;; For example, the IN-ADDR.ARPA domain will contain information about the
;; ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's

;; net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU.  Assuming that ISI
;; gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
;; GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
;; and a name GW.LCS.MIT.EDU, the domain database would contain:

;;     10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
;;     10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
;;     18.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
;;     26.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
;;     22.0.2.10.IN-ADDR.ARPA.    PTR MILNET-GW.ISI.EDU.
;;     103.0.0.26.IN-ADDR.ARPA.   PTR MILNET-GW.ISI.EDU.
;;     77.0.0.10.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
;;     4.0.10.18.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
;;     103.0.3.26.IN-ADDR.ARPA.   PTR A.ISI.EDU.
;;     6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.

;; Thus a program which wanted to locate gateways on net 10 would originate
;; a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA.  It
;; would receive two RRs in response:

;;     10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
;;     10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.

;; The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
;; GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
;; these gateways.

;; A resolver which wanted to find the host name corresponding to Internet
;; host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
;; QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:

;;     6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.

;; Several cautions apply to the use of these services:
;;    - Since the IN-ADDR.ARPA special domain and the normal domain
;;      for a particular host or gateway will be in different zones,
;;      the possibility exists that that the data may be inconsistent.

;;    - Gateways will often have two names in separate domains, only
;;      one of which can be primary.

;;    - Systems that use the domain database to initialize their
;;      routing tables must start with enough gateway information to
;;      guarantee that they can access the appropriate name server.

;;    - The gateway data only reflects the existence of a gateway in a
;;      manner equivalent to the current HOSTS.TXT file.  It doesn't
;;      replace the dynamic availability information from GGP or EGP.

;; 3.6. Defining new types, classes, and special namespaces

;; The previously defined types and classes are the ones in use as of the
;; date of this memo.  New definitions should be expected.  This section
;; makes some recommendations to designers considering additions to the
;; existing facilities.  The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
;; forum where general discussion of design issues takes place.

;; In general, a new type is appropriate when new information is to be
;; added to the database about an existing object, or we need new data
;; formats for some totally new object.  Designers should attempt to define
;; types and their RDATA formats that are generally applicable to all
;; classes, and which avoid duplication of information.  New classes are
;; appropriate when the DNS is to be used for a new protocol, etc which
;; requires new class-specific data formats, or when a copy of the existing
;; name space is desired, but a separate management domain is necessary.

;; New types and classes need mnemonics for master files; the format of the
;; master files requires that the mnemonics for type and class be disjoint.

;; TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
;; respectively.

;; The present system uses multiple RRs to represent multiple values of a
;; type rather than storing multiple values in the RDATA section of a
;; single RR.  This is less efficient for most applications, but does keep
;; RRs shorter.  The multiple RRs assumption is incorporated in some
;; experimental work on dynamic update methods.

;; The present system attempts to minimize the duplication of data in the
;; database in order to insure consistency.  Thus, in order to find the
;; address of the host for a mail exchange, you map the mail domain name to
;; a host name, then the host name to addresses, rather than a direct
;; mapping to host address.  This approach is preferred because it avoids
;; the opportunity for inconsistency.

;; In defining a new type of data, multiple RR types should not be used to
;; create an ordering between entries or express different formats for
;; equivalent bindings, instead this information should be carried in the
;; body of the RR and a single type used.  This policy avoids problems with
;; caching multiple types and defining QTYPEs to match multiple types.

;; For example, the original form of mail exchange binding used two RR
;; types one to represent a "closer" exchange (MD) and one to represent a
;; "less close" exchange (MF).  The difficulty is that the presence of one
;; RR type in a cache doesn't convey any information about the other
;; because the query which acquired the cached information might have used
;; a QTYPE of MF, MD, or MAILA (which matched both).  The redesigned




;; service used a single type (MX) with a "preference" value in the RDATA
;; section which can order different RRs.  However, if any MX RRs are found
;; in the cache, then all should be there.

;; 4. MESSAGES

;; 4.1. Format

;; All communications inside of the domain protocol are carried in a single
;; format called a message.  The top level format of message is divided
;; into 5 sections (some of which are empty in certain cases) shown below:

;; The names of the sections after the header are derived from their use in
;; standard queries.  The question section contains fields that describe a
;; question to a name server.  These fields are a query type (QTYPE), a
;; query class (QCLASS), and a query domain name (QNAME).  The last three
;; sections have the same format: a possibly empty list of concatenated
;; resource records (RRs).  The answer section contains RRs that answer the
;; question; the authority section contains RRs that point toward an
;; authoritative name server; the additional records section contains RRs
;; which relate to the query, but are not strictly answers for the
;; question.

;; The header section is always present.  The header includes fields that
;; specify which of the remaining sections are present, and also specify
;; whether the message is a query or a response, a standard query or some
;; other opcode, etc.

;; 4.1.1. Header section format

(defbinary dns-header (:byte-order :big-endian)
           ;; A 16 bit identifier assigned by the program that
           ;; generates any kind of query. This identifier is copied
           ;; the corresponding reply and can be used by the requester
           ;; to match up replies to outstanding queries.
           (id 0 :type 16)

           ;; A one bit field that specifies whether this message is a
           ;; query (0), or a response (1).
           (qr 0 :type 1)

           ;; A four bit field that specifies kind of query in this
           ;; message. This value is set by the originator of a query
           ;; and copied into the response. The values are:
           ;;
           ;; 0               a standard query (QUERY)
           ;; 1               an inverse query (IQUERY)
           ;; 2               a server status request (STATUS)
           ;; 3-15            reserved for future use
           (opcode 0 :type 4) ; TODO(tazjin): use define-enum

           ;; Authoritative Answer - this bit is valid in responses,
           ;; and specifies that the responding name server is an
           ;; authority for the domain name in question section.
           (aa nil :type 1)

           ;; TrunCation - specifies that this message was truncated
           ;; due to length greater than that permitted on the
           ;; transmission channel.
           (tc nil :type 1)

           ;; Recursion Desired - this bit may be set in a query and
           ;; is copied into the response.  If RD is set, it directs
           ;; the name server to pursue the query recursively.
           ;; Recursive query support is optional.
           (rd nil :type 1)

           ;; Recursion Available - this be is set or cleared in a
           ;; response, and denotes whether recursive query support is
           ;; available in the name server.
           (ra nil :type 1)

           ;; Reserved for future use. Must be zero in all queries and
           ;; responses.
           (z 0 :type 3)

           ;; Response code - this 4 bit field is set as part of
           ;; responses.  The values have the following
           ;; interpretation:
           ;; 0               No error condition
           ;; 1               Format error - The name server was
           ;;                 unable to interpret the query.
           ;; 2               Server failure - The name server was
           ;;                 unable to process this query due to a
           ;;                 problem with the name server.
           ;; 3               Name Error - Meaningful only for
           ;;                 responses from an authoritative name
           ;;                 server, this code signifies that the
           ;;                 domain name referenced in the query does
           ;;                 not exist.
           ;; 4               Not Implemented - The name server does
           ;;                 not support the requested kind of query.
           ;; 5               Refused - The name server refuses to
           ;;                 perform the specified operation for
           ;;                 policy reasons.  For example, a name
           ;;                 server may not wish to provide the
           ;;                 information to the particular requester,
           ;;                 or a name server may not wish to perform
           ;;                 a particular operation (e.g., zone
           ;;                 transfer) for particular data.
           ;; 6-15            Reserved for future use.
           (rcode 0 :type 4)

           ;; an unsigned 16 bit integer specifying the number of
           ;; entries in the question section.
           (qdcount 0 :type 16)

           ;; an unsigned 16 bit integer specifying the number of
           ;; resource records in the answer section.
           (ancount 0 :type 16)

           ;; an unsigned 16 bit integer specifying the number of name
           ;; server resource records in the authority records
           ;; section.
           (nscount 0 :type 16)

           ;; an unsigned 16 bit integer specifying the number of
           ;; resource records in the additional records section.
           (arcount 0 :type 16))


;; Representation of DNS QNAMEs.
;;
;; A QNAME can be either made up entirely of labels, which is
;; basically a list of strings, or be terminated with a pointer to an
;; offset within the original message.

(deftype qname-field ()
  '(or
    ;; pointer
    (unsigned-byte 14)
    ;; label
    string))

(defstruct qname
  (start-at 0 :type (unsigned-byte 14))
  (names #() :type (vector qname-field)))

;; Domain names in questions and resource records are represented as a
;; sequence of labels, where each label consists of a length octet
;; followed by that number of octets.
;;
;; The domain name terminates with the zero length octet for the null
;; label of the root. Note that this field may be an odd number of
;; octets; no padding is used.
(declaim (ftype (function (stream) (values qname integer)) read-qname))
(defun read-qname (stream)
  "Reads a DNS QNAME from STREAM."

  (let ((start-at (file-position stream)))
    (iter (for byte next (read-byte stream))
      ;; Each fragment is collected into this byte vector pre-allocated
      ;; with the correct size.
      (for fragment = (make-array byte :element-type '(unsigned-byte 8)
                                       :fill-pointer 0))

      ;; If the bit sequence (1 1) is encountered at the beginning of
      ;; the fragment, a qname pointer is being read.
      (let ((byte-copy byte))
        (when (equal #b11 (lisp-binary/integer:pop-bits 2 8 byte-copy))
          (let ((next (read-byte stream)))
            (lisp-binary/integer:push-bits byte-copy 8 next)
            (collect next into fragments result-type vector)
            (sum 2 into size)
            (finish))))

      ;; Total size is needed, count for each iteration byte, plus its
      ;; own value.
      (sum (+ 1 byte) into size)
      (until (equal byte 0))

      ;; On each iteration, this will interpret the current byte as an
      ;; unsigned integer and read from STREAM an equivalent amount of
      ;; times to assemble the current fragment.
      ;;
      ;; Advancing the stream like this also ensures that the next
      ;; iteration occurs on a new fragment or the final terminating
      ;; byte.
      ;;
      ;; TODO(tazjin): Use lisp-binary:read-counted-string.
      (dotimes (_ byte (collect (babel:octets-to-string fragment)
                         into fragments result-type vector))
        (vector-push (read-byte stream) fragment))

      (finally (return (values (make-qname :start-at start-at
                                           :names fragments)
                               size))))))

(declaim (ftype (function (stream qname)) write-qname))
(defun write-qname (stream qname)
  "Write a DNS qname to STREAM."

  ;; Write each fragment starting with its (byte-) length, followed by
  ;; the bytes.
  (iter (for fragment in-vector (qname-names qname))
    (for bytes = (babel:string-to-octets fragment))
    (write-byte (length bytes) stream)
    (iter (for byte in-vector bytes)
      (write-byte byte stream)))

  ;; Always finish off the serialisation with a null-byte!
  (write-byte 0 stream))

;; 4.1.2. Question section format
(defbinary dns-question (:byte-order :big-endian :export t)
           ;; a domain name represented
           (qname "" :type (custom :lisp-type qname
                                   :reader #'read-qname
                                   :writer #'write-qname))

           ;; a two octet code which specifies the type of the query.
           ;; The values for this field include all codes valid for a
           ;; TYPE field, together with some more general codes which
           ;; can match more than one type of RR.
           (qtype 0 :type 16) ;; TODO(tazjin): define type after the RR binary

           ;; a two octet code that specifies the class of the query. For
           ;; example, the QCLASS field is IN for the Internet.
           (qclass 0 :type 16)) ; TODO(tazjin): enum?

;; 4.1.3. Resource record format

(define-enum dns-type 2
    (:byte-order :big-endian)

    ;; http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
    (A 1)
    (NS 2)
    (CNAME 5)
    (SOA 6)
    (PTR 12)
    (MX 15)
    (TXT 16)
    (SRV 33)
    (AAAA 28)
    (ANY  255)) ;; (typically wants SOA, MX, NS and MX)

(defbinary dns-rr (:byte-order :big-endian :export t)
           (name nil :type (custom :lisp-type qname
                                   :reader #'read-qname
                                   :writer #'write-qname))

           ;; two octets containing one of the RR type codes. This
           ;; field specifies the meaning of the data in the RDATA
           ;; field.
           (type 0 :type dns-type)

           ;; two octets which specify the class of the data in the
           ;; RDATA field.
           (class 0 :type 16)           ; TODO(tazjin): enum

           ;; a 32 bit unsigned integer that specifies the time
           ;; interval (in seconds) that the resource record may be
           ;; cached before it should be discarded. Zero values are
           ;; interpreted to mean that the RR can only be used for the
           ;; transaction in progress, and should not be cached.
           (ttl 0 :type 32)

           ;; an unsigned 16 bit integer that specifies the length in
           ;; octets of the RDATA field.
           (rdlength 0 :type 16)

           ;; a variable length string of octets that describes the
           ;; resource. The format of this information varies
           ;; according to the TYPE and CLASS of the resource record.
           ;; For example, the if the TYPE is A and the CLASS is IN,
           ;; the RDATA field is a 4 octet ARPA Internet address.
           (rdata #() :type (eval (case type
                                    ;; TODO(tazjin): Deal with multiple strings in single RRDATA
                                    ((TXT) '(counted-string 1))
                                    ((A) '(simple-array (unsigned-byte 8) (4)))
                                    (otherwise `(simple-array (unsigned-byte 8) (,rdlength)))))))

(defbinary dns-message (:byte-order :big-endian :export t)
           (header nil :type dns-header)

           ;; the question for the name server
           (question #() :type (simple-array dns-question ((dns-header-qdcount header))))

           ;; ;; RRs answering the question
           ;; (answer #() :type (simple-array (unsigned-byte 8) (16)))
           (answer #() :type (simple-array dns-rr ((dns-header-ancount header))))

           ;; ;; ;; RRs pointing toward an authority
           (authority #() :type (simple-array dns-rr ((dns-header-nscount header))))

           ;; ;; RRs holding additional information
           (additional #() :type (simple-array dns-rr ((dns-header-arcount header)))))