Re: [dbound] The proposals before us

Casey Deccio <> Sun, 11 September 2016 01:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC02912B1FC for <>; Sat, 10 Sep 2016 18:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 kCOnC2dHhRFL for <>; Sat, 10 Sep 2016 18:46:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87E2B12B014 for <>; Sat, 10 Sep 2016 18:46:09 -0700 (PDT)
Received: by with SMTP id h8so25202732qka.1 for <>; Sat, 10 Sep 2016 18:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=VUrnZWDYrS55/Pj/zJaDDVRc1lEMEMYR5M02BnbZXGE=; b=BHoCYWUHDdMB+1QHs18e1PisNPYjASCjFWLOywBrtcgXgLSvD6e9XZ8YIZ9oXARfSc Gqz74pfoLQUO+8hWqES7ILh56OfnGJhSB9Dcg+NE3n9kEY5j+Ns3MAqaKtO8TkBmDvFc o5NVaiwCL7x26U0yJbN4//jahkR+vj4kbm4vI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VUrnZWDYrS55/Pj/zJaDDVRc1lEMEMYR5M02BnbZXGE=; b=hHvzRjsE0nKk3alanbTEcE9/n+e4RKKWY77yy02BFs8NPVkZFBpVbdrjGPG+i79QLM 9BgmnSlGjMHSYOrl/IaZpqLnv+TArlPghD5zYUcowbZXOvrsO6+AyjBoei2nX8tutxAn zPWg8/1Xdbs+YF3dGkf2kagkIry1N3rcXRyOjMRsq5N/c4LTX+m7n080/hfKUKcyqbzV NsfwXmIdISEAW7b6RM4jywv5C7HqCSl39lRmzY/haQJz9FitJ/7ZEy5i2vjYcFC6LeL+ I5GySW2IGMP60fiIDe1LHP0xGxCdlKBA4+jHNdc2b53+24poNwNeZt1H//Iiw8KsmmNa gSHQ==
X-Gm-Message-State: AE9vXwNGp3c/2KiHKXYjhhRB6ECbK2IeheadrlCm1BaeIL38UCuiYV18QQcjLsPRTVO58g==
X-Received: by with SMTP id 13mr11632386qkf.112.1473558368495; Sat, 10 Sep 2016 18:46:08 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id w184sm6373032qkw.38.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 10 Sep 2016 18:46:07 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_82E7F8C9-0320-4F34-B12B-8FA0FA340362"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Casey Deccio <>
In-Reply-To: <20160910211314.47140.qmail@ary.lan>
Date: Sat, 10 Sep 2016 21:46:06 -0400
Message-Id: <>
References: <20160910211314.47140.qmail@ary.lan>
To: John Levine <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [dbound] The proposals before us
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: DNS tree bounds <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Sep 2016 01:46:12 -0000

Hi John,

> On Sep 10, 2016, at 5:13 PM, John Levine <> wrote:
> In article <> you write:
>> Proper use of the "fetch" directive (introduced in version -01 and fleshed
>> out in version -02; the current version is -03 [1]) allows an application
>> to pull down ahead of time or on-demand the policy for an entire namespace
>> tree.
> I don't see how that is very useful in practice.

The pertinent information was included in the text that immediately followed the snippet that you included above.  Since it was omitted, I'll include it again here (some emphasis added):

> Downloading the policy associated with public suffixes ahead of time brings the number of DNS lookups for names in any domain with no explicit policy (i.e., using default behavior) to one [1].  Downloading the policy associated with other domains (especially those with heavy usage) brings lookups to zero for names in those domains.

Slightly restated:

The point is that if the entire policy-negative realm (current known as public suffixes) is pulled in using fetch (e.g., using [1]), then unless an organizational domain below the policy-negative realm has introduced custom policy (by the addition of records in the _odup subdomain), the DNS lookups required are at most one.  If the policy for any arbitrary organizational domain is pulled in using fetch, then no DNS lookups are required.

>  The namespace that
> people are likely to be most interested in is the .COM TLD, but the
> registry doesn't know which subdomains have third-party delegations.
> A domain that doesn't have third-party delegations can publish a fetch
> blob, but in most cases that's only going to say we're one big
> organizational domain.  It's unclear to me if fetch helps domains like
> uk that know that and and are boundaries but don't
> know what boundaries may exist below that.

I'm not sure I follow your thought patterns.

Current behavior:
The PSL contains a list of all public suffixes.  The organizational domain for a domain name is immediately below the public suffix associated with the name [2].

Each TLD defines bottom-most boundary of the policy-negative realm in the DNS namespace below _odup.TLD.  The organizational domain for a domain name is immediately below the policy negative boundary.

By having all the _odup.TLD zones locally (i.e., obtained using fetch), the boundary of the policy negative realm is known to the application without it making a single DNS query.

For something below the policy-negative boundary (e.g., if it doesn't already have a local copy of the zone, then it must make an on-demand DNS query for the records it is looking for.  In the case where there are no such records (i.e., the default case) an NXDOMAIN is returned, and the search stops with just one query.  On the other hand, if it does have a local copy of the zone, then no DNS queries are required (unless the local copy of the zone indicates that there is another organizational domain boundary).

>> 1) Minimal information disclosure.  There is a broad effort to minimize
>> information disclosure in the name of privacy.  ODUP keeps with those
>> efforts by only disclosing the information necessary to find the policy or
>> next delegation of policy--sort of the qname-minimization equivalent of
>> DBOUND.  The Levine draft specifies that the entire name for which the
>> organizational boundary is being sought is provided to the DNS servers
> That is true, but for incoming mail the request will typically be in
> conjunction with a bunch of inquiries about the IP the message is
> coming from (DNSBLs) and the domain in the envelope (SPF).

These DNS queries go to different parties than DBOUND-related DNS queries would go, so it really is additional disclosure.  I suppose whether or not that is acceptable is up to the working group.

> The horse
> has left the barn and I'd rather have the performance.

As already described, when fetch is properly applied, there is no performance disadvantage to ODUP.  Performance and privacy do not  have to be mutually exclusive.

>> 2) Sane default.  There needs to be a default behavior that is consistent
>> and compatible with existing behavior.  With ODUP the lack of DNS data at
>> an ODUP name (that is, nothing special has been changed for the domain by
>> way of adding ODUP records) results in behavior that is consistent with the
>> current behavior [3].  The Levine draft says: "If there is no policy for
>> the domain the lookup fails; there are no defaults... Applications may
>> apply defaults of their own, but that is beyond the scope of this
>> specification."  I'm not sure I fully understand that statement, but it
>> doesn't provide me confidence that the default is backwards compatible with
>> current behavior.
> The current behavior is typically to look in the PSL and if the domain
> isn't there, the code does whatever it does.  I haven't looked at any
> of the libraries to see if they don't look for an org domain or if
> they do some hack like assume it's a 2LD.  Whatever they do, it seems
> compatible to me.

The algorithms on the Public Suffix List page [2] and in section 3.2 of RFC 7489 [3] seem pretty clear.  The algorithm is longest match--there really isn't a notion of "if the domain isn't there".

Best regards,

[1] <>