Subject: RFC 2782 (SRV RRs) Interop testing report

From: "Levon Esibov" <[email-masked]>
Date: Tue, 8 May 2001 14:44:07 -0700

Here is the update report on the RFC 2782 (SRV RRs) Interop testing.

Randy, Olafur, could you, please, take the appropriate actions to
advance draft-ietf-dnsext-rfc2782bis-00.txt to draft standard.

Thanks,
Levon.
This is the revised report on the RFC 2782 Interoperability Testing based
on the feedback from the IESG.

**********************************
What's new in this report:
1. List of ALL sections of the RFC 2782 with explanation on
whether every particular section needs to be tested.
2. Explanation of why single record per RRSet was used in the original
interoperability testing. Results of the testing with multiple records
per RRSet.

1. List of ALL sections of the RFC 2782 with explanation on
whether every particular section needs to be tested.

Most of the sections of the draft rfc2782bis require no interoperability
testing. These sections include:
  Applicability Statement
  Introductory example
  Domain administrator advice
  The "Weight" field
  The Port number
  Fictional example

The section "Usage rules" describes how an application SHOULD use SRV resource
records to locate the servers providing required service over specified protocol,
and how such application should choose a server in case if more than one server
is specified in the SRV resource record set. According to rfc2782bis, use of the
SRV records in the service location mechanism of a particular application must
be specified in the corresponding protocol specification.
Interoperability testing of the implementations supporting service location
mechanism based on the rules described in the "Usage rules" section should be
conducted within the testing of the implementations supporting relevant protocol
specification corresponding to a specific application, not the generic
specification of the SRV records, rfc2782bis.

The only section that required the interoperability section is "The format of
the SRV RR". The format of the records was verified by monitoring the network
traffic and by performing the tests described below.
Note: subsections "Priority" and "Weight" describe how application using SRV
records to locate a server should treat Priority and Weight values specified in
the SRV records. Interoperability testing of the implementations supporting
service location mechanism based on the rules described in the "Priority" and
"Weight" sub-sections should be conducted within the testing of the
implementations supporting relevant protocol specification corresponding to a
specific application, not the generic specification of the SRV records,
rfc2782bis.

2. Explanation of why single record per RRSet was used in the original
interoperability testing. Results of the testing with multiple records
per RRSet.

It was sufficient to demonstrate interoperability of the implementations
supporting SRV records using a SRV resource record set containing single record
because rfc2782bis doesn't specify the order in which multiple SRV record in a
record set should be returned to a caller.

To eliminate any concerns, the testing was repeated with multiple SRV resource
records in a resource record set:

Participated implementations
A	Microsoft Whistler DNS server, Beta 2 (build 2462)  (Levon Esibov)
B	BIND 9.1.1					    (Olafur Gudmundsson)

Date: April 4, 2001
Place: over the Internet. Server A was physically located in a Microsoft lab and
was connected to the Internet.

Test zones were srv.ind.test and srv-ogud.ind.test.
In addition to the SOA and NS records at the top of the zone, the zone srv.ind.test
contained the following records:
_ldap._tcp              SRV	0 0 389	target.srv.ind.test.
_ldap._tcp              SRV	1 0 389	target1.srv.ind.test.
_ldap._tcp              SRV	0 0 389	target2.srv.ind.test.
target                  A	1.2.3.4
target1                 A	1.2.3.5
target2                 A	1.2.3.6

In addition to the SOA and NS records at the top of the zone, the zone srv-ogud.ind.test
contained the following records:
kerberos                900	A	127.0.0.1
many                    900	TXT	( "Name with SRV larger RRset" )
_ns._tcp.many           900	SRV	0 0 30	ns30.srv-ogud.ind.test.
_ns._tcp.many           900	SRV	0 0 40	ns40.srv-ogud.ind.test.
_ns._tcp.many           900	SRV	0 2 50	ns250.srv-ogud.ind.test.
_ns._tcp.many           900	SRV	0 2 60	ns360.srv-ogud.ind.test.
_ns._tcp.many           900	SRV	3 2 50	ns3250.srv-ogud.ind.test.
_ns._tcp.many           900	SRV	3 2 60	ns3260.srv-ogud.ind.test.
ns250                   900	A	127.0.2.50
ns30                    900	A	127.0.0.30
ns3250                  900	A	127.3.2.50
ns3260                  900	A	127.3.2.60
ns360                   900	A	127.0.2.60
ns40                    900	A	127.0.0.40
one                     900	TXT	( "Name with SRV RRset that contains one record" )
_kerberos._tcp.one      900	SRV	0 0 88	kerberos.srv-ogud.ind.test.
_ldap._tcp.one          900	SRV	0 0 389	target.srv-ogud.ind.test.
target                  900	A	1.2.3.4

DNS server A was configured as primary server for the zone srv.ind.test.
and as a secondary server for the zone srv-ogud.ind.test.
The DNS server B was configured as primary server for the zone srv-ogud.ind.test.
and as a secondary server for the zone srv.ind.test.

The conducted test ensured proper transmission of resource records
of type SRV in a zone transfer from one server to another AND the ability
of the DNS servers to properly respond to the queries for the resource records of
type SRV.
After the primary and secondary zones were created on each of the DNS servers and after
zone transfers took place, NSLOOKUP tool installed on the Whistler Server
was used to send to the servers A and B queries for the resource records of type
SRV for the names _ldap._tcp.srv.ind.test., _ns._tcp.many.srv-ogud.ind.test.,
_kerberos._tcp.one.many.srv-ogud.ind.test. and _ldap._tcp.one.many.srv-ogud.ind.test. 

The responses from both servers contained all expected records in both cases:
when there is only one record and when there are multiple records in the specified
in the query RRSet.

The order of the records returned in the query response is irrelevant for the
interoperability testing of the RFC 2782 since this document doesn't require any
particular order of the returned records.

****************************************************************************

Below are the results of the original test conducted in Pittsburgh, PA in August 2000.

Tested RFC:
RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"

Date: August 1, 2000
Place: Double Tree Hotel, Pittsburgh, PA, USA.

Participated implementations
A	Checkpoint 8.2.3-t6b				(Kevin Dunlap)
B	Cisco CNR (build 353)				(Josh Littlefield)
C	ISC BIND 8.2.3-t6b				(Mark Andrews)
D	Lucent QIP 3.0					(Alexis MacFarlane)
E	Microsoft Windows 2000 DNS server		(Levon Esibov)
F	Microsoft Whistler DNS server (build 2253)	(Stuart Kwan)
G	Nominum BIND 9.1.0a				(Andreas Gustafsson)

Running on network 10.0.0.0/8.

Test zone was srv.ind.test.
In addition to the SOA and NS records at the top of the zone, the zone
contained the following records:
_kerberos._tcp          SRV	0 0 88	.
_ldap._tcp              SRV	0 0 389	target.srv.ind.test.
target                  A	1.2.3.4

DNS server E was configured as primary server for the zone srv.ind.test.
All other DNS servers (i.e. A, B, C, D, F and G) were configured as
secondary DNS servers for the zone srv.ind.test. with E DNS server as the
Master server for the zone.

The first round of tests ensured proper transmission of resource records
of type SRV in a zone transfer from one server to another AND the ability
of the DNS servers to respond to the queries for the resource records of
type SRV:
After every secondary DNS server was configured with DNS server E as its
Master for the zone srv.ind.test. and after zone transfers took place,
NSLOOKUP tool installed on the Windows 2000 Server was used to send to the
secondary servers (one at a time) queries for the resource records of type
SRV for the names _kerberos._tcp.srv.ind.test. and _ldap._tcp.srv.ind.test.
The responses from the secondary servers were verified to match the SRV
resource records specified in the primary copy of the srv.ind.test. zone.

The second round of tests ensured that the DNS servers properly store and
load SRV resource records:
Every secondary DNS server reloaded the secondary zone. Presence and
correctness of the DNS SRV recourse records was ensured by checking the
zone file containing the records and by repeating the set of the SRV
queries used in the first series of tests and verifying that the returned
in the query response records match the SRV records specified in the
primary copy of the zone srv.ind.test.

Finally, to ensure that the DNS server E that served as primary DNS server
in the interoperability testing (and therefore was not subjected to the
same testing as all other secondary servers) also passes the same tests,
it was configured as a secondary DNS server for the zone srv.ind.test.
with DNS server F being its Master. Then the same set of tests (as described
above) was applied to the DNS server E and it passed all the tests.

By monitoring network traffic it was verified that none of the DNS server
implementations use name compression in the target field of the RDATA of
the SRV resource records.

The conclusion of the participants of the interoperability testing:
The testing demonstrates full compliance of seven implementations of the
DNS servers with all requirements of the RFC 2782.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.