Re: [DNSOP] comments on draft-jabley-dnsop-refuse-any-01

Bob Harold <> Mon, 02 November 2015 15:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C52A71B48C4 for <>; Mon, 2 Nov 2015 07:50:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lrEL_ZRhLSCc for <>; Mon, 2 Nov 2015 07:50:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6AF11B48C5 for <>; Mon, 2 Nov 2015 07:50:53 -0800 (PST)
Received: by ykft191 with SMTP id t191so143069358ykf.0 for <>; Mon, 02 Nov 2015 07:50:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HmdcCzltcgYVPV51/0EKr8/S+pcy0Pkkl7AsVIj29bw=; b=QWKZMRfw0rxnwpVUJGG4tQ+3RuCGlhoL1XaOU1tSIHXvGyeUXaiYYxCHfWhBS6/LAb AHcfTbV3dnCnU+Aweqyqh1CUkrlP0/lB9XYlzLzFBsA7/JOsdhA/I8cmwjh2fUtXMsEP cq0T/wyh4i8JK3RPPI9obuDD2+tJNMbFr8AoQP/vmxKjhSvy0Sg8r6ck4CVHkpHgqEA2 mIQ7SIAcILlYWTuoZLHPl7ptceSn5k+cP1pdEyfY4Cw27PmbWPwLRIRM2z1MXb2mP4o9 Co6K6wBjbBgV8GC3z6gIGAoYV+bd/rpWNdzONhqkVpIWFi/HgwEe7s5f1sqmwySegkAe sgow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HmdcCzltcgYVPV51/0EKr8/S+pcy0Pkkl7AsVIj29bw=; b=Z1jTnlUqeS2s/bYBz0+w9fd5pZFQFMdVzmq4TZc3ZFAQrRbqmv0n6M/SfgbmuaDBdV p9GM6rFeQ+ZoTLFDA00c3ypZhJErzp9KxlIz1nDww4/aZ3QE4QBlI7h6mJ53+CapeB41 iWZgP/9oHYp5U0Wsn6Q8EOltFD6vI5faTBRjsZNhLgaT3hfeLy422ouluamXKAkBgcNF BqFuZtVahzCpRUh2HYl1MUroSnP2DFCxl264fcN0PS/RVbcJk/DZXAjsaYv+JNPorFEJ tY182dU/zRrw88Sbm1o/Mn0CdzhsVGj9ZZeT0co0nPKley5OjamS1DvOU834ZjYZnpe7 lPMg==
X-Gm-Message-State: ALoCoQkB66Uan2Ei+mEICs20fmAS0FccVSqLQR6HmBbiNKquyWvU3KcvFe6Su3SJG32HoXysYho2
MIME-Version: 1.0
X-Received: by with SMTP id j2mr18574645ywe.165.1446479452646; Mon, 02 Nov 2015 07:50:52 -0800 (PST)
Received: by with HTTP; Mon, 2 Nov 2015 07:50:52 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Mon, 02 Nov 2015 10:50:52 -0500
Message-ID: <>
From: Bob Harold <>
To: 神明達哉 <>
Content-Type: multipart/alternative; boundary="94eb2c074626f35e57052390bdf9"
Archived-At: <>
Cc: dnsop <>
Subject: Re: [DNSOP] comments on draft-jabley-dnsop-refuse-any-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Nov 2015 15:50:55 -0000

On Mon, Nov 2, 2015 at 1:21 AM, 神明達哉 <> wrote:

> I've read draft-jabley-dnsop-refuse-any-01.  I have a few comments:
> - Section 3
>    ANY queries are sometimes used to help mine authoritative-only DNS
>    servers for zone data, since they return all RRSets for a particular
>    owner name.  A DNS zone maintainer might prefer not to send full ANY
>    responses to reduce the potential for such information leaks.
>   I'm not opposed to the idea of reducing ANY responses per se, but
>   this rationale doesn't sound very strong to me.  There are at most
>   64K types of records for a particular of name (of the same class),
>   and for a signed zone it's quite easy to get all existing types for
>   a particular name (the number of which would usually be much smaller
>   than 64K in practice).  It may be true that sending an ANY query is
>   an easy and cheap way to get all types of records of a particular
>   name today, if you really worry about this type of mining, tweaking
>   ANY response won't help much anyway.
> Even a 3 to 1 reduction in queries is a significant bonus to using ANY,
and since most zones are not signed, ANY is very useful.  (But
unfortunately also abusable.)

> - Section 4
>    1.  A DNS responder may choose to search for an owner name that
>        matches the QNAME and, if that name owns multiple RRs, return
>        just one of them.
>   If the choice of the "one" is not deterministic and especially if a
>   zone uses different authoritative server implementations, then it's
>   more likely that they return "inconsistent" responses.  This may not
>   be a problem, but we may want to encourage consistent behavior,
>   e.g., by suggesting the choice of smallest (not just 'a small') one
>   in Section 5.
> +1

> - In terms of using ANY query for debugging purposes, and if our main
>   goal is to prevent abuses like amplification attacks rather than
>   mining, I wonder whether we want to allow the original behavior
>   under some conditions, e.g., queries authorized by TSIG or sent over
>   TCP.
> Strong +1 here.

> - I wonder whether we want to use a new type of RR rather than HINFO
>   for synthesized responses. (I've not closely followed discussions on
>   this draft, so perhaps it was already considered and rejected?).
> Do most resolvers cache RR types that they do not recognize?

> --
> JINMEI, Tatuya
Bob Harold