Subject: chapter and verse: unknown type

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 07 Apr 2000 15:27:37 -0700

I'm looking for an explicit chapter and verse citation on the standard
behavior for the proper handling of an unknown resource record. IE, if a
client issues a query for some newly-defined type code 99, what is the
exact specific behavior that a server which is unaware of this code
should exhibit? Since there is probably a formatting rule associated
with the type, it can't just try to process it.

Similarly, if a client receives a response message with an unknown code
99, what is it supposed to do? Simply discarding the unknown code could
be dangerous since it may have some relevant impact on some other piece
of data.

I've looked through the various RFCs, but I may have missed it. If
anybody knows the relevant citation section off the top of their heads
I'd appreciate a clue.

Thanks

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com

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

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 Apr 2000 18:38:14 +1000

Date:        Fri, 07 Apr 2000 15:27:37 -0700
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | IE, if a
  | client issues a query for some newly-defined type code 99, what is the
  | exact specific behavior that a server which is unaware of this code
  | should exhibit?

It depends what role the server plays.   For an authoritative server for
the domain queried, it should just return a NXDOMAIN or "no error no data"
response, depending upon whether the name exists or not.   By definition,
if an authoritatve server for a domain has neevr heard of a RR type, there
cannot be any data of that type associated with the record.

A caching (non-authoritative) server should just forward the query to
an authoritative server, and then forward the answer it obtains back
to the client.   In theory it ought be able to also cache the answer,
and then return it again in response to later queries, but as there has
been a tendancy to do domain name compaction in newly defined RRs
that turns out to be a dangerous thing to do.   Probably now, assuming
that the server knows all the current record types, it could almost
cache the result, as we (the people who invent new RR types) have mostly
come to understand that compressed domain names cannot be used, or not
without explicit confirmation from the client (or cache) that it understands
the type and can handle compression.

  | Since there is probably a formatting rule associated
  | with the type, it can't just try to process it.

For an authoritative server, which is all where that would be relevant,
this makes little sense - if the server has been told that data exists
for the type, it must also have been told how to represent the data.

If a server were to receive a DNS update packet containing an unknown type,
it should probably just store the data as it received it, though I would
also expect that local server policy might have a switch to specify whether 
or not certain record types can be updated, and "unknown types" should be
one of those (so servers that aren't expecting to get new types will just
refuse to accept any nonsense clients might be tempted to send).

  | Similarly, if a client receives a response message with an unknown code
  | 99, what is it supposed to do?

Ignore it.   Clearly the client didn't ask for the unknown type (or it
could hardly be called unknown).

  | Simply discarding the unknown code could
  | be dangerous since it may have some relevant impact on some other piece
  | of data.

If we ever define new RR types in such a way that older RR types can
have their meaning altered in any way by the new one, then we will have
totally failed the community.   That would be a ludicrous thing to do.

Similarly a client which implemented one RR type, but not another, where
it was already defined that the other might have some impact on the first,
is simply broken, and deserves to suffer whatever danger comes its way.
An example of that wold be a client that didn't bother to understand CNAME
records - when requesting an A record, it might get a CNAME returned, and
an A record for the canonical name.   If it fails to understand CNAME, it
is going to break badly - but it deserves to.

A common example of just this happening (not badly defined RR types, or
badly designed clients, I mean RR types unknown to the client being returned)
is SIG records.  We expect that as DNSSEC is deployed amongst servers, and
more and more zones are signed, than clients will start receiving answers
with accompanying SIG records attached - we expect that clients that don't
understand DNSSEC (all of them I think at the minute) will simply ignore
the SIG record.   If we could not count upon that, we would never be
able to deploy any new RR type that could ever be returned without being
explicitly requested.

  | I've looked through the various RFCs, but I may have missed it. If
  | anybody knows the relevant citation section off the top of their heads
  | I'd appreciate a clue.

I didn't go looking, but I don't recall anything which explicitly states
any of this, most of it is just sort of obvious...

kre

---

From: [email-masked]
Date: Sat, 08 Apr 2000 15:36:40 +1000

You treat it as opaque data.  This is one of the reasons why
	new RRs are not allowed to use compression pointers so that
	the servers that don't know the contents don't need to look
	inside the RR data to cache and retransmit it.

	DNSSEC has made this a little bit harder in that you need to
	originally transmit the RR with domain names within the RR
	data downcased so that you can verify the signatures.  If we
	had been thinking correctly when DNSSEC was written we should
	have been only case folded domain names in the well known RR
	types as servers are supposed to preserve the case of domain
	names if possible.  The only reason for case changing today is
	as the result of using compression pointers and as new RR types
	don't have compression pointers it is easy to preserve case in
	the data sections.  In fact you have to go out of your way to
	change it.

	I can't remember if this was discussed in the early DNSSEC
	discussions or not but *not* downcasing domains in the data
	sections of *new* RR types when signing would solve some
	existing issues.

	Mark

--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 08 Apr 2000 13:42:48 -0700

Thanks for the comprehensive responses.

> I didn't go looking, but I don't recall anything which explicitly
> states any of this, most of it is just sort of obvious...

Most of the protocols that use options or codes explicitly state that
unknown types must be ingored, or prescribe some other form of behavior
like returning an explicit error. There doesn't appear to be a
definitive statement on the behavior for DNS, which is what I was
looking for, although the detailed responses are also appreciated.