Re: [DNSOP] On some terminology in draft-ietf-dnsop-respsize (truncation)

Joe Abley <> Tue, 04 March 2014 13:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 801EA1A017B for <>; Tue, 4 Mar 2014 05:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i1v5brIhTSD2 for <>; Tue, 4 Mar 2014 05:08:46 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c03::229]) by (Postfix) with ESMTP id B9AB71A0176 for <>; Tue, 4 Mar 2014 05:08:45 -0800 (PST)
Received: by with SMTP id w62so3102425wes.14 for <>; Tue, 04 Mar 2014 05:08:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sVmeghCXzETzJwhnXeybFlcK/hmWFPKasiUiZ/ahak0=; b=Y7etvngD4+lxe2BbcCcf0iyPMtA93aip/0ZicdWouBxBD6e4yiVf8M/oaYTJMpv11j MIvn+i7KnMjBXaljoy4In/tL6DEcSJewmB9s6JA2X2sIQmVFK1GpaK5ObSMr8j6A2fKl 8ItN3iRpOKhM9gZPHcoj6jliFxDjHCJ+Eq8UE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=sVmeghCXzETzJwhnXeybFlcK/hmWFPKasiUiZ/ahak0=; b=PvAQa3QM8I8GxluLHu34trFeSDfem/lPLK2rk/jCUCf4Ywsmn+bmHsHA5flaKJB/3k HWDztBXtWY4ZK4trOP2ZEMzVchHxUtSjTvJXTu2z75NiJ7sD5Tx2PyQj3aiXlzwpOyxu cXyFYudpbuTllue6L6VmEN89aQLdJkxE0BOsak1nTZc+UoTVJpKWPKIebDbudXVEAIKv g7UrDFUq1edOlURGS5Rt/8ZwTMjqJoyCToabP+gU3s6jh4FNf7/XI3oaIag7L2YYLfL6 bR5pVWOUxEtkp1/COe2Pos7/4h92fjj6SSdJJaDZiLr6mX32sG6iUlbo9uNEIiWbLxmD azFw==
X-Gm-Message-State: ALoCoQmg60PgbUtY0x/JSq/AL/hR8BnHunu4KzIwz6hQs48vjJR/0fPAiba6vOUIz6Z/gNDyhfXn
X-Received: by with SMTP id cj6mr15199087wjb.70.1393938522100; Tue, 04 Mar 2014 05:08:42 -0800 (PST)
Received: from ( []) by with ESMTPSA id hy8sm51793132wjb.2.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 05:08:41 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Joe Abley <>
In-Reply-To: <>
Date: Tue, 4 Mar 2014 13:08:38 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Paul Vixie <>
X-Mailer: Apple Mail (2.1874)
Cc: " WG" <>, David Conrad <>
Subject: Re: [DNSOP] On some terminology in draft-ietf-dnsop-respsize (truncation)
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: Tue, 04 Mar 2014 13:08:47 -0000

On 3 Mar 2014, at 18:46, Paul Vixie <> wrote:

> i know of code that's in widespread use which assumes that TC=1 means that the last non-empty section was damaged but that it is safe to cache anything found in earlier sections. this code is clearly wrong-headed, but as i said, is in wide-spread use.

> a protocol clarification (not a change, which dnsop can't by charter make) might be that a sender should send empty response, authority, and additional sections when setting TC=1, and that a receiver must act as if the response, authority, and additional sections are empty if it sees TC=1.

I'm aware of a SIP ATA apparently in semi-widespread use amongst customers of a large independent ISP in Canada which (a) doesn't support TCP transport, (b) doesn't support EDNS(0), and (c) issues an IN/SRV query to bootstrap, the response to which is large and reliably features TC=1.

The ISP in question switched from BIND9 to Unbound in their resolver clusters, and the helpdesk phone started to ring.

BIND9 would return a truncated but non-empty response, which would be good enough for the ATA to work (from the user's perspective). Unbound would send empty ANSWER, AUTHORITY and ADDITIONAL sections, which left the ATA stranded and caused much end-user ire.

Clearly the ATA in question is quite broken (or, the service's SRV RRSet was unreasonably large considering the client limitations). Surely this is not the only broken situation of this type on the Internet, however.

The fact that the change from BIND9 to Unbound behaviour has been observed to result in a non-zero support cost is pertinent, I think, when imagining clarifications to the specification.