Subject: How does a sever for child answer a DS query.

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 10 Sep 2002 16:15:12 -0400 (EDT)

The following is based on some observations at the DS workshop
at ISI/East. The issue is: what should DS aware authorative servers
return/do in different cases, currently the draft under-specifies what
the responses in certain cases.

The under-specification affects servers that are authorative for the
child and the query is for DS record at apex.
Here are the different cases that need to be considered by the DS document,
server is:
1. Authorative: for both parent and child
   Recursion:   <does not matter>
   RD bit:      <does not matter>
   Answer:      if DS exists in parent
                   it is returned with AA bit set.
                if no DS in parent
                   Rcode= NOERROR
                   Answer section: <empty>
                   Authority section:  SOA
                                       NXT if AD bit is set in query

2. Authorative: child only
   Recursion:   Not allowed
   RD bit:      <does not matter>
   Answer:      <needs specification>

3. Authorative: child only
   Recursion:   Allowed
   RD bit:      not set
   Answer:      <needs specification (same as in #2?)>

4. Authorative: child only
   Recursion:   Allowed
   RD bit:      SET
   Answer:      if answer in cache
                  return it without AA bit
                else
                  perform recursion

At least one of the authorative servers used at the workshop returned
a referral to a zone above the QNAME. This caused some common
resolvers to mark the server as LAME.  If all the servers for the zone
have this behavior the zone can be made to disappear.

DS is the first real record that can only exist at the parent thus
this issue has never been explored.

In the early years of DS deployment non DS aware resolvers/caches will
blindly send DS queries to the child servers, thus is it important
that the answer returned have no negative implications for future
queries for records from the child zone.

At the DS workshop we performed a test of number of possibilities and
tested them against number a available DNS cache programs:
       Bind-4.9.9
       Bind-8.3.3
       Bind-9.2.2rc2
       Bind-9.3-<snapshot)
       Djbdns-1.0.5 DNScache program
       Vendor X, Unreleased Cache software.
       Windows 2K server (not sure version)

Following is a list of of the the possible answers that where tested
from a DS capable server.

Test name    AA     RCODE       Returned data
Noauth.      off    NOTAUTH     ans:  empty
                                auth: empty
referdown    on     NOERROR     ans:  empty
                                auth: NS for referdown

Noanswer     on     NOERROR     ans:  empty
                                auth: empty

refused      off    REFUSED     ans:  empty
                                auth: empty

Nodata       on     NOERROR     ans:  empty
                                auth: SOA

Note: Nodata is identical to what some existing servers return.

Each test was had 2 authorative servers with 3 different setups
     DS     two modified servers
     Mixed  one modified server, one Bind-9.2.1 server
     Not    two Bind-9.2.1 servers.
Each authorative server had recursion disabled.

The tests where run on a local network with no outside connectivity,
with a local root server.
The tests needed 3 runs to eliminate all setup errors
Each test + setup was given a unique name
     <setup>.<test>.

The DS capable server was a specialized server hacked up in about
1 hour by Brian Wellington using DNSjava, that returned different
answers depending on the right most label in the query name.

Test procedure:
     start root server
     start authorative servers
     start caches
     for each cache
         for each test
             for each setup
                   dig @cache  <setup>.<test> ns
                   dig @cache  <setup>.<test> ds
                   dig @cache  findme.<setup>.<test> txt
             end
          end
     end

If findme.<setup>.<test> was not found then that return code/value
from the DS server will have bad effect during DS transition.
The caches below appear in random order, but vendors know which one
of the column is their implementation.

ds.notauth           OK OK OK       OK OK SERVFAIL OK
mixed.notauth        OK OK OK       OK OK       OK OK
not.notauth          OK OK OK       OK OK       OK OK

ds.referdown         OK OK OK SERVFAIL OK SERVFAIL OK
mixed.referdown      OK OK OK       OK OK       OK OK
not.referdown        OK OK OK       OK OK       OK OK

ds.noanswer          OK OK OK       OK OK       OK OK
mixed.noanswer       OK OK OK       OK OK       OK OK
not.noanswer         OK OK OK       OK OK       OK OK

ds.refused           OK OK OK       OK OK SERVFAIL OK
mixed.refused        OK OK OK       OK OK       OK OK
not.refused          OK OK OK       OK OK       OK OK

ds.nodata            OK OK OK       OK OK       OK OK
mixed.nodata         OK OK OK       OK OK       OK OK
not.nodata           OK OK OK       OK OK       OK OK

	Olafur

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>