[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 | +------------------------+--------------------------------------------+
- [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more vers… Alfred Hönes
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … Matthew Dempsky
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … Paul Vixie
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … Andrew Sullivan
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … Alfred Hönes
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … Paul Vixie
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … Masataka Ohta
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … Stuart Cheshire
- [dnsext] Re: draft-li-dnsext-ipv4-ipv6 -- a more … Stephane Bortzmeyer
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … Andras Salamon
- [dnsext] Re: draft-li-dnsext-ipv4-ipv6 -- a more … Stephane Bortzmeyer
- [dnsext] Re: draft-li-dnsext-ipv4-ipv6 -- a more … Andras Salamon
- [dnsext] Re: draft-li-dnsext-ipv4-ipv6 -- a more … Stephane Bortzmeyer
- RE: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … mohamed.boucadair
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … Alfred Hönes
- [dnsext] Re: draft-li-dnsext-ipv4-ipv6 -- a more … Stephane Bortzmeyer
- [dnsext] RE: draft-li-dnsext-ipv4-ipv6 -- a more … mohamed.boucadair
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … Paul Vixie
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … bmanning
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … Paul Vixie
- Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more … Ted Lemon
- [dnsext] Re: draft-li-dnsext-ipv4-ipv6 -- a more … Stephane Bortzmeyer
- Re: [dnsext] Re: draft-li-dnsext-ipv4-ipv6 -- a m… John Levine
- [dnsext] Re: draft-li-dnsext-ipv4-ipv6 -- a more … Stephane Bortzmeyer