Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis

"Paul Hoffman" <paul.hoffman@vpnc.org> Sun, 22 April 2018 20:00 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24D6126D3F for <dnsop@ietfa.amsl.com>; Sun, 22 Apr 2018 13:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOV6hsUCQSD0 for <dnsop@ietfa.amsl.com>; Sun, 22 Apr 2018 13:00:36 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FA6126CC7 for <dnsop@ietf.org>; Sun, 22 Apr 2018 13:00:36 -0700 (PDT)
Received: from [10.32.60.37] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w3MJxnWO041889 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 22 Apr 2018 12:59:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.37]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Matthijs Mekking <matthijs@pletterpet.nl>
Cc: dnsop@ietf.org
Date: Sun, 22 Apr 2018 13:00:33 -0700
X-Mailer: MailMate (1.11.1r5471)
Message-ID: <224D06C2-F9EC-42C6-A656-BCB50AAE7C97@vpnc.org>
In-Reply-To: <22fe4a5c-fcd5-50fd-71da-d714d8f31fe5@pletterpet.nl>
References: <7C873271-A784-4594-91A3-48C697EEC613@vpnc.org> <22fe4a5c-fcd5-50fd-71da-d714d8f31fe5@pletterpet.nl>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VllfxgMVcju5_E_1zIExiTOe6oU>
Subject: Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Apr 2018 20:00:37 -0000

On 19 Mar 2018, at 5:21, Matthijs Mekking wrote:

> Negative response:
>
> I and some others have been using the term 'Negative response' to 
> indicate that the response does not contain any records in the Answer 
> section. Current definition seems to imply that this is only the case 
> if the RCODE is NXDOMAIN, NOERROR, SERVFAIL or if there was a timeout 
> (unreachable). The definition I have been using includes responses 
> with other RCODEs too, for example FORMERR or REFUSED.
>
> I wonder if this is just me and my bubble or if others also a slightly 
> different meaning of 'Negative response' as it is defined now. If 
> there are others, is it worth spending a line or two about this here?

Some implementations put things in the Answer section even when it seems 
like they are saying negative things. This does not appear to be 
prohibited by RFC 1035 or updates, but I could be wrong.

> RRsets:
>
> Raised by a discussion I had at the Hackathon, I think it would be 
> useful to add some clarification about RRSIGs and their role with 
> respect to RRsets. Perhaps a quote from RFC4035 will do:
>
>    An RRset MAY have multiple RRSIG RRs associated with it.  Note that
>    as RRSIG RRs are closely tied to the RRsets whose signatures they
>    contain, RRSIG RRs, unlike all other DNS RR types, do not form
>    RRsets.  In particular, the TTL values among RRSIG RRs with a 
> common
>    owner name do not follow the RRset rules described in [RFC2181].

Great suggestion. I only remember that last bit some of the time when I 
(incorrectly) say "all records in an RRset have the same TTL".

> Last, I don't fully understand the meaning of the cryptic comment 
> about QTYPE=ANY that is under the RRset definition:
>
>    (This definition is definitely not the same as "the
>    response one gets to a query for QTYPE=ANY", which is an
>    unfortunate misunderstanding.)
>
> Can you explain why this comment is here?

Um, no. :-( I'll remove it.

--Paul Hoffman