New Non-WG Mailing List: Dbound -- DNS tree bounds

IETF Secretariat <> Tue, 28 January 2014 22:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C09691A036C for <>; Tue, 28 Jan 2014 14:31:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mSMoy1_8DLdD; Tue, 28 Jan 2014 14:31:01 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id E100B1A0069; Tue, 28 Jan 2014 14:31:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: IETF Secretariat <>
To: IETF Announcement List <>
Subject: New Non-WG Mailing List: Dbound -- DNS tree bounds
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Tue, 28 Jan 2014 14:31:01 -0800
X-Mailman-Version: 2.1.15
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Jan 2014 22:31:04 -0000

A new IETF non-working group email list has been created.

List address:
To subscribe:


Both users and applications make inferences from domain names, usually 
in an effort to make some determination about identity or the correct 
security stance to take. Such inferences, however, are usually based 
on heuristics, rules of thumb, and large static lists describing parts 
of the DNS name space. The DNS root is expanding rapidly, and the 
existing mechanisms -- primarily the public suffix list 
( and related systems -- are unlikely to be 
sustainable in the medium term. Most of the existing mechanisms are 
managed semi-manually, and there are good reasons to suppose that the 
limits of such management are either about to be exceeded, or already 
have been. Moreover, the existing mechanisms are made without regard 
to the semantics of domain name boundaries, and sometimes miss subtle 
but important parts of those semantics (in particular, the public 
suffix list has sometimes failed to take into account so-called empty 
non-terminals). Perhaps most importantly, the public suffix list puts 
the control of policy assertions about a given name outside of the 
control of the domain operator, and in the hands of the operator of 
the list. 

The purpose of this mailing list is to discuss this issue and to 
identify as completely as we can the cases in need of addressing, to 
identify the necessary lines of work to address each case, and to 
determine whether there is sufficient interest and energy to set up a 
working group to complete that work.

For additional information, please contact the list administrators.