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

From: Joe Abley <[email-masked]>
Date: Fri, 27 Jun 2008 16:26:17 -0400

Hi all,

Comments on this document in this list would be most welcome.

My idea was that if the wg liked it, it might be adopted in the  
interests of producing a BCP. With hindsight, I should have called  
this "empty-mname" rather than "missing-mname", but really, what's in  
a name.

Now that I actually read the abstract I see at least one typo. Perhaps  
I should have read before submitting (imagine that!). Apologies; s/ 
usual purpose/useful purpose/.

Joe

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: 27 June 2008 16:20:46 GMT-04:00
> To: [email-masked]
> Subject: New Version Notification for draft-jabley-dnsop-missing- 
> mname-00
>
>
> A new version of I-D, draft-jabley-dnsop-missing-mname-00.txt has  
> been successfuly submitted by Joe Abley and posted to the IETF  
> repository.
>
> Filename:	 draft-jabley-dnsop-missing-mname
> Revision:	 00
> Title:		 Indicating Non-Availability of Dynamic Updates in the DNS
> Creation_date:	 2008-06-27
> WG ID:		 Independent Submission
> Number_of_pages: 7
>
> Abstract:
> The Start of Authority (SOA) Resource Record (RR) in the Domain Name
> System (DNS) specifies various parameters related to the handling of
> data in DNS zones.  These parameters are variously used bFrom [email-masked]  Fri Jun 27 13:26:20 2008
From: Joe Abley <[email-masked]>
To: [email-masked]
Date: Fri, 27 Jun 2008 16:26:17 -0400
Subject: [DNSOP] Fwd: New Version Notification for
	draft-jabley-dnsop-missing-mname-00
Sender: [email-masked]

Hi all,

Comments on this document in this list would be most welcome.

My idea was that if the wg liked it, it might be adopted in the  
interests of producing a BCP. With hindsight, I should have called  
this "empty-mname" rather than "missing-mname", but really, what's in  
a name.

Now that I actually read the abstract I see at least one typo. Perhaps  
I should have read before submitting (imagine that!). Apologies; s/ 
usual purpose/useful purpose/.

Joe

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: 27 June 2008 16:20:46 GMT-04:00
> To: [email-masked]
> Subject: New Version Notification for draft-jabley-dnsop-missing- 
> mname-00
>
>
> A new version of I-D, draft-jabley-dnsop-missing-mname-00.txt has  
> been successfuly submitted by Joe Abley and posted to the IETF  
> repository.
>
> Filename:	 draft-jabley-dnsop-missing-mname
> Revision:	 00
> Title:		 Indicating Non-Availability of Dynamic Updates in the DNS
> Creation_date:	 2008-06-27
> WG ID:		 Independent Submission
> Number_of_pages: 7
>
> Abstract:
> The Start of Authority (SOA) Resource Record (RR) in the Domain Name
> System (DNS) specifies various parameters related to the handling of
> data in DNS zones.  These parameters are variously usedy authority-
> only servers, caching resolvers and DNS clients to guide them in the
> way that data contained within particular zones should be used.
>
> One particular field in the SOA RR is known as MNAME, which is used
> to specify the "Primary Master" server for a zone.  This is the
> server to which Dynamic Updates are sent by clients.  Many zones do
> not accept updates using the Dynamic Update mechanism, and any such
> DNS UPDATE messages which are received provide no usual purpose.  For
> such zones it may be preferable not to receive updates from clients
> at all.
>
> This document proposes a convention by which a zone operator can
> signal to clients that a particular zone does not accept Dynamic
> Updates.
>
>
>
> The IETF Secretariat.
>
>
>

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

 by authority-
> only servers, caching resolvers and DNS clients to guide them in the
> way that data contained within particular zones should be used.
>
> One particular field in the SOA RR is known as MNAME, which is used
> to specify the "Primary Master" server for a zone.  This is the
> server to which Dynamic Updates are sent by clients.  Many zones do
> not accept updates using the Dynamic Update mechanism, and any such
> DNS UPDATE messages which are received provide no usual purpose.  For
> such zones it may be preferable not to receive updates from clients
> at all.
>
> This document proposes a convention by which a zone operator can
> signal to clients that a particular zone does not accept Dynamic
> Updates.
>
>
>
> The IETF Secretariat.
>
>
>

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Phil Regnauld <[email-masked]>
Date: Sat, 28 Jun 2008 13:24:48 +0200

>    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 [email-masked]  Sat Jun 28 04:24:48 2008
Date: Sat, 28 Jun 2008 13:24:48 +0200
From: Phil Regnauld <[email-masked]>
To: Joe Abley <[email-masked]>
Organization: catpipe Systems ApS
Cc: [email-masked]
Subject: Re: [DNSOP] Fwd: New Version Notification
	for	draft-jabley-dnsop-missing-mname-00
Sender: [email-masked]

>    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

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

---

From: Paul Vixie <[email-masked]>
Date: 28 Jun 2008 15:29:26 +0000

note, i have removed the leading tab character from this author's paragraphs,
since i find it very distracting.  (a cautionary note to marka and bmanning.)

[email-masked] (Phil Regnauld) writes:

> single, terminal 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 ?

i'm afraid that this will just result in a lot of QTYPE A messages sent to
the authority servers for . asking about ., and a lot of new useless RCODE 3
responses therefrom.

> 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.

during the preparation of RFC 2136 we knew that SOA.MNAME was often
meaningless, and so the rule is, "if it's the same as an NS.NSDNAME, then
it's the best target for an update."  the purpose of this was to avoid
having to forward updates from secondaries toward the master.  but as it
happened, noone read RFC 2136 carefully.  every second of every day, the
SOA.MNAME for 10.in-addr.arpa receives update requests from all over the
world, even though it is not also an NS.NSDNAME.

those update requests are all coming from a single vendor's implementation.

> 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 implFrom [email-masked]  Sat Jun 28 08:29:21 2008
To: [email-masked]
From: Paul Vixie <[email-masked]>
Date: 28 Jun 2008 15:29:26 +0000
Lines: 41
Subject: Re: [DNSOP] Fwd: New Version Notification
Sender: [email-masked]

note, i have removed the leading tab character from this author's paragraphs,
since i find it very distracting.  (a cautionary note to marka and bmanning.)

[email-masked] (Phil Regnauld) writes:

> single, terminal 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 ?

i'm afraid that this will just result in a lot of QTYPE A messages sent to
the authority servers for . asking about ., and a lot of new useless RCODE 3
responses therefrom.

> 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.

during the preparation of RFC 2136 we knew that SOA.MNAME was often
meaningless, and so the rule is, "if it's the same as an NS.NSDNAME, then
it's the best target for an update."  the purpose of this was to avoid
having to forward updates from secondaries toward the master.  but as it
happened, noone read RFC 2136 carefully.  every second of every day, the
SOA.MNAME for 10.in-addr.arpa receives update requests from all over the
world, even though it is not also an NS.NSDNAME.

those update requests are all coming from a single vendor's implementation.

> 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 imementing the suggested approach ?

i think it will not be correctly implemented, just as RFC 2136 was not
correctly implemented, and if people start putting SOA.MNAME="." then it
will just lead to a lot more QTYPE A queries for ".".
-- 
Paul Vixie
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

plementing the suggested approach ?

i think it will not be correctly implemented, just as RFC 2136 was not
correctly implemented, and if people start putting SOA.MNAME="." then it
will just lead to a lot more QTYPE A queries for ".".
-- 
Paul Vixie
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Phil Regnauld <[email-masked]>
Date: Sat, 28 Jun 2008 17:40:33 +0200

> since i find it very distracting.  (a cautionary note to marka and bmanning.)

I'll trade my tabs (bad editor, no cookie) for the capitalization of your
lead words.  ;-P

> the authority servers for . asking about ., and a lot of new useless RCODE 3

Ok, thanks for clarifying.  I suspected so.

Phil, not tabbed.

---

From: Phil Regnauld <[email-masked]>
Date: Sat, 28 Jun 2008 17:40:33 +0200

Phil, not tabbed.

---

From: Brian Dickson <[email-masked]>
Date: Sat, 28 Jun 2008 12:19:46 -0400

> the authority servers for . asking about ., and a lot of new useless RCODE 3

Are you certain? (And does RCODE 3 mean, as I understand it, NXDOMAIN?)

I tried doing just such a query using dig, and got:

; <<>> DiG 9.3.2 <<>> @f.root-servers.net A . +norec
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47975
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;.                              IN      A

;; AUTHORITY SECTION:
.                       86400   IN      SOA     A.ROOT-SERVERS.NET. 
NSTLD.VERISIGN-GRS.COM. 2008062800 1800 900 604800 86400

;; Query time: 3 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Sat Jun 28 16:11:59 2008
;; MSG SIZE  rcvd: 92

> will just lead to a lot more QTYPE A queries for ".".

Hypothetically speaking, if an actual answer for such a query were 
returned, would anything actually *use* the answer?

Again, hypothetically speaking, if an A RR were added for "." , with a 
very long TTL, such as 86400000, that would be cached ubiquitously, and 
reduce these queries at the root servers, right?

Again, hypothetically, what values for such an A RR would cause benign 
behaviour? E.g. 127.0.0.1?

Just thinking *way* outside the box....

Brian

---

From: Brian Dickson <[email-masked]>
Date: Sat, 28 Jun 2008 12:19:46 -0400

;; QUESTION SECTION:
;.                              IN      A

;; AUTHORITY SECTION:

;; Query time: 3 msec

Brian

---

From: Paul Vixie <[email-masked]>
Date: 28 Jun 2008 17:19:42 +0000

> Are you certain? (And does RCODE 3 mean, as I understand it, NXDOMAIN?)

i mean of course ANCOUNT=0 RCODE=0, thank you for your correction.

> Just thinking *way* outside the box....

i think that if LOCALHOST. could be made to return A 127.0.0.1 and AAAA ::1
then we could use LOCALHOST. as a meaningless value for SOA.MNAME, but that
would just be there to handle the case where RFC 2136 initiators were talking
to an SOA.MNAME that did not match any NS.NSDNAME, in which case they are
already out of spec and it's difficult to say how much effort should be spent
changing the spec further.
-- 
Paul Vixie
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: 28 Jun 2008 17:19:42 +0000

---

From: Phil Regnauld <[email-masked]>
Date: Sat, 28 Jun 2008 20:10:35 +0200

(updated subject to reflect draft being discussed)

Paul Vixie (vixie) writes:
> then we could use LOCALHOST. as a meaningless value for SOA.MNAME,

I actually considered that option for a moment.

> but that

Is it then out of spec if we're working with a hidden/unreachable master
server, and even though it is disclosed in SOA.MNAME, it is not listed
in NS.NSDNAME ?  What should one put in the SOA.MNAME in that case ?
Any one of the slaves ?

Phil

---

From: Phil Regnauld <[email-masked]>
Date: Sat, 28 Jun 2008 20:10:35 +0200

Phil

---

From: Paul Vixie <[email-masked]>
Date: Sat, 28 Jun 2008 18:37:53 +0000

> server, and even though it is disclosed in SOA.MNAME, it is not listed in
> NS.NSDNAME ?  What should one put in the SOA.MNAME in that case ?  Any one
> of the slaves ?

Since an RFC 2136 initiator is only supposed to send updates to an NS.NSDNAME,
and since the only spec'd use for SOA.MNAME is to select an NS.NSDNAME, any
change we want existing clients to make, we'd make with changes in NS.NSDNAME,
which would also affect normal operations (since these are used for delegation)
which isn't desireable.

I don't know a way to get out-of-spec clients to stop sending unwanted updates
other than to point SOA.MNAME at a meaningless value like LOCALHOST in one's
own local domain, and have that resolve to 127.0.0.1.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: Sat, 28 Jun 2008 18:37:53 +0000

---

From: Joe Abley <[email-masked]>
Date: Sat, 28 Jun 2008 21:52:54 -0400

> the authority servers for . asking about ., and a lot of new useless  

Is it not the case that ANCOUNT=0 RCODE=0 responses could be cached,  
whilst failures to send DNS UPDATE messages to root servers would not  
be cached?

Joe

---

From: Joe Abley <[email-masked]>
Date: Sat, 28 Jun 2008 21:52:54 -0400

Joe

---

From: Paul Vixie <[email-masked]>
Date: Sun, 29 Jun 2008 02:06:49 +0000

> Is it not the case that ANCOUNT=0 RCODE=0 responses could be cached, whilst
> failures to send DNS UPDATE messages to root servers would not be cached?

the data at hand tells me that lots of people don't cache, and those who
do only cache positives.  but in principle, yes, if the hosts who aren't
following the spec regarding using SOA.MNAME as a selection criteria among
{NS.NSDNAME} happen not to be the same hosts who aren't caching negative
or empty results, then some good could come of this.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: Sun, 29 Jun 2008 02:06:49 +0000

---

From: Brian Dickson <[email-masked]>
Date: Sat, 28 Jun 2008 23:55:25 -0400

> or empty results, then some good could come of this.

What about the behavior of (modern) caching resolvers, at start-up time, 
when they prime themselves based on the root hints file?

What do they query for, i.e. "." with query type of "any"?

If that's the case, then such resolvers will already have the answer 
(empty though it may be), and no new traffic should be seen.

If I understand things correctly, that is, and some quick local tests I 
did seem to point to this behavior.

(Even trying to do "dig +trace" on the A of . seems to short-circuit 
locally, without querying any root servers.)

Brian

---

From: Brian Dickson <[email-masked]>
Date: Sat, 28 Jun 2008 23:55:25 -0400

Brian

---

From: Paul Vixie <[email-masked]>
Date: Sun, 29 Jun 2008 04:23:41 +0000

> when they prime themselves based on the root hints file?

they are in the minority.

> What do they query for, i.e. "." with query type of "any"?

qtype SOA or qtype NS.  never qtype ANY, which is at best a diagnostic probe
and at worst makes you fall back with TCP after truncation just because of
some TXT RRset you didn't expect.

> If that's the case, then such resolvers will already have the answer (empty
> though it may be), and no new traffic should be seen.

that's not the case, but if it was, it would be true for only a minority.

> If I understand things correctly, that is, and some quick local tests I did
> seem to point to this behavior.
> 

"dig +trace" is not indicative of any cache's behaviour, as you know.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: Sun, 29 Jun 2008 04:23:41 +0000