Subject: indicating data/nodata simultaneously

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 23 Nov 2003 23:13:00 -0600

On the subject of trying to provide answer data along with an indicator
that some other data does not exist... After some thinking, it seems like
it would be pretty simple to patch the qtype=addr proposal to handle this.

Since the original proposal already requires intermediary servers to chase
down the A and AAAA RRsets to ensure that all of the data is being
provided, supporting servers can already provide the necessary clues: if
the question section of the response message shows qtype=addr, then any
missing RRsets in the answer section are actually missing from the zone,
or else they would have been found as part of the discovery process (in
the case of authoritative servers responses, you'd even have proof
positive by way of the A flag). So since we're that far already, really
the only part that's actually missing here is to provide negative cache
timers for the missing RRsets, so that the complete answer (including any
known data as well as known missing data) can be cached and reused,
without causing all subsequent queries to non-authoritative servers to
re-query the authoritative servers to find out for sure.

The easiest way to deal with this is to mimic the Type 1 NODATA response
as described in RFC 2308. Specifically:

   1) if the question section contains qtype=addr

      -and-

   2) if the RCODE is set to NOERROR

      -and-

   3) if the answer section is missing one or both of A/AAAA RRsets

      -and-

   4) the authority section contains an SOA RR of the controlling zone

      -then-

   treat the answer as complete, and cache the provided and missing
   data according to the existing rules

In that scenario, the full view of the data could be provided, cached,
relayed and processed by any compliant system in the query path.

The complexities start when the Type 2 and 3 NODATA responses are
encountered in response to independent queries for one or both address
types, as will particularly be the case with authoritative servers that
don't support qtype=addr. Although it's possible to reuse some of the
logic from RFC 2308 here, I think it might actually be easier to just
require implementations to explicitly query for the SOA RR if they find
themselves in this situation.

The upside to this approach is that this would guarantee complete answers
were formed and relayed throughout the query path. The downside is that a
compliant caching server would have to generate three distinct queries if
the chosen authoritative server doesn't support qtype=addr and doesn't
provide a Type 1 NODATA response to either of the discrete A or AAAA
lookups. However, since that approach would allow the negative data to be
cached and relayed, this should in theory result in fewer overall queries
than providing no hinting data whatsoever (the current situation), so even
in the worst case it should still be cheaper than not provide any cachable
hinting data.

I can write this into an update of the draft unless anybody sees anything
totally stupid about it.

btw--the old qtype=addr draft expired long ago, but there's a copy online
at http://www.ehsco.com/misc/draft-hall-qtype-addr-00.txt

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

--
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/>