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

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

Stuart Cheshire wrote:

> On 6 Nov 2009, at 13:35, Paul Vixie wrote:
>
>> the way to handle this is to include
>> AAAA as additional data in A responses, and include A as additional
>> data in AAAA responses.
>
>
> I agree. FWIW, this is exactly what we do in Multicast DNS:
>
> <http://tools.ietf.org/id/draft-cheshire-dnsext-multicastdns.txt>
>
> 8.2 Responding to Address Queries
>
>     In Multicast DNS, whenever a Responder places an IPv4 or IPv6 address
>     record (rrtype "A" or "AAAA") into a response packet, it SHOULD also
>     place the corresponding other address type into the additional
>     section, if there is space in the packet.
>
> In addition, if there isn't a record of one or other type, we indicate
> this using an NSEC record.

I also had this draft in mind.  But given the lack of acceptance of
these ideas (and other multi-question proposals) in the IETF this
did not seem a good base for a *new* proposal.

The drawbacks of Additional Data have become more and more evident
in the recent past, and Paul Vixie already has acknowledged that
in a follow-up message to Andrew's response to his posting.

There seems to be long established consensus that multiple questions (if
considered at all) need to be restricted to same-QNAME plus same-QCLASS.
Multiple Questions (QDCOUNT>1) incur the inherent problem that the
consistency needs to be checked, with many novel error scenarios.
Encoding a multi-question query in a way that inherently enforces
that match-in-QNAME-and-QCLASS restriction and is at least equivalent
(or even better) in terms of packet space requirements might turn out
to be a superior idea.

> This is for cases like where an SRV response has an A record in the
> additional section but no AAAA. Including the NSEC asserting the
> nonexistence of AAAA records saves us having to do another round-trip
> to get the no-answer-no-error response telling us that the name has no
> AAAA records.
>
>     In the event that a device has only IPv4 addresses but no IPv6
>     addresses, or vice versa, then the appropriate NSEC record SHOULD
>     be placed into the additional section, so that queriers can know
>     with certainty that the device has no addresses of that kind.

Additional Section processing for RR types that already do specify
that is entirely orthogonal to the problem considered and I would very
much prefer to leave it out of scope of this discussion.
There seems to have been consensus in the past that Additional Section
processing for new RR types should be avoided wherever possible.

>
> Stuart Cheshire <[e-mail]>
> * Wizard Without Portfolio, Apple Inc.
> * Internet Architecture Board
> * www.stuartcheshire.org

The problem with similar specifications is that they *change* existing
specifications in an incompatible way, making attempts to do so a
horrible cross-country ride in the IETF.  Adding new elements and
confining new behavior to these elements seems to be more appreciated
in general, because the interactions needed at layer 8 and above are
less difficult then.  :-)
Specific exceptional rules based on RR type are inflexible and a
burden for server implementations.  I have tried to find a way to
escape these complications.

Given the apparent interest in my proposal (only sketched so far in
coarse granularity), I'll try to write it up in an I-D ASAP -- but
please admit roughly 3 weeks due to pending other efforts.

There remain design choices -- e.g., new meta RR type plus RGMASK
EDNS option (as noted in my proposal), or RGMASK alone, combined
with any 'Data' RR type (omitted from the initial proposal for
brevity) --, and incremental deployment considerations need to be
pursued in detail.  Hints on other existing use cases for the
"RR Group Query" are welcome in the interim!


A related request I'd like to recall:  Could we please consider
in the EDNS0-bis effort a means to signal the intended behavior
regarding EDNS options that the queried server does not "know" (as
in several routing protocols and RSVP) ?  The most easiest way to
do so would be to assign semantics to 2 or 3 most significant bits
of the EDNS option type, thus leaving all legacy options untouched.
Useful encoded behavior would include "mandatory to support",
"ignore if unknown", "echo unchanged", etc.
This would be a small "one-change-forever" detail, but a big deal for
the incremental deployment of new EDNS options, such as the RGMASK
proposed for RR Group Queries.  (See also the IAB deliberations on
protocol extensibility in draft-iab-extension-recs.)

More thoughts on this detail soon in a specific note on
draft-ietf-dnsext-rfc2671bis-edns0.


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