Re: EDNS1

[Robert Elz <[e-mail]>]

    Date:        Tue, 09 Oct 2001 09:19:37 -0700
    From:        Paul A Vixie <[e-mail]>
    Message-ID:  <[e-mail]>

  |    2 - Affected Protocol Elements

I'd like to see ...

    2.4.  Only a subset of DNS RR types support compression of labels in
    the RDATA, as explained in [...whatever that new draft is...].  Where
    it is known that the requestor, and the server, both recognise other
    RR types, and so can locate labels in the RDATA, and decompress them,
    name compression can be permitted in the RDATA of additional RR types.

added, and then:

  |    4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags
  |    are structured as follows:
  | 
  |                     +0 (MSB)                            +1 (LSB)
  |          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  |       0: |         EXTENDED-RCODE        |            VERSION            |
  |          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  |       2: |MD |FM |RRD|LM |XC |                   Z                       |
  |          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  | 
       XC		If set to 1 by the sender, then the sender understands
			label compression in the extended set of RR types as
			defined for the VERSION specified.   If set to 1 in
			a response, the server indicates that it is able to
			compress labels for the extended set of RR types as
			defined for the VERSION specified.   Any label
			compression scheme defined by the DNS for the EDNS
			VERSION agreed between sender and responder may be used.

and then add a new section (6) below (and renumber those that were 6, 7, 8
into 7, 8, 9, of course)

    6.  Extended Label Compression RDATA RR types

	Any DNS system that supports extended compression (sets the XC
	bit in the OPT RR) and supports EDNS version 1, must support
	label compression in all domain names included in the RDATA of
	the followingRR types, as well as all of those defined by RFC1035.

	NXT (rfc2535) SRV (rfc2782) A6 (rfc2874) TKEY (rfc2930)
	NAPTR (rfc2915) TSIG (rfc2845) DNAME (rfc2672) KX (rfc2230)
	PX (rfc2163) AFSDB (rfc1183) RP (rfc1183)

(OK, including the algorithm "domain name" from TKEY and TSIG might
be going a bit overboard, deleting those from this list wouldn't harm
a lot I don't think).

If I missed any that should be added, then add them...  (if any of those
I found are so obsolete that no-one will ever use them, then we should
drop them from the list, so as to avoid requiring people to support rubbish).

I know NXT allows compression anyway, according to 2535 anyway, though
I'm not sure that is really appropriate ... it is intended to only be used
between servers that understand it, but I'm not sure how that is actually
enforced.   In any case, explicitly specifying it to be OK for EDNS1 can't
hurt.

(continuing the above section to be inserted...)

	A DNS server capable of compressing the domain labels in the
	RDATA of all of the RR types listed above (plus all of the
	RR types defined to support compression in rfc1035) MAY set the
	XC bit in the OPT RR in responses it sends that include that RR,
	where the version indicated as supported is 1.   If support for
	a higher version number is available, the XC bit MUST NOT be set
	in responses unless any additional RRs defined for that EDNS
	version are also supported.

	In any case, a server MUST NOT compress labels for any of the above
	RR types, unless it is responding to a query received containing an
	OPT RR with the XC bit set, and a version of at least 1.
	When responding to a query wich was received with the XC bit set
	in an included OPT RR which has a version of 1 or greater, the
	server MAY compress labels in the above RR formats using any
	compression scheme available to be used in the EDNS version applicable.

	Domain names in the RDATA field of RR types not listed here, or in
	rfc1035, or in the specification of some later EDNS version agreed
	between sender and server, MUST NOT be compressed.

Aside from that, I'd fix ...

  |    5.4. If iteratively processing a multiple question request using an
  |    authority server which can only process single question requests, if any
  |    contributing request generates a SERVFAIL response, then the final
  |    response's RCODE should be SERVFAIL.

to be
	5.4. If iteratively processing a multiple question request using an
	authority server which can only process single question requests, if any
	contributing request generates only a SERVFAIL response, then the final
	response's RCODE should be SERVFAIL.

That is, if there are 2 auth servers listed for a QNAME, the intermediate
server tries one, and gets SERVFAIL, but then tries the other, and gets all
the answers it needs, it shouldn't be setting SERVFAIL in the response, only
if it is unable to get an answer to one of the questions from any of the
auth servers for the QNAME (that it chooses to try).

  |    7 - References

Most of the ones in this list that were drafts are RFCs now...

except ...

  |    [KOCH98]   P. Koch, ``A New Scheme for the Compression of Domain
  |               Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt.

which seems to have vanished completely.  If it isn't coming back, the
reference, and the label code tentatively allocated for it, need to go
as well.

kre



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