Subject: DNS Orlando Interop Testing minutes

From: Jeff Schreiber <[email-masked]>
Date: Fri, 18 Dec 1998 08:16:11 -0400

08-Dec-1998	DNSIND Interoperability testing.

Observers and Loggers: Jeff Schreiber, Bob Halley, Mark Andrews
Testing Coordinator: Olafur Gudmundsson

A) Internet Software Consortium - David Lawrence
	BIND 8.1.2 (BSD/OS) Notify Client & Server
	BIND 8.1.2 (BSD/OS) DynUpd Client & Server
B) Microsoft - Stuart Kwan [email-masked] [email-masked]
	NT Notify Client & Server
	NT DynUpd Client & Server
	NT IXFR   Client & Server
C) Metainfo - Kevin Dunlap 
	NT Notify Client & Server
	NT DynUpd Client & Server
D) TISLabs - Brian Wellington [email-masked]
	BIND 8.2 (Linux) Notify Client & Server
	BIND 8.2 (Linux) DynUpd Client & Server
E) Olafur Gudmundsson
	Linux DynUpd Client

Running on network 10.1.2.0/8

Microsoft running root server.

Set up zone ind.test, in which delegations to individual vendors were
created:
	isc.ind.test
	msft.ind.test
	metainfo.ind.test
	tis.ind.test

Each vendor served as a primary master for their 'vendor zone'.

Each vender then created 2 subzones ('vendor subzones') to serve as 
primary masters for in each vendor zone:
	dyn.<vendor>.ind.test
	notify.<vendor>.ind.test

Each vender created slave zones for all the other 'vender subzones', with 
their master being the primary master.

NS records the slave servers and the primary server were added to each 
vendor subzone.

Due to networking and configuration difficulties, setup took upwards
of 1.5 hours.

- Impl-D sent update A record to notify zone from self to self.  Impl-D
  issued NOTIFY to secondaries on Impl-A, Impl-B, and Impl-C

- Impl-B sent update to Impl-D vendor zone.  Impl-D responded with REFUSED
- Impl-B sent update to Impl-D dyn zone with prereq section requiring
  a non-existant A record to exist.  Impl-D responded with NXRRSET
- Impl-B sent update to Impl-D dyn zone.  Impl-D responded with NOERROR,
  zone was updated.
- Impl-B sent update to Impl-D dyn zone with txt record.  Impl-D responded
  with NOERROR.  Zone was updated
- Impl-D updated serial number on Impl-D dyn zone.

    At this point in the testing, it was determined that the NOTIFY packets
    and actions from within the dyn domains was confusing the testing
    results.  dyn zones changed to not send NOTIFY requests.

- Impl-C update add to Impl-A dyn zone.  Impl-A responded with NOERROR, zone
  was updated
- Impl-B update add to Impl-D dyn zone.  Impl-D responded with NOERROR, zone
  was updated
- Impl-C update delete non-existant record to Impl-A dyn zone.  Impl-A 
  responded with NOERROR.  Zone was not changed (Silent Ignore)
- Impl-B update delete non-existant record to Impl-D dyn zone.  Impl-D 
  responded with NOERROR.  Zone was not changed (Silent Ignore)
- Impl-D update add to Impl-B dyn zone.  Impl-B responded with NOERROR, 
  zone was updated
- Impl-D update delete existing record to Impl-B dyn zone.  Impl-B
  responded with NOERROR.  Zone was updated
- Impl-D update delete non-existant record to Impl-B dyn zone.  Impl-B
  responded with NOERROR.  Zone was not changed (Silent Ignore)
- Impl-C update delete existant record to Impl-A dyn zone.  Impl-A
  responded with NOERROR.  Zone was changed.

- Impl-C to update an A record to Impl-A.
- Impl-C to update a CNAME record to Impl-A of the same owner as A record.
- Impl-A dyn zone contains both A and CNAME record.  Impl-A knows this
  is incorrect

- Impl-D to update an A record to Impl-B
- Impl-D to update a CNAME record to Impl-B of the same owner as A record.
- Impl-B silently ignored CNAME record (correct)

- Impl-C to update a SOA record w/ higher serial (45) to Impl-A.  NOERROR
  response, zone changed.  (correct)
- Impl-C to update a SOA record w/ lower serial (12) to Impl-A.  NO ERROR
  response, zone not changed (silent ignore).  (correct)

    At this point, some testers went off to interoperate with video games.
    It was found that the Microsoft implementation was the most accurate.

    At this point, there was a debate to the nessessity of duplicating the
    LA interperability test, since those issues found have already been
    brought to the attention of the WG, and some vendors have not fixed
    those implementation issues since March.  Interoperability tests will
    be run over the Internet to revisit the LA Tests when testers have
    more time and are ready.

Section 6 describes forwarding of update requests from a slave server to 
    it's master.  There was only one implementation of a server that
    will forward dynamic update packets, so this section went untested.

Section 7.6 - delete of SOA RR
- Impl-C attempts to delete SOA RR from Impl-A's zone.  Impl-A silently
  ignores.
- Impl-A attempts to delete SOA RR from Impl-B's zone.  Impl-B silently 
  ignores.

*** What should the effect be?
    If someone tries to delete an SOA record, it says you shouldn't be
    able to do that.  Testers propose the response should be FORMERR 
    for lack of a better error code.  SERVFAIL, NOTIMPL would both be
    removed from the list because of section 4.6.  REFUSED wouldn't be
    acceptable, because that would be misleading.  It's not policy or
    security, so it's a bad result.  It's different between refused by
    policy and refused because it's an impossibility.

    The question is:  Should things that are not valid (CNAME and other 
    Data, removing last NS from zone top, removing/adding SOA records) be
    silently ignored?  Should clients be led to believe that it worked
    when it didn't, and _NEVER_ will?

- Impl-D attempted to add delegation NS record to Impl-B.  Success
- Impl-D attempted to delete delegation NS to Impl-B.  Success
- Impl-D attempted to delete NS from top of Impl-B dyn zone.  Success

- Impl-E attempted to delete an NS from top of Impl-B dyn zone (not last
  NS record).  Success
- Impl-E attempted to delete last NS from top of Impl-B dyn zone.
  Success. This result is incorrect.
- Impl-E added one NS record to top of Impl-B's zone.  success
- Impl-E deleted each NS record (one at a time) from Impl-B's zone
  except the one NS RR that was added.

- Impl-E attempted to delete 1 of 4 NS from top of Impl-D's zone.  NOERROR,
  no modification to zone (Silent Ignore).  This is incorrect.
- Impl-B attempted to delete 1 of 4 NS from top of Impl-D's zone.  NOERROR,
  no modification to zone (Silent Ignore).  This is incorrect.
- Impl-E attempted to delete all NS from zone top of Impl-D's zone.
  NOERROR, no modification to zone (Silent Ignore).  This is correct.
- Impl-B attempt to add SOA (not at zone top) to Impl-D. Silent Ignore.
  This is correct.
- Impl-D attempt to add SOA (not at zone top) to Impl-B. REFUSED.  This
  is Incorrect.

---

From: Andras Salamon <[email-masked]>
Date: Mon, 21 Dec 1998 10:07:52 +0200

> 08-Dec-1998	DNSIND Interoperability testing.

Does one of the participants have a short precis of the minutes?  I'm
obviously missing something crucial, for I drew the overall conclusion
that all the implementations are pretty flaky at this stage (including
BIND).  Can anyone improve on this?

-- Andras Salamon                   [email-masked]
-- DNS Resources Directory          http://www.dns.net/dnsrd/