Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt

Richard Gibson <> Wed, 20 September 2017 23:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F419132396 for <>; Wed, 20 Sep 2017 16:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XQG9WO0ZAyyr for <>; Wed, 20 Sep 2017 16:47:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::246]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 010EF1321BB for <>; Wed, 20 Sep 2017 16:47:08 -0700 (PDT)
Received: by with SMTP id 72so3504684uas.7 for <>; Wed, 20 Sep 2017 16:47:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kRvolV98sa6tQD4BuSMGYuC2X7k1tYx2jVtWrGDIZTo=; b=pKwTIDmEGD1I0N7BLx0jK04gAtGxiYBIuxaYXPXhPIf3dk4LZ0Mq+nn/1g4/Ay4Qg0 rMw2ewSNm8V8LI/tWBPUh+BvDVzD60bx1VzTRLz2ZkcesUMBzfsrGo7/RJ+ZOOC6I6Ih h5zl3JxYYIIKHV+XMyWvfRKWkxWiAI4abCGuM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kRvolV98sa6tQD4BuSMGYuC2X7k1tYx2jVtWrGDIZTo=; b=KKNGIFiS3bCKzbpWjSmAWV7Ytc/cfZ57QLu6/GY/s3jw2TGTW0fJBQZy64s2Vu8g6t erXUd+Bm1+wNe03VEwayJp+J9F2Kc53OV3Feti+126WmtRuSk8pQFfyveDFO4J8D02M2 PqmMRxoCEyXr9RNWvHfZ4HMIHoI4ZIYRo12s6Nk95FuL4ssAuDQJYk41knWVOvpIacWR mozQOck2Ljf7YSPl5znDz3fbSrGKC/wNedxGZiXFy1nQ0/wVLaC8A9lit8+jMS/4ZF0c QQmmlm85ruM7ERELJq16StWzXoZ+5oKnf/Q4F3QQKHolh0IEzSgz+WSKkhUex5ExMJu0 l9Zg==
X-Gm-Message-State: AHPjjUjx+V/w1mZKvxBeIEfnMOcHVuABfL3/uwVQ5kKO2gGZ4410Ddug AZ/a3A2c6PQl79Srh7dT4zhKKVLLYUt0u2VnYAq3Z9F6aOw=
X-Google-Smtp-Source: AOwi7QAiC/KPjvCz5zGXXvS39FMNf8f6JGpBcEfUy/ifnuleWRRPYHMlO1SURS3ZHlQR68duykfu+ACcux8AOi6KdNw=
X-Received: by with SMTP id t15mr302766vke.155.1505951227056; Wed, 20 Sep 2017 16:47:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 20 Sep 2017 16:46:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Richard Gibson <>
Date: Wed, 20 Sep 2017 19:46:46 -0400
Message-ID: <>
To: yaojk <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="001a11432250f02a3b0559a7977a"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Sep 2017 23:47:10 -0000

On Wed, Sep 20, 2017 at 3:45 AM, Jiankang Yao <> wrote:

> *From:* Richard Gibson <>
> *Date:* 2017-09-19 10:48
> *To:* dnsop <>
> *Subject:* Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-
> questions-04.txt
> In a more general sense, how are responders to generate—and how are
> initiators to interpret—responses in which it is not clear which question
> any given response record corresponds to?
> *[Jiankang Yao]*
>    The responders will put the query result of main question first,
> then Accompanying Question 1, Accompanying Question 2 in the answer,
> authority or additional section. It means that the responders will put the
> results for main question first, then Accompanying Question 1, Accompanying
> Question 2, one by one in order.
Ah, so the response is expected to include *duplicate* records when they
answer multiple questions (e.g., in the case of NXDOMAIN and NODATA
results)? That's worth making explicit (e.g., rewording "the SOA resource
record will be put in the authority section" in section 4). And I believe
it also calls for guidance instructing responders to reject question sets
that include duplicates or special QTYPES (AXFR/IXFR/ANY), including a
description of *how* to reject (e.g., AQ-RCODE=REFUSED).

> Why require accompanying question names to match or be subdomains of the
> QNAME? It precludes potentially useful queries like
> accompanied by, and prohibiting them doesn't
> prevent out-of-bailiwick queries anyway.
> *[Jiankang Yao]*
> currently the use cases for accompanying questions are the same domain
> names with different typs (A and AAA) or different sub domain names (TLSA
> record:  ).
> If we can find some strong use cases for  queries like QNAME=
> accompanied by, we may
> consider to adjust the design.
 I don't think you need to adjust the design, just strike "The domain name
for accompanying questions MUST be same with the domain name for a main
question or be children name of it" from section 3.

Your response did get me thinking about name compression, though. RFC 3597
section 4 <> states "Future
specifications for new RR types that contain domain names within their
RDATA MUST NOT allow the use of name compression for those names", and I
don't think that should be tossed aside lightly. If they truly are to be
allowed in EDNS0 options (which may already be a mistake), I think that
they MUST be required to point into the first QNAME of the message.