Re: [DNSOP] Batch Multiple Query Packet

[Alfred Hönes <[e-mail]>]

On 27 Feb 2012 13:35:45 -0500, Hector Santos wrote:
>
> I am interesting to find information about past or possible current
> interest regarding the support of a Batch single call of multiple
> query packets.
>
> If it doesn't already exist or not considered in the past as an
> unfeasible concept, I am interest in seeing if this is something
> worth pursuing.

Below are a few comments, and pointers to references, to my past,
humble contributions to a possible solution for the issue at hands.


In response to a draft that suggested a form of A+AAAA query type,
which was submitted/refreshed for the Hiroshima IETF meeting,
draft-li-dnsext-ipv4-ipv6-02, on 09 Nov 2009 I have submitted a
"more versatile proposal" to the DNSEXT WG's list [1], which was
only one possible variant (for brevity) for a "RR Group Query"
(RRGQ) to query for a group of RRtypes with the same QNAME and
QCLASS using an EDNS option to indicate the Data RRtypes wanted.
The distinguishing idea was to build in some kind of integrity of
RRsets using feedback signaling that allows to indicate empty RRsets
("nodata" indication per RRtype); caches that do not "know" the
entire RRset of an RRtype asked for do not send a partial RRset
but indicate that the response does not answer for such RRtype.
The initially posted single variant made use of a Pseudo-RRtype
as draft-li-dnsext-ipv4-ipv6, but another potential variant of
RRGQ that uses a traditiona Data RRtype in the query section
(plus the same EDNS option to indicate the desired Data RRtypes)
has been explained later, near the end of a follow-up message [2].

Among the possible applications motivating the proposal and mentioned
in the thread were DNSBLs and mail policy records (as you mention).
This proposal has been discussed on the list during the Hiroshima
IETF timeframe (see the thread started with [1], and shortly in the
DNSEXT session in Hiroshima.
However, unfortunately I never happened to fully write up this idea
as an I-D, but Ray Bellis' dnsext-multy-qtypes draft revives it now
(with some variation in the encoding of the EDNS option).

This solution -- although not "perfect" or "optimally coded" in the
present DNS protocol (with EDNS) -- might have the potential to
find enough traction to allow relatively fast deployment, eased
by its property that it has save fallback to traditional behavior
with servers that support EDNS0.  The obstacle to fast automatic
fallback with responders that do not support EDNS0 due to the rule
in RFC 2671[bis] that such responders MUST signal FormErr to query
messages carrying an EDNS OPT RR -- unlike in the case of unknown
EDNS options (that are to be ignored) is likely to be less of a
problem now, because the increase in response sizes expected, and
corresponding normative requirements to support EDNS0, for IPv6 and
DNSSEC, has lead to now widespread support for EDNS0.

So stakeholders interested in a tractable solution who do not want
to wait for some future "dns-ng" allowing this (and much more) in
some optimal way are invited to chime in and follow up in the
discussion of draft-bellis-dnsext-multi-qtypes on the dnsext list!


References to ancient messages on RRGQ -- once sent to the late
namedroppers list, and now archived in the dnsext list archive:
[1] http://www.ietf.org/mail-archive/web/dnsext/current/msg05291.html
[2] http://www.ietf.org/mail-archive/web/dnsext/current/msg05305.html
Please follow the entire thread to evaluate the raised point-of-views.

Recent messages on multi-qtypes :
    http://www.ietf.org/mail-archive/web/dnsext/current/msg12398.html
    http://www.ietf.org/mail-archive/web/dnsext/current/msg12403.html


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+