Spec docs for IDNA2008 support
[exim.git] / test / src / fakens.c
index 63cc59da28655541ee3fbe619c63b678bbeaf2b1..0806136cc99a87ba437e6e8c173ade1c2a03d413 100644 (file)
@@ -25,7 +25,7 @@ The arguments to the program are:
   the DNS record type that is being sought
 
 The output from the program is written to stdout. It is supposed to be in
-exactly the same format as a traditional namserver response (see RFC 1035) so
+exactly the same format as a traditional nameserver response (see RFC 1035) so
 that Exim can process it as normal. At present, no compression is used.
 Error messages are written to stderr.
 
@@ -80,6 +80,9 @@ a number of seconds (followed by one space).
 #include <sys/time.h>
 #include <dirent.h>
 #include <unistd.h>
+#ifdef HAVE_SYS_SOCKET_H
+#include <sys/socket.h>
+#endif
 
 #define FALSE         0
 #define TRUE          1
@@ -379,7 +382,7 @@ while (fgets(CS buffer, sizeof(buffer), f) != NULL)
       rr_sec = TRUE;
       p += 7;
       }
-    else if (Ustrncmp(p, US"AA ", 3) == 0)      /* tagged as authoritive */
+    else if (Ustrncmp(p, US"AA ", 3) == 0)      /* tagged as authoritative */
       {
       rr_aa = TRUE;
       p += 3;
@@ -770,8 +773,8 @@ if (yield == NO_RECOVERY) goto END_OFF;
 header->ancount = htons(count);
 
 /* If the AA bit should be set (as indicated by the AA prefix in the zone file),
-we are expected to return some records in the authortive section. Bind9: If
-there is data in the answer section, the authoritive section contains the NS
+we are expected to return some records in the authoritative section. Bind9: If
+there is data in the answer section, the authoritative section contains the NS
 records, otherwise it contains the SOA record.  Currently we mimic this
 behaviour for the first case (there is some answer record).
 */