[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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