Re: [DNSOP] DNS Delegation Requirements

"Jakob Schlyter" <> Mon, 19 September 2016 10:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8814312B2FF for <>; Mon, 19 Sep 2016 03:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.617
X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, 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 hCtU4pIrenMS for <>; Mon, 19 Sep 2016 03:49:49 -0700 (PDT)
Received: from ( [IPv6:2001:67c:394:15::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 754D712B005 for <>; Mon, 19 Sep 2016 03:49:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=spg20100524; h=received:from:to:cc:subject:date:message-id:in-reply-to:references: mime-version:content-type:content-transfer-encoding:x-mailer; bh=+Pv/eUWCg3AdOdQiUK7KMjXiEzkDzUaTM0YmYG5U5bk=; b=sw3LCa3P5NGe4oM9BpLcQQysFqYLq4MdKp10jl4vAC4hhNu43ipvy12I98NP3E1GrZaCZLoDxJVpZ CR5dfeVVvW+UQ3/wNxmAU7q6F9zvJwP0lq8sirZeTCi9hmJgA5cvRLbXqzs900pp8p1T9/7cAlhb/h 5fIKx9uv4ytavAaA=
Received: from (unknown []) by (Halon) with ESMTPS id c69a778e-7e56-11e6-b08e-232a48e874da; Mon, 19 Sep 2016 12:49:44 +0200 (CEST)
From: "Jakob Schlyter" <>
To: "John Kristoff" <>
Date: Mon, 19 Sep 2016 12:49:43 +0200
Message-ID: <>
In-Reply-To: <20160317164524.59a212a9@localhost>
References: <> <20160317164524.59a212a9@localhost>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <>
Cc: dnsop <>
Subject: Re: [DNSOP] DNS Delegation Requirements
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Sep 2016 10:49:52 -0000

(very very delayed reply, rebooting draft now...)

On 2016-03-17 at 22:45, John Kristoff wrote:

> The introduction lists 8 areas of interest.  All, except "7. Name
> Server" have their own section in the table of contents.  Oversight?

Yes, one section was missing. Fixed now.

> This sentence is awfully confusing:
>   Many requirements in this document deal with the properties of a
>   nameserver that is used as part of a delegation, therefore the
>   wording mentioning the use of a name server as part of this is
>   omitted.
> First there is nameserver, then name server as two words.  Which is
> it?  More importantly, I'm not quite sure what is being said here.  
> Can
> you perhaps rewrite, elaborate or provide an example?

Perhaps better?  "Many requirements in this document deal with the 
properties of a
name server that is used as part of a delegation, therefore the wording
mentioning the use - authoritative or recursive - of a name server as 
part of
this is omitted."

> You may be interested to know that I recently submitted a draft on DNS
> over TCP operational requirements.  If that work progresses as I hope,
> it might help with section 4.2 of your draft.

Reference added.

> The consistency requirements might be too strict, since it applies all
> zone data.  While reasonable people might fret about inconsistency 
> when
> things like "views", "geo-location", client-subnet and so on are in
> use, it might be best to limit consistency requirements to the
> infrastructure records (e.g. SOA, NS).

Yes, I've added a reference to RFC 7871.

> Additionally, I could imagine an argument being made that all names
> need not respond with the same NS RRset.  While generally this
> delegation or authority list inconsistency is often indication of a
> problem, it is feasible that it might be intentional and may even
> provide some advantage.  The so-called "fast flux" invention by the
> miscreants taught us that.

Do you have any proposed text to address this?

> Suggesting that name servers be the same AS is often unnecessary.  
> More
> important is diversity in the route announcements covering the name
> server addresses.  Many might not even be able to easily satisfy this
> requirement.

Addressed in

> A few additional topics you may wish to consider:
>   * delegated name server should be authoritative only (no rd service)

>   * ptr names of NS addresses should match the associated A/AAAA names

Why is that?

>   * name server should run NTP or equivalent so time is accurate

This would be import if using TSIG, but how is it important form a 
delegation point of view?

>   * DNS TTLs of the NS and A/AAAA name servers MUST be consistent

It makes sense to me, but we need to explain why.


(work in progress version at