Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-missing-mname-00

[Phil Regnauld <[e-mail]>]

Joe Abley (jabley) writes:
> Hi all,
>
> Comments on this document in this list would be most welcome.


>    the MNAME field of an SOA record has no benefit, and in fact may well
>    cause unwanted traffic (DNS UPDATE messages) to be received by the
>    named server.

	... if the named server is at all reachable/exists.  Think stealth
	servers or other zone population and provisioning mechanisms that do
	not use AXFR/IXFR as their method of distribution (i.e. where each
	nameserver for the delegation could arguably be itself a master).
	I won't even get into MNAMEs pointing to RFC1918 addresses (see
	http://www.ripe.net/ripe/maillists/archives/dns-wg/2005/msg00264.html)

>    This document specifies a convention by which a zone operator may
>    include an empty MNAME field in order to deliberately specify that
>    there is no appropriate place for Dynamic Updates to be sent.

	Question: How do existing implementations react to the presence of a
	single, terminal doFrom [e-mail]  Sat Jun 28 04:24:48 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 87F813A68BD;
	Sat, 28 Jun 2008 04:24:48 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6D5FF3A68DF
	for <[e-mail]>; Sat, 28 Jun 2008 04:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id HvmrRq-Yzsf3 for <[e-mail]>;
	Sat, 28 Jun 2008 04:24:46 -0700 (PDT)
Received: from moof.catpipe.net (moof.catpipe.net [129.142.64.64])
	by core3.amsl.com (Postfix) with ESMTP id 267E33A68BD
	for <[e-mail]>; Sat, 28 Jun 2008 04:24:45 -0700 (PDT)
Received: from localhost (unknown [129.142.64.64])
	by localhost.catpipe.net (Postfix) with ESMTP id 306A37D3BF4;
	Sat, 28 Jun 2008 13:24:52 +0200 (CEST)
X-Virus-Scanned: amavisd-new at catpipe.net
Received: from moof.catpipe.net ([129.142.64.64])
	by localhost (moof.catpipe.net [129.142.64.64]) (amavisd-new,
	port 10024)
	with ESMTP id sft34pqjTvXx; Sat, 28 Jun 2008 13:24:49 +0200 (CEST)
Received: from macbook.catpipe.net (unknown [83.95.48.180])
	(Authenticated sender: relayuser)
	by moof.catpipe.net (Postfix) with ESMTP id 56F207D3B5F;
	Sat, 28 Jun 2008 13:24:49 +0200 (CEST)
Received: by macbook.catpipe.net (Postfix, from userid 1001)
	id 95A5298CF89; Sat, 28 Jun 2008 13:24:48 +0200 (CEST)
Date: Sat, 28 Jun 2008 13:24:48 +0200
From: Phil Regnauld <[e-mail]>
To: Joe Abley <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <[e-mail]>
X-Operating-System: Darwin 9.3.0 i386
Organization: catpipe Systems ApS
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: [e-mail]
Subject: Re: [DNSOP] Fwd: New Version Notification
	for	draft-jabley-dnsop-missing-mname-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Joe Abley (jabley) writes:
> Hi all,
>
> Comments on this document in this list would be most welcome.


>    the MNAME field of an SOA record has no benefit, and in fact may well
>    cause unwanted traffic (DNS UPDATE messages) to be received by the
>    named server.

	... if the named server is at all reachable/exists.  Think stealth
	servers or other zone population and provisioning mechanisms that do
	not use AXFR/IXFR as their method of distribution (i.e. where each
	nameserver for the delegation could arguably be itself a master).
	I won't even get into MNAMEs pointing to RFC1918 addresses (see
	http://www.ripe.net/ripe/maillists/archives/dns-wg/2005/msg00264.html)

>    This document specifies a convention by which a zone operator may
>    include an empty MNAME field in order to deliberately specify that
>    there is no appropriate place for Dynamic Updates to be sent.

	Question: How do existing implementations react to the presence of a
	single, terminal t ?  What if an A record is published for '.' ?
	I know it probably won't happen. but I'm also curious to know, and
	I think the document should specify this: what is the impact of
	this on existing implementations ?

>    For zones whose SOA record contains an MNAME field which corresponds
>    to a server listed in the apex NS set, making the MNAME field empty
>    might well cause additional NOTIFY traffic.  If this is a concern,
>    the operators of the authority-only servers for the zone might choose
>    to specify an explicit notify list.

	... which excludes the "master".


	Question:
	
	In some cases it can be useful to be able to identify the real
	master anyway.  But MNAME was never a reliable way of ascertaining which
	server in an NS set was the source of data, if such a source existed
	at all.
	
	Do people on this list think that we are losing any valuable
	information by using the convention suggested by Joe, or was it already
	too uncertain, and that no usefull debugging/troubleshooting
	information is being lost by implementing the suggested approach ?


	Otherwise a good idea.

	Phil
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


dot ?  What if an A record is published for '.' ?
	I know it probably won't happen. but I'm also curious to know, and
	I think the document should specify this: what is the impact of
	this on existing implementations ?

>    For zones whose SOA record contains an MNAME field which corresponds
>    to a server listed in the apex NS set, making the MNAME field empty
>    might well cause additional NOTIFY traffic.  If this is a concern,
>    the operators of the authority-only servers for the zone might choose
>    to specify an explicit notify list.

	... which excludes the "master".


	Question:
	
	In some cases it can be useful to be able to identify the real
	master anyway.  But MNAME was never a reliable way of ascertaining which
	server in an NS set was the source of data, if such a source existed
	at all.
	
	Do people on this list think that we are losing any valuable
	information by using the convention suggested by Joe, or was it already
	too uncertain, and that no usefull debugging/troubleshooting
	information is being lost by implementing the suggested approach ?


	Otherwise a good idea.

	Phil
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop