[dnsext] draft-li-dnsext-ipv4-ipv6 -- a more versatile proposal

Alfred Hönes <ah@TR-Sys.de> Fri, 06 November 2009 21:09 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325EA3A6870; Fri, 6 Nov 2009 13:09:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.84
X-Spam-Level: ***
X-Spam-Status: No, score=3.84 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aldYeXySiRVa; Fri, 6 Nov 2009 13:09:55 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 33CE53A6887; Fri, 6 Nov 2009 13:09:55 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1N6Vxh-00084l-7x for namedroppers-data0@psg.com; Fri, 06 Nov 2009 21:03:13 +0000
Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <A.Hoenes@TR-Sys.de>) id 1N6Vxd-00083m-Qp for namedroppers@ops.ietf.org; Fri, 06 Nov 2009 21:03:10 +0000
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA088691331; Fri, 6 Nov 2009 22:02:11 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA27842; Fri, 6 Nov 2009 22:02:06 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de>
Message-Id: <200911062102.WAA27842@TR-Sys.de>
Subject: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more versatile proposal
To: draft-li-dnsext-ipv4-ipv6@cabernet.tools.IETF.ORG, namedroppers@ops.ietf.org
Date: Fri, 6 Nov 2009 22:02:05 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

The recent I-D, "DNS Extensions to Support IPv4 and IPv6",
draft-li-dnsext-ipv4-ipv6-02, proposes a new specific QUERY TYPE
to pick up A and AAAA RRsets in a single DNS request.

This seems to be a specific solution restricted to a narrow,
yet frequent, desire / use case.

I suggest to expand on this proposal by defining a more versatile and
general mechanism that does not need to be changed again should any
new 'address' RRtype be defined in the future, and that will have
different other use cases for the pickup of 'grouped' RRsets
(e.g. TXT records together with PTR records on DNSBL lookups,
mail policy TXT RRs together with MX RRs, etc.).

This proposal is inspired by similar functionality present in DHCP
and an old, expired proposal to allow multiple queries in a single
DNS request.

It should help save round trips and eliminate the need to specify
dedicated additional section processing for some new RR types in
the future, saving additional, RR type specific processing logic in
authorities and caching resolvers.


Rough sketch of the idea:  << RR-Group Query >>

A new 'Query' RRtype, say "RGRP", is used to request the delivery
of an arbitrary set of 'data' RR types, specified in a bitmask --
similar to the one used in NSEC/NSEC3, but handed over in a new
EDNS option, say "RGMASK".

The semantics I envision for the authority/cache might be sketched
as follows:

-  CLASS-independent.

-  No Additional Section processing (beyond EDNS).

-  Any RRset matching (QNAME, QCLASS) with RRtype flagged in RGMASK
is returned -- similar to what is done for QTYPE=ANY queries with
a virtually restricted "set of interest", but more tightly controlled
as follows:

-  The RGMASK EDNS option is echoed back (iff the answerer understands
RGRP and this option).  Any bit still set in the echoed bit mask
indicates knowledge at the answerer of the corresponding RRset (with no
such RR present in the answer signalling per-RRtype selective NODATA);
clearing of a bit would indicate lack of knowledge of the corresponding
RRset and only be allowed only for cache servers, not for authorities.

-  It could be considered to use particular flag bit setting(s) to
request from a recursive resolver 'exhaustive' behavior, essentially
like an authority.

Rationale for using an EDNS option: It is expected that responses
to RGRP queries are larger and would generally benefit of increased
response size.  The proposal will only be implemented in "new" DNS
software that should support EDNS0 anyway.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+