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

Stuart Cheshire <cheshire@apple.com> Sat, 07 November 2009 05:40 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 C65ED3A685D; Fri, 6 Nov 2009 21:40:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.495
X-Spam-Level:
X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 LAJ6e8kRPu6g; Fri, 6 Nov 2009 21:40:22 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76C043A67D7; Fri, 6 Nov 2009 21:40:22 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1N6dvT-0003FF-E8 for namedroppers-data0@psg.com; Sat, 07 Nov 2009 05:33:27 +0000
Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <cheshire@apple.com>) id 1N6dvP-0003Eg-Jb for namedroppers@ops.ietf.org; Sat, 07 Nov 2009 05:33:23 +0000
Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 781067E81E3E for <namedroppers@ops.ietf.org>; Fri, 6 Nov 2009 21:33:22 -0800 (PST)
X-AuditID: 11807134-b7cd9ae000001002-8f-4af506a29e24
Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay14.apple.com (Apple SCV relay) with SMTP id B4.4A.04098.2A605FA4; Fri, 6 Nov 2009 21:33:22 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Received: from host-112-143.meeting.ietf.org (host-112-143.meeting.ietf.org [133.93.112.143]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KSQ0066Y4RK3T10@gertie.apple.com> for namedroppers@ops.ietf.org; Fri, 06 Nov 2009 21:33:22 -0800 (PST)
Cc: Alfred HÎnes <ah@TR-Sys.de>, draft-li-dnsext-ipv4-ipv6@cabernet.tools.IETF.ORG, namedroppers@ops.ietf.org
Message-id: <38CCBAA1-1814-4BFE-B0DD-F8549B1E66CB@apple.com>
From: Stuart Cheshire <cheshire@apple.com>
To: Paul Vixie <vixie@isc.org>
In-reply-to: <89274.1257543356@nsa.vix.com>
Subject: Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more versatile proposal
Date: Fri, 06 Nov 2009 21:33:19 -0800
References: <200911062102.WAA27842@TR-Sys.de> <89274.1257543356@nsa.vix.com>
X-Mailer: Apple Mail (2.936)
X-Brightmail-Tracker: AAAAAQAAAZE=
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/>

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.

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.

Stuart Cheshire <cheshire@apple.com>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org