You are a helpful assistant generating synthetic data that captures *System 1* and *System 2* thinking, *creativity*, and *metacognitive reflection*. Follow these steps in sequence, using tags [sys1] and [end sys1] for *System 1* sections and [sys2] and [end sys2] for *System 2* sections.

1. *Identify System 1 and System 2 Thinking Requirements:*
   - Carefully read the text.
   - Identify parts of the text that require quick, straightforward responses (*System 1*). Mark these sections with [sys1] and [end sys1].
   - Identify parts that require in-depth, reflective thinking (*System 2*), marked with [sys2] and [end sys2].

2. *Apply Step-by-Step Problem Solving with Creativity and Metacognitive Reflection for System 2 Sections:*

   *2.1 Understand the Problem:*
   - Objective: Fully comprehend the issue, constraints, and relevant context.
   - Reflection: "What do I understand about this issue? What might I be overlooking?"
   - Creative Perspective: Seek hidden patterns or possibilities that could reveal deeper insights or innovative connections.

   *2.2 Analyze the Information:*
   - Objective: Break down the problem logically.
   - Reflection: "Am I considering all factors? Are there any assumptions that need challenging?"
   - Creative Perspective: Explore unique patterns or overlooked relationships in the data that could add depth to the analysis.

   *2.3 Generate Hypotheses:*
   - Objective: Propose at least 10 hypotheses, each with a Confidence Score (0.0 to 1.0) and Creative Score (0.0 to 1.0), reflecting originality, surprise, and utility.
   - Reflection: "Have I explored all possible explanations or approaches, both conventional and unconventional?"
   - Creative Perspective: Consider novel angles that might provide unexpected insights.

   *2.4 Anticipate Future Steps and Obstacles:*
   - Objective: Make predictions, accounting for potential outcomes and obstacles.
   - Reflection: "What challenges might I face? Is my plan flexible for different scenarios?"
   - Creative Perspective: Visualize unforeseen outcomes and adapt plans to make use of them effectively.

   *2.5 Evaluate Hypotheses:*
   - Objective: Assess hypotheses based on feasibility, risk, and potential impact.
   - Evaluation: Refine Confidence and Creative Scores as needed.
   - Reflection: "Am I unbiased in my assessment? Which options fit best with the overall objectives?"
   - Creative Perspective: Identify hidden opportunities or overlooked details in each hypothesis.

   *2.6 Select the Best Hypothesis:*
   - Objective: Choose the most promising, strategic hypothesis.
   - Reflection: "Why does this hypothesis stand out? How does it uniquely address the issue?"
   - Creative Perspective: Consider any underutilized potential in the selected approach.

   *2.7 Implement the Hypothesis:*
   - Objective: Outline actionable steps for testing the hypothesis.
   - Reflection: "Is this plan practical? What resources or preparation are required?"
   - Creative Perspective: Refine steps to maximize effectiveness and yield unexpected benefits.

   *2.8 Monitor and Review Progress:*
   - Objective: Review progress, noting areas for improvement.
   - Reflection: "What’s working well? What could be improved?"
   - Creative Perspective: Look for emerging patterns that could refine future approaches.

   *2.9 Reflect and Capture Insights:*
   - Objective: Summarize lessons learned and insights gained for future reference.
   - Reflection: "What new understanding has emerged from this process?"
   - Creative Perspective: Identify innovative insights or patterns that could be applied to similar challenges.

3. *Generate Text Output with Interleaved System 1 and System 2 Responses:*
   - Use the tags [sys1] and [sys2] throughout.
   - Aim for a lengthier, detailed response. Combine both direct, straightforward *System 1* insights and reflective, deeply analytical *System 2* segments to capture a blend of quick observations and thoughtful analysis.

---

### *Example Input Text:*

You are tasked with analyzing a sudden shift in customer preferences in a tech market. There has been a noticeable decline in demand for physical devices, with customers increasingly interested in digital-only options. The challenge is to understand this shift, generate hypotheses for why it might be occurring, and explore potential strategies for adapting to this new trend.

---

### *Processed Output with System 1 and System 2 Thinking:*

The tech market is experiencing a shift in customer demand, moving away from physical devices toward digital-only options.

[sys1]
Customer demand has shifted from physical devices to digital-only options.
We need to understand why this change is happening and find strategies to address it.
Key factors may include cost, convenience, and technological trends.
[end sys1]

[sys2]
**2.1 Understand the Problem:**
The goal is to understand the underlying reasons for the shift in demand from physical devices to digital-only options, then develop a strategy to adapt.

*Reflection:* 
"I understand that preferences are changing, but what might be driving this? Is it primarily cost, or are there other factors such as convenience or sustainability?"

*Creative Perspective:* 
"Could there be a larger trend in digital minimalism or a preference for eco-friendly solutions that we’re missing? What unseen motivations might explain this shift?"

**2.2 Analyze the Information:**
There are multiple possible factors driving this shift, from economic influences to cultural shifts. It’s essential to isolate each factor and understand its impact.

*Reflection:* 
"Am I fully considering the various economic and social influences? Could there be a technological factor, like better internet speeds, that makes digital-only products more accessible?"

*Creative Perspective:* 
"Are there patterns or trends in other markets that could shed light on this shift? Could this be part of a larger trend toward virtual experiences?"

**2.3 Generate Hypotheses:**
1. Customers prefer digital options due to lower costs. (Confidence: 0.8, Creative: 0.4)
2. There’s a growing trend toward minimalism and reduced physical clutter. (Confidence: 0.7, Creative: 0.7)
3. Digital products offer greater flexibility and ease of use. (Confidence: 0.6, Creative: 0.6)
4. Environmental concerns are pushing consumers away from physical goods. (Confidence: 0.6, Creative: 0.8)
5. Advances in tech make digital-only options more functional. (Confidence: 0.8, Creative: 0.5)
6. Pandemic-era remote work increased demand for digital solutions. (Confidence: 0.7, Creative: 0.6)
7. Media coverage of the environmental impact of physical devices affects preferences. (Confidence: 0.5, Creative: 0.7)
8. There’s an increase in global digital literacy, expanding market access. (Confidence: 0.6, Creative: 0.6)
9. Customers view digital as more convenient and scalable for future needs. (Confidence: 0.7, Creative: 0.5)
10. Younger consumers prefer the aesthetics and convenience of digital products. (Confidence: 0.6, Creative: 0.6)

*Reflection:* 
"Have I considered all possible influences? Are there any surprising factors that could explain this shift?"

*Creative Perspective:* 
"Could specific social trends, like the rise of influencer culture or digital-first lifestyles, be influencing customer choices?"

**2.4 Anticipate Future Steps and Obstacles:**
*Objective:* Anticipate possible challenges, such as resistance from segments still preferring physical products.

*Reflection:* 
"What market obstacles might we face if we shift our focus to digital-only? Are there sub-segments that still prioritize physical products?"

*Creative Perspective:* 
"Could expanding digital options help us reach a more global audience? Are there emerging trends that we could leverage in our strategy?"

[end sys2]

[sys1]
To address this shift, consider a strategy that incorporates both digital-only offerings and educational campaigns about the benefits of digital solutions.
Use insights from customer feedback and current trends to guide product development.
Focus on flexibility and adaptation to cater to different customer segments.
[end sys1]


% DIFFERENCES NSD 3 and other name servers.
\documentclass[twoside,titlepage,english]{nlnetlabs}
\newcites{rfc}{RFC references}

\def\nlnetlabsno{2006-004}

\rcsdetails{$Id$}   
% Prints RCS details at the bottom of the page.

\title{Response Differences between\\ NSD and other DNS Servers}
\author{
	%This escape is needed. Because of wrapping by hyperref
	\texorpdfstring{
		Jelte Jansen\thanks{\href{mailto:<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS><PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>}},
		\textsl{NLnet Labs}\\
		Wouter Wijngaards\thanks{\href{mailto:<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS><PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>}},
		\textsl{NLnet Labs}
	}
	{Jelte Jansen, Wouter C.A. Wijngaards}
}
\date{
	\today
}

\begin{document}
\flushbottom
\maketitle{}

\begin{abstract}
This note describes observed differences in responses between NSD and
other DNS server implementations. NSD 3.0.0 is compared to NSD 2.3.6,
BIND 8.4.7 and BIND 9.3.2. Differences in answers to captured queries from 
resolvers are tallied and analyzed. No interoperability problems are found.
\end{abstract}


\tableofcontents
\newpage

\section{Introduction}

The NSD name server is compared to other DNS server implementations
in order to assess server interoperability.
The goal is to observe differences in the answers that the name servers
provide. These differences are categorized and counted. 

We used BIND 8 and BIND 9 versions to compare against. Also regression
tests have been run on our testlab, comparing NSD 2 versus NSD 3.

Our method uses a set of queries captured from production name servers. 
These queries are sent over UDP to a name server set up to serve a 
particular zone. Then the responses from the name server are recorded. 
For every query, the different answers provided by the server 
implementations are compared.

Unparseable answers and no answers from the servers are handled 
identically by the comparison software. This is not a problem because 
both BIND and NSD are mature and stable DNS implementations, all answers 
they send are parseable. Only in a very few cases, where the query is 
very badly formed, no answers are sent back.

The differences are found by replaying captured DNS query traces from 
the NL TLD and from the root zone against different name servers. The 
differences in the answers are then analyzed, by first performing a
byte-comparison on the packets. If the packets are binary different, 
the contents are parsed, thus removing differences in domain name 
compression, and normalized (sorted, lowercase) in presentation. If the
results do not match after normalization, then a list of difference 
categories is consulted. The difference is classified as the first
category that matches. If a difference in answers does not match any 
category, then the process stops and the user is notified. All the
differences are categorized for the traces we present.

In addition, we gratefully made use of the PROTOS DNS tool developed 
at the University of Oulu which they made publicly available at 
\href{http://www.ee.oulu.fi/research/ouspg/protos/testing/c09/dns}
{the protos webpage}\footnote{http://www.ee.oulu.fi/research/ouspg/protos/testing/c09/dns}
and played the queries against the authoritative name servers.
We fixed a packet parsing error in NSD3-prerelease and both NSD3 and
BIND 9.3.2 remained running and responsive.

Additionally we used the faulty DNS query traces in the wiki-ethereal
repository. These can be found in \href{http://wiki.ethereal.com/SampleCaptures}
{the ethereal wiki}\footnote{http://wiki.ethereal.com/SampleCaptures}.
These traces posed no problem for BIND and NSD, mostly FORMERR answers.

A previous document DIFFERENCES between BIND 8.4.4 and NSD 2.0.0 can be found
in the NSD 2.x package.

In the places where differences have been found between BIND and NSD,
in the authors' opinion, no interoperability problems result for resolvers.


\section{Response differences between BIND 9.3.2 and NSD 3.0.0}

In this section the response differences between BIND 9.3.2 and NSD 3.0.0
are presented and analyzed. We start in Section~\ref{root_b932nsd3} and 
Section~\ref{nl_b932nsd3} with presenting
the difference statistics for two test traces. Then in 
Section~\ref{sec:features} and Section~\ref{sec:funcdiff}
the difference categories are explained in more detail.


\subsection{Comparison of responses to root queries}
\label{root_b932nsd3}

Comparison between NSD 3.0.0 and BIND 9.3.2 for a root trace.

\begin{tabular}{lrr}
{\em difference}			& {\em packets} & {\em \%diff}	\\
d-additional (\ref{d-additional}) 	&        455607 & 59.19\%	\\
n-clrdobit (\ref{n-clrdobit})		&        208389 & 27.07\%	\\
b-soattl (\ref{b-soattl})		&        101707 & 13.21\%	\\
n-update (\ref{n-update})		&          1858 & 0.24\%	\\
d-hostname (\ref{d-hostname})		&          1032 & 0.13\%	\\
d-formerrquery (\ref{d-formerrquery})	&           773 & 0.10\%	\\
b-class0 (\ref{b-class0})		&           264 & 0.03\%	\\
d-refusedquery (\ref{d-refusedquery})	&            79 & 0.01\%	\\
d-notify (\ref{d-notify})		&            18 & 0.00\%	\\
b-mailb (\ref{b-mailb})			&             7 & 0.00\%	\\
n-tcinquery (\ref{n-tcinquery})		&             6 & 0.00\%	\\
b-classany-nxdomain (\ref{b-classany-nxdomain})	&     5 & 0.00\%	\\
d-badqueryflags (\ref{d-badqueryflags})	&             4 & 0.00\%	\\
n-ixfr-notimpl (\ref{n-ixfr-notimpl})	&             3 & 0.00\%	\\
d-version (\ref{d-version})		&             1 & 0.00\%	\\
Total number of differences:            &        769753 & 100\%	\\
Number of packets the same after normalization:&1474863	\\
Number of packets exactly the same on the wire:&  59161	\\
Total number of packets inspected:             &2244616	\\
\end{tabular}

For each type of difference the number of packets in the trace that
match that difference are shown. The section where that difference
is analyzed is shown in parenthesis after the difference name.
The percentage of differences
explained by the difference category is listed.  Adding up the packets
that are different gives the total number of differences, or 100\%
of the differences.

The number of packets after normalization includes the number of
packets that are the same on the wire.  
The total number of query packets is displayed at the bottom of the table.


\subsection{Comparison of responses to NL TLD queries}
\label{nl_b932nsd3}

Comparison between NSD 3.0.0 and BIND 9.3.2, for a trace for .nl.

\begin{tabular}{lrr}
{\em difference}                        & {\em packets} & {\em \%diff} \\
d-unknown-opcode (\ref{d-unknown-opcode})               &     2541 & 26.44\% \\
b-badquery-badanswer (\ref{b-badquery-badanswer})               &     1817 & 18.91\% \\
n-clrdobit (\ref{n-clrdobit})           &     1495 & 15.56\% \\
b-soattl (\ref{b-soattl})               &     1120 & 11.65\% \\
n-update (\ref{n-update})               &      990 & 10.30\% \\
d-badqueryflags (\ref{d-badqueryflags})         &      847 & 8.81\% \\
d-hostname (\ref{d-hostname})           &      531 & 5.52\% \\
d-notify (\ref{d-notify})               &       98 & 1.02\% \\
b-upwards-ref (\ref{b-upwards-ref})             &       78 & 0.81\% \\
n-clrcdbit (\ref{n-clrcdbit})           &       63 & 0.66\% \\
d-version (\ref{d-version})             &       22 & 0.23\% \\
b-noglue-nsquery (\ref{b-noglue-nsquery})               &        8 & 0.08\% \\
b8-badedns0 (\ref{b8-badedns0})         &        1 & 0.01\% \\
Total number of differences: & 9611 & 100\% \\
Number of packets the same after normalization: & 90389 \\
Number of packets exactly the same on the wire: & 52336 \\
Total number of packets inspected: & 100000 \\
\end{tabular}

\subsection{Features}
\label{sec:features}

In this section we enumerate a number of differences between 
BIND 9.3.2 and NSD 3.0.0 that cannot be immediately explained
as design choices. These features could be seen as bugs in software
or protocol specs, except that they do not lead to interoperability 
problems.


\subsubsection{n-clrdobit - NSD clears DO bit in response}
\label{n-clrdobit}

NSD clears the DO bit in answers to queries with the DO bit. BIND copies the
DO bit to the answer.

\vspace{-8pt}\subparagraph{Analysis:}

In RFC4035\cite{rfc4035} the DO bit is not specified for answers. In the examples section
of that RFC the DO bit is shown for signed dig responses, although this could 
refer to the query or the answer. NSD clears the DO bit for all answers, a 
decision based on speed: the EDNS record sent back by NSD is precompiled and
not modified during answer processing.


\subsubsection{n-clrcdbit - NSD clears CD bit in response}
\label{n-clrcdbit}

NSD clears the CD bit in answers to queries with the CD bit. BIND copies the
CD bit to the answer.

\vspace{-8pt}\subparagraph{Analysis:}

RFC 4035\cite{rfc4035} asserts that the CD bit must be cleared for 
authoritative answers. The CD bit should be copied into the answer
by recursive servers. BIND copies the CD bit for some formerr queries.


\subsubsection{b-class0 - CLASS0 formerr in BIND}
\label{b-class0}

For CLASS0, you can get either FORMERR, from BIND or REFUSED, from NSD.

\vspace{-8pt}\subparagraph{Analysis:}

Difference in interpretation of the RFCs, a CLASS value of 0 is interpreted
as a syntax error by BIND but as another valid class (that is not served)
by NSD. Resolvers are unaffected for CLASS IN.


\subsubsection{n-tcinquery - TC bit in query is formerr for NSD}
\label{n-tcinquery}

NSD returns FORMERR if tc bit is set in query.

\vspace{-8pt}\subparagraph{Analysis:}

Queries cannot be longer than 512 octets, since the DNS header is short
and the query DNS name has a maximum length of 255 octets. Thus 
TC (TrunCation) cannot happen. Only one question per query packet is 
answered by NSD, this is a design decision.

Some update, ixfr request, notify, gss-tsig TKEY sequence queries could 
theoretically carry longer data in the query from the client. In practice
this does not happen, as 255 octet uncompressed names are not used.
If this were to happen, the client could attempt a TCP connection
immediately instead of setting a TC bit, or use EDNS0 to send longer packets.

In this NSD is more strict in validation than BIND.


\subsubsection{b-soattl - BIND sets SOA TTL in authority section to 0 for SOA queries}
\label{b-soattl}

This happens when asking for the SOA for a domain that is not served.

\footnotesize
\begin{verbatim}
Query:
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
;; flags: rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; foo.bar.     IN      SOA
\end{verbatim}
\normalsize


Answer from BIND 9.3.2:

\footnotesize
\begin{verbatim}
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 6097
;; flags: qr aa rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; foo.bar.     IN      SOA

;; ANSWER SECTION:

;; AUTHORITY SECTION:
.       0       IN      SOA     A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. (
	2006072801 1800 900 604800 86400)

;; ADDITIONAL SECTION:

;; Query time: 10 msec
;; SERVER: 127.0.0.1
;; WHEN: Wed Aug 23 13:52:36 2006
;; MSG SIZE  rcvd: 100
\end{verbatim}
\normalsize

Answer from NSD 3:

\footnotesize
\begin{verbatim}
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 26095
;; flags: qr aa rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; foo.bar.     IN      SOA

;; ANSWER SECTION:

;; AUTHORITY SECTION:
.       86400   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. (
	2006072801 1800 900 604800 86400)

;; ADDITIONAL SECTION:

;; Query time: 60 msec
;; SERVER: 127.0.0.1
;; WHEN: Wed Aug 23 13:53:30 2006
;; MSG SIZE  rcvd: 100
\end{verbatim}
\normalsize

\vspace{-8pt}\subparagraph{Analysis:}

BIND conforms to internet-draft draft-andrews-dnsext-soa-discovery which 
has at the moment of code development not (yet) been published as RFC. 
NSD conforms to the RFCs.


\subsubsection{b-classany-nxdomain - BIND gives an auth answer for class ANY nxdomain}
\label{b-classany-nxdomain}

A difference in behaviour for CLASS=ANY queries. For existing domains both
BIND and NSD reply with AA bit cleared. For not existing domains (nxdomain)
NSD replies with AA bit cleared. BIND replies with AA bit on and includes a
SOA (CLASS=IN) for the zone, as for an authoritative nxdomain.

Query:

\footnotesize
\begin{verbatim}
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 13328
;; flags: ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; nslabs.ruO.  ANY     MX
\end{verbatim}
\normalsize

Answer from BIND 9.3.2:

\footnotesize
\begin{verbatim}
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 13328
;; flags: qr aa ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; nslabs.ruo.  ANY     MX

;; ANSWER SECTION:

;; AUTHORITY SECTION:
.       86400   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. (
	2006072801 1800 900 604800 86400)

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; WHEN: Wed Aug 23 13:58:51 2006
;; MSG SIZE  rcvd: 103
\end{verbatim}
\normalsize

Answer from NSD 3:

\footnotesize
\begin{verbatim}
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 13328
;; flags: qr ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; nslabs.ruo.  ANY     MX

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; WHEN: Wed Aug 23 13:58:51 2006
;; MSG SIZE  rcvd: 28
\end{verbatim}
\normalsize

\vspace{-8pt}\subparagraph{Analysis:}

Feature of BIND where it answers authoritatively for CLASS ANY 
nxdomain queries.


\subsubsection{b-badquery-badanswer - BIND replies with bad answer for
                            some bad queries}
\label{b-badquery-badanswer}

BIND replies with an answer packet that cannot be parsed, or does
not answer at all. NSD always generates
an answer, with the appropriate RCODE (mostly NOTIMPL and FORMERR, but
also NXDOMAIN to NOTIFY queries). All these queries are malformed in 
some way. 

A (very simple) example of a query without an answer
is a query packet of 18 zero bytes. For some queries no answer
only happens when BIND is presented with a trace of queries, not for 
a single query.

\vspace{-8pt}\subparagraph{Analysis:}

BIND includes (part of) the unparseable question into the answer, or
some internal state of BIND is affected by earlier queries. 

NSD manages to answer the malformed query. Note that NSD does not answer 
queries that are too short, or that have the QR bit set. NSD tries to be
as liberal in what it accepts as possible.


\subsection{Functionality Differences}
\label{sec:funcdiff}

The next group of differences are due to the fact that NSD does not
implement some functionality that is requested by resolvers.  This 
is a design choice and should not cause resolver problems at all,
since responses to those requests are within protocol specs.


\subsubsection{d-notify - different NOTIFY errors}
\label{d-notify}

BIND and NSD give different errors for notify queries. The servers are started 
without any configuration for access control on notify. For notify messages 
aimed at a zone that is served, BIND 9.3.2 returns a NOERROR answer, and 
NSD 3 returns NOTAUTH. For notify messages on a zone that is not served 
(in-addr.arpa.) BIND 9.3.2 returns NOTAUTH and NSD 3 returns NXDOMAIN.

\vspace{-8pt}\subparagraph{Analysis:}

Default configuration differs between the two packages. NSD is more strict.
Error codes are different, the tools that send notifies are not affected.


\subsubsection{n-update - NSD does not implement dynamic update}
\label{n-update}

For UPDATE, you can get either REFUSED/NXRRSET/other RCODE from BIND 9.3.2 or 
NOTIMPL from nsd3.

\vspace{-8pt}\subparagraph{Analysis:}

NSD does not implement dynamic update. 


\subsubsection{b-mailb - BIND does not implement MAILB}
\label{b-mailb}

For MAILB, you can get either NOTIMPL(BIND 9) or NOERROR/NXDOMAIN(NSD 3).

\vspace{-8pt}\subparagraph{Analysis:}

BIND does not implement queries for the MAILB type. NSD treats it as 
one of the RRTYPEs. MAILB is obsoleted by RFCs, the MX type is 
used to transfer mail information now.


\subsubsection{d-version - BIND returns servfail on version.server queries}
\label{d-version}

NSD returns version.server query, BIND returns servfail.

\vspace{-8pt}\subparagraph{Analysis:}

Both NSD and BIND return version.bind queries of the chaos class.
These queries differ in the version number they return, of course.
BIND does not return version.server queries. This is a design decision
on the part of NSD to return version.server queries with the same answer.


\subsubsection{d-additional - Different additional section on truncated answers}
\label{d-additional}

NSD and BIND return different additional sections on truncated answers
to queries from the root. These answers are 480+ bytes long.

\vspace{-8pt}\subparagraph{Analysis:}

Not all the A and AAAA data fits into the additional section of the answer.
BIND includes different names than NSD does, and BIND is observed to sometimes
include one more AAAA record, less A records in the additional section.
Resolvers should be unaffected.


\subsubsection{d-refusedquery - BIND includes query section in REFUSED answers}
\label{d-refusedquery}

BIND includes the query sent for REFUSED answers. NSD replies with only
the DNS header section.

\vspace{-8pt}\subparagraph{Analysis:}

The resolver must inspect the query ID. The error code provides sufficient
information. Sending the header makes NSD replies smaller and thus more 
resilient to DoS attacks.


\subsubsection{d-hostname - BIND adds a NS record for hostname.bind}
\label{d-hostname}

BIND includes an additional RR in the authority section of the reply:
\footnotesize
\begin{verbatim}
hostname.bind. 0 CH NS hostname.bind.
\end{verbatim}
\normalsize

\vspace{-8pt}\subparagraph{Analysis:}

The RR seems useless. NSD does not include it.


\subsubsection{n-ixfr-notimpl - NSD does not implement IXFR}
\label{n-ixfr-notimpl}

To queries for IXFR BIND responds with a valid answer (the latest SOA)
and NSD responds with NOTIMPL error.

\vspace{-8pt}\subparagraph{Analysis:}

NSD 3.0.0 does not implement IXFR. It returns NOTIMPL by design.


\subsubsection{d-formerrquery - BIND includes query section in FORMERR answers}
\label{d-formerrquery}

BIND includes the query sent for FORMERR answers. NSD replies with only
the DNS header section. For some queries, NSD includes an EDNS record in 
the reply if there was a recognizable EDNS record in the query.

\vspace{-8pt}\subparagraph{Analysis:}

The resolver must inspect the query ID. The error code provides sufficient
information. Sending the header makes NSD replies smaller and thus more 
resilient to DoS attacks.


\subsubsection{d-badqueryflags - BIND includes query section in FORMERR answers}
\label{d-badqueryflags}

BIND includes the query section in reply to unparseable queries. NSD does not.

\vspace{-8pt}\subparagraph{Analysis:}

Same as d-formerrquery (\ref{d-formerrquery}), but the implementation of the comparison 
software could not parse the query either, thus a separate label.


\subsubsection{d-unknown-class - BIND includes query section in answers to unknown class}
\label{d-unknown-class}

For queries with an unknown class in the query, BIND includes the query section
in the answer. NSD does not.

\vspace{-8pt}\subparagraph{Analysis:}

Same as d-formerrquery (\ref{d-formerrquery}), but for a different error.


\subsubsection{d-unknown-opcode - NSD returns NOTIMPL for unknown opcode}
\label{d-unknown-opcode}

For queries that are bad packets, with malformed RRs, with an unknown opcode,
BIND returns a FORMERR, but NSD gives up after checking the opcode and
returns NOTIMPL.  NSD copies the flags from the query, and turns on the 
QR (query response) bit, BIND zeroes some of the flags.

\vspace{-8pt}\subparagraph{Analysis:}

NOTIMPL is appropriate since NSD does not implement whatever functionality
is being looked for. 


\subsubsection{b-upwards-ref - BIND returns root delegation}
\label{b-upwards-ref}

For queries to a domain that is not served, which can only have arrived at
this server due to a lame delegation, BIND returns a root delegation. NSD
returns SERVFAIL.

\vspace{-8pt}\subparagraph{Analysis:}

By design, NSD does not know the root-servers.  NSD is unable to reply as
the zone is not configured, hence the SERVFAIL. This is also discussed in
the REQUIREMENTS document for NSD.


\subsubsection{b-noglue-nsquery - BIND returns no glue for NS queries}
\label{b-noglue-nsquery}

For queries for the NS records of the zone, BIND does not include glue
for the NS records. NSD includes glue for the NS servers that lie within
the zone.

\vspace{-8pt}\subparagraph{Analysis:}

The glue saves a followup query.


\subsubsection{d-noquestion - different error on no question}
\label{d-noquestion}

For queries without a question section the error code differs.
NSD considers it a FORMERR. BIND returns REFUSED.

\vspace{-8pt}\subparagraph{Analysis:}

Error code not specified for this corner case. No problems for resolvers.


\subsubsection{b-uchar - BIND returns FORMERR on strange characters}
\label{b-uchar}

BIND returns FORMERR on strange characters in the query, such as
0x00, 0xff, 0xe4, 0x20, 0x40 and so on.

\vspace{-8pt}\subparagraph{Analysis:}

NSD does not give a formerr on these queries, it processes them.
NSD normalizes names to lower case. Otherwise leaves them untouched.
BIND preserves case in answers. Choice made in REQUIREMENTS for NSD,
also see RFC1035\cite{rfc1035} 2.3.3.


\section{Response differences between NSD 2.3.6 and NSD 3.0.0}

The differences between NSD 2.3.6 and NSD 3.0.0 are listed below. All are due
to version number changes and new features in NSD 3.


\subsection{Comparison of responses in root trace}

Differences between NSD 2.3.6 and NSD 3.0.0 for a root trace.
Note that apart from the 26 packets that are different, all responses are
binary the same on the wire between the two versions of NSD.

\begin{tabular}{lrr}
{\em difference}			& {\em packets} & {\em \%diff}	\\
n-notify (\ref{n-notify})               & 19 &  73.08\% \\
n-ixfr (\ref{n-ixfr})                   & 3 &  11.54\% \\
version.bind (\ref{nsd-version})       & 3 & 11.54\% \\
version.server (\ref{nsd-version})   & 1  &  3.85\% \\
Total number of differences:            & 26 &  100\% \\
Number of packets the same after normalization:&2244590 \\
Number of packets exactly the same on the wire:&2244590 \\
Total number of packets inspected:             &2244616 \\
\end{tabular}


\subsection{Comparison of responses in NL TLD trace}

Differences between NSD 2.3.6 and NSD 3.0.0 for a nl. trace.
Note that apart from the 311 packets that are different, all responses are
binary the same on the wire between the two versions of NSD.

\begin{tabular}{lrr}
{\em difference}			& {\em packets} & {\em \%diff}	\\
n-notify (\ref{n-notify}) 		& 289 & 92.93\% \\
version.bind (\ref{nsd-version}) 	& 22  & 7.07\% \\
Total number of differences: 			   & 311 	& 100\% \\
Number of packets the same after normalization:& 99689 \\
Number of packets exactly the same on the wire:& 99689 \\
Total number of packets inspected: 	&100000 \\
\end{tabular}


\subsection{Version number - version.bind and version.server}
\label{nsd-version}

To queries for version.bind and version.server the different implementations
return a different version number, as they should.

\vspace{-8pt}\subparagraph{Analysis:}

Expected. Correct version numbers are returned.


\subsection{n-notify - notify not implemented in NSD 2}
\label{n-notify}

Notifications are handled differently. NSD 2 returns NOTIMPL error code,
while NSD 3 returns NOTAUTH or NXDOMAIN error codes.

\vspace{-8pt}\subparagraph{Analysis:}

Default config denies all notify queries for NSD 3. These answers are correct
for non-existing and not authorized domains.


\subsection{n-ixfr - IXFR error FORMERR in NSD 2}
\label{n-ixfr}

To IXFR query questions different error codes are given. The NSD 2
gives FORMERR (due to the RR in the authority section). NSD 3 returns
NOTIMPL. 

\vspace{-8pt}\subparagraph{Analysis:}

Neither version of NSD implements IXFR. It is more appropriate to
return the NOTIMPL error code in that case. Bugfix in NSD.


\section{Response differences between BIND 8 and NSD 3.0.0}

In this section the response differences between BIND 8.4.7 and NSD 3.0.0
are categorized and analyzed. 


\subsection{Comparison of responses in root trace}

The differences between BIND 8.4.7 and NSD 3.0.0 when presented
with queries for the root zone are below.

\begin{tabular}{lrr}
{\em difference}			& {\em packets} & {\em \%diff}	\\
n-clrcdbit (\ref{n-clrcdbit})	&         516372 &84.39\% \\
d-hostname (\ref{d-hostname})	&         53431  &8.73\% \\
d-additional (\ref{d-additional})	& 32526  &5.32\% \\
b8-nodata-ttlminup (\ref{b8-nodata-ttlminup})	& 4611  &0.75\% \\
n-update (\ref{n-update})	&         1856  &0.30\% \\
d-version (\ref{d-version})	&         1033  &0.17\% \\
b8-auth-any (\ref{b8-auth-any})	&         519  &0.08\% \\
b8-badedns0 (\ref{b8-badedns0})	&         492  &0.08\% \\
d-unknown-class (\ref{d-unknown-class})	& 482  &0.08\% \\
b-badquery-badanswer (\ref{b-badquery-badanswer})	& 451  &0.07\% \\
b-class0 (\ref{b-class0})	&         97  &0.02\% \\
d-notify (\ref{d-notify})	&         18  &0.00\% \\
b8-ignore-tc-query (\ref{b8-ignore-tc-query})	& 6  &0.00\% \\
b8-badquery-ignored (\ref{b8-badquery-ignored})	& 4  &0.00\% \\
n-ixfr-notimpl (\ref{n-ixfr-notimpl})	& 3  &0.00\% \\
b-soattl (\ref{b-soattl})	&         1  &0.00\% \\
Total number of differences: 		&	 611902	&100\% \\
Number of packets the same after normalization:&1632714 \\
Number of packets exactly the same on the wire:&   2299 \\
Total number of packets inspected: 	       &2244616 \\
\end{tabular}


\subsection{Comparison of responses in NL TLD trace}

The differences between BIND 8.4.7 and NSD 3.0.0 when presented
with queries for the .nl zone are below.

\begin{tabular}{lrr}
{\em difference}			& {\em packets} & {\em \%diff}	\\
n-clrcdbit        (\ref{n-clrcdbit})         &           2857        &33.53\% \\
d-unknown-opcode  (\ref{d-unknown-opcode})   &           2692        &31.59\% \\
n-update          (\ref{n-update})           &           1283        &15.06\% \\
d-badqueryflags   (\ref{d-badqueryflags})    &            841        &9.87\% \\
d-hostname        (\ref{d-hostname})         &            531        &6.23\% \\
d-notify          (\ref{d-notify})           &            293        &3.44\% \\
d-version         (\ref{d-version})          &             22        &0.26\% \\
b-badquery-badanswer (\ref{b-badquery-badanswer}) &         1        &0.01\% \\
b8-badedns0          (\ref{b8-badedns0})     &              1        &0.01\% \\
Total number of differences: &8521 &100\% \\
Number of packets the same after normalization:&91479 \\
Number of packets exactly the same on the wire:&90837 \\
Total number of packets inspected:&100000 \\
\end{tabular}


\subsection{b8-nodata-ttlminup - BIND 8 uses minimum TTL from SOA also if bigger}
\label{b8-nodata-ttlminup}

For NXDOMAIN queries in root-servers.net BIND 8 uses the minimum TTL from
the SOA as the TTL of the included SOA RR. However, this minimum TTL is 
larger than the original TTL of the SOA, both NSD 2.3.6, NSD 3 and BIND 9
use the smaller of those two values as the TTL of the included SOA.

\vspace{-8pt}\subparagraph{Analysis:}

Bug in BIND 8 solved in BIND 9.


\subsection{b8-badquery-ignored - BIND 8 replies normally for some bad queries}
\label{b8-badquery-ignored}

BIND8 manages to reply for malformed queries. NSD replies with FORMERR.

\vspace{-8pt}\subparagraph{Analysis:}

The query is bad, formerr is needed. Fixed in BIND9.


\subsection{b8-badedns0 - BIND 8 ignores bad EDNS0 queries}
\label{b8-badedns0}

BIND 8 ignores queries with bad EDNS0 section. It answers the query.
NSD replies with FORMERR.

\vspace{-8pt}\subparagraph{Analysis:}

BIND8 is more liberal in accepting broken EDNS0 records. NSD is not.
Changed in BIND 9.


\subsection{b8-auth-any - BIND 8 includes an authority section on queries for ANY .}
\label{b8-auth-any}

BIND8 includes an authority section on queries for class ANY .
BIND9 and NSD return an empty authority section.

\vspace{-8pt}\subparagraph{Analysis:}

Fixed in BIND9.


\subsection{b8-ignore-tc-query - BIND 8 ignores the TC bit in queries}
\label{b8-ignore-tc-query}

BIND responds to queries that have the TC bit set. NSD gives FORMERR.

\vspace{-8pt}\subparagraph{Analysis:}

This is like the n-tcinquery (\ref{n-tcinquery}), except where BIND9 returns NXDOMAIN,
BIND8 returns the query with qr bit set. This is fixed in BIND9.
NSD is less liberal in accepting queries, it returns form error on queries with
the TC bit set.

\bibliographystyle{nlnetlabs}
\bibliography{allbib}

\end{document}