Subject: [dnsext] request to adopt draft-andrews-dnsext-expire-00.txt

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Nov 2008 03:52:59 +1100

As per the chairs' instructions, this is a request for
	dnsext to adopt draft-andrews-dnsext-expire-00.txt as a wg
	item.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 19 Nov 2008 17:05:58 -0600

> 	dnsext to adopt draft-andrews-dnsext-expire-00.txt as a wg

As usual, we need to have at least five people commit to working on
(== reviewing) the document, or we can't put it into the WG's work
list because we can't reasnably expect to complete the work.

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 19 Nov 2008 17:18:32 -0600

> list because we can't reasnably expect to complete the work.

Sign me up.

    Patrik

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 19 Nov 2008 17:39:31 -0600

> list because we can't reasnably expect to complete the work.

If the wg decides to adopt you can add me to the list of reviewers

Jelte

---

From: Florian Weimer <[email-masked]>
Date: Thu, 20 Nov 2008 12:04:18 +0100

We need to fix EDNS to ignore unknown options before we can add more
of them, otherwise there'll be a combinatorial explosion in the check
to find the cause of a SERVFAIL.

I wonder if it's not easier to put the expiration time of a zone into
a special record at the zone apex.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 20 Nov 2008 06:39:06 -0600

> a special record at the zone apex.

Arghhh...no please!

Lets review the EDNS0 unknown options behaviour.

    paf

---

From: [email-masked]
Date: Thu, 20 Nov 2008 12:42:01 +0000

> a special record at the zone apex.

	perhaps we could hijack a field in the SOA thats not being used...

	like, perhaps, EXPIRE?

--bill

---

From: Florian Weimer <[email-masked]>
Date: Thu, 20 Nov 2008 14:06:01 +0100

>> a special record at the zone apex.

Huh?  We're jumping through all kinds of hoops to reconstruct that
timestamp, so why not list it explicitly in the zone?

Obviously, if the master does not regenerate it, you'll eventually run
into a problem, but as an optional feature for those who know what
they're doing -- why not?

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Thu, 20 Nov 2008 08:04:14 -0500

>to find the cause of a SERVFAIL.

Thank you Florian, for kick starting this discussion (it was on
my TODO list).
The right way to handle this is to place text in the EDNS0-bis
document.
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-rfc2671bis-edns0/

Q1: How do we mark Ignorable vs Required options ?
(see Section 4.4.2 of EDNS0-bis)
The possibilities include:
      - Continue to define all options as ignorable
      - Set an ENDS0 flag (affects all options in message)
      - define a range of option numbers for required options
      - steal a bit from the option number to be set when
         support for that option is required by recipient.

Q1-1: If we allow required options does that mean we need to go to
a new EDNS version number?

Q2: We are starting to see requests for EDNS options that are
mostly "local scope" for MDNS/Bonjour should these be treated
differently?

Q3: What should the registration criteria for new ENDS0 Options be?
Currently it is Standards track. RRtypes are Expert review.
(Section 7 of ENDS0-bis)

Feel free to add more open questions.

         Olafur

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 20 Nov 2008 07:40:54 -0600

> timestamp, so why not list it explicitly in the zone?

Because the timer should be possible to set from (I think) both as a  
request from the client and as from the server. If you do this as a  
new RR Type, I claim you have to change the DDNS spec, because when  
you send a request for an update, and get the response back, then the  
server is to respond with other RR Types part from the ones that ddns  
spec already specifies.

I think that is ugly.

I think having a ENDS0 "timer" option is much more clean, as I see it  
as a more generic clean solutions.

Hey, we could just store the number of seconds the record is valud in  
a TXT record with the same owner... ;-) That way we do not have to  
change the protocol at all... [I hope people understand I am joking]

    Patrik

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 Nov 2008 00:58:12 +1100

> to find the cause of a SERVFAIL.

	Firstly it has already been stated.  Secondly it will mainly
	be used where the client knows the server's support level or
	can reasonably be expected to be able to it the option off
	for a particular server.
 
> a special record at the zone apex.

	And you do that with DNSSEC how?

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 Nov 2008 07:58:11 -0600

>	dnsext to adopt draft-andrews-dnsext-expire-00.txt as a wg

A question for the chairs - how would y'all manage having both this 
document and axfr-clarify active at the same time?  As in, would they 
have to travel together, one before the other, etc.?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Jim Reid <[email-masked]>
Date: Thu, 20 Nov 2008 17:35:31 +0000

> 	dnsext to adopt draft-andrews-dnsext-expire-00.txt as a wg

I think this draft should not go forward as a WG item. Sorry Mark. IMO  
it is a bad idea to change the protocol because of foolish, easily  
avoided, administrator mistakes. [What next, we tweak the protocol to  
cope with forwarding loops in resolvers?] If people do dumb things,  
they need to realise their actions have consequences. That said, I  
would support a BCP which says things like "don't set up stupid  
transfer graphs and here's what sort of nastiness can occur when these  
are used". Though this won't get read by the DNS admins who do silly  
things.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 Nov 2008 11:43:03 -0600

http://tools.ietf.org/html/draft-andrews-dnsext-expire-00:

#   There are also zone transfer graphs in which the slave never talks to
#   the master, so the effective expiry period becomes multiplied the
#   length of the zone transfer graph--which when it contains loops is
#   infinite.

I think loops are easily handled - no server "reloads" a zone of the same TTL.

As far as the expiry clock not ticking down from server to server - 
is that any more than a nuisance?  Sure, it's possible that a slave 
learns the zone from another, possibly near the time of expiry there. 
Working NOTIFY takes care of this, but without working NOTIFY, there 
are other problems.

Other than that, relative to the draft, the solution contained in it 
seems solid.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 20 Nov 2008 11:53:27 -0600

>> list because we can't reasnably expect to complete the work.

Let me be clear in my "sign me up" position.

I think there is a problem here that has to be solved. Whether this  
document is solving the problem, I do not know. At the first fast  
read, I think my answer to the question is "no".

But, to be able to say this, or be able to say what the real solution  
is, I am happy to review this draft in detail.

    Patrik

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 Nov 2008 07:19:40 +1100

> are used". Though this won't get read by the DNS admins who do silly  

	Firstly there are other uses for this.

	I'm repeatedly asked "how do I know when a zone will expire" and
	"how do I check that refresh is working".  The answer today is
	look in the file system but some of the people wanting to do this
	check don't have access to the file system.  The security section
	points out this possible use.

	Some non transfer uses:
	* client checking that the ISP's servers are refreshing properly.
	* ISP check that all the zones it is serving are transfering.

	Secondly anything which requires a human to configure is likely
	to be stuffed up.  If it can be completely automated then there
	is no human error in the configuration (though possibly in the
	automation.

	Usage senario 1

	C1 and C2 are local anycast servers behind a single address
	and both are transfering from M and each other.   C1 and C2
	will now expire the zone at the same time.

			 --- M-----\
		 ------/     |     |
		 v     v     v     v
		C1 <-> C2    S2    S3

	Usage senario 2

			     M
			D1 <---> D2
	        S S S S S S S S S S S S S

	Communication between D1 and M breaks. If you need to identify
	D2 as a peer (not updating expire) everything off D1 expires
	when there is still a working transfer path.  This is a example
	of where configuration fails to do the right job.  There are
	other failure senarios which produce similar negative behaviours.
	Having the remaining expiry lifetime be transfered with the
	refresh queries keeps all servers working provided there is *a*
	path through the graph that works.
	
	Mark

---

From: Florian Weimer <[email-masked]>
Date: Thu, 20 Nov 2008 21:34:05 +0100

> Currently it is Standards track. RRtypes are Expert review.

Q: Shall we provide transitive options which are supposed to be
forwarded unaltered along with an upstream query (or downstream with a
response)?

Q: Shall we provide transitive options which may alter the data
returned in a response? (HTTP has got such a mechanism, via the Vary
field.)

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 Nov 2008 15:49:55 -0600

At 7:19 +1100 11/21/08, Mark Andrews wrote:

I'm not opposed to the idea of including something in EDNS for this, 
but, I'm still not won over for the need.

>	* client checking that the ISP's servers are refreshing properly.

I feel it is ineffective to have a goal of supporting outsider 
debugging.  There is too much information hidden from an outsider as 
it is for them to make an informed decisions.

>	* ISP check that all the zones it is serving are transfering.

ISP's generally aren't hosting zones, but I think that's a minor 
point.  Any DNS operator should have some out-of-band (to DNS) means 
to monitor the health of the DNS constellation, something that is 
especially important when using anycast (hence not being able to 
flat-out ping all the servers from one location).

>	is no human error in the configuration (though possibly in the

This has no meaning to me.  Zone transfer via AXFR, IXFR, and NOTIFY 
is one of the most automated things we have.

Now - I'm not denying that there maybe reasons to worry about 
transmitting the seconds until expiry in a zone transfer, I just 
don't see the justification in these arguments.

>	will now expire the zone at the same time.

What's lost on me is why seeing two servers expire a zone 
simultaneously is a good thing.  Expiry of the zone is an error 
condition - the result of not being able to update the zone or at 
least ask if there's an update.  (Remember there are refresh and 
retry parameters too and the roles they play.)

And regardless, how would the seconds until expiry play a role in the scenario?

>	path through the graph that works.

I don't follow.  If D1 can only get the zone from D2 and cannot see 
M, then it might be like this...

SOA has refresh at 10 mins, retry at 5 mins, and expire at 30 mins.

M updates at 12:00, D1 and D2 get it by 12:01.
The line from D1 to M dies at 12:05
At 12:10 D1 and D2 ask M if there is an update
          D1 gets no answer from M
          D2 hears that no change happened and expire is reset to 12:40
At 12:15 D1 tries M again, and maybe then tries D2 also
          D2 replies no update, so D1 should reset expire to 12:45

Now, if there were a chain but still someway to get to a "neighbor" 
the last name server might expire the zone "retry" x "number of 
slaves" later.

But, so what?  These are errors caused by more important errors (such 
as unanticipated network topology changes).

---

From: Jim Reid <[email-masked]>
Date: Thu, 20 Nov 2008 22:10:25 +0000

> 	* ISP check that all the zones it is serving are transfering.

These make more sense than defending against idiot admin behaviour.  
I'm still sceptical that the draft is worth pursuing: it's just not as  
bad as it first looked. I won't oppose it going forward as a WG item  
but won't support it either.

---

From: bert hubert <[email-masked]>
Date: Thu, 20 Nov 2008 23:27:38 +0100

> but won't support it either.

This echos my feelings exactly. 

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 Nov 2008 16:45:51 -0600

>These make more sense than defending against idiot admin behaviour.

I'm all for idiot-proofing the protocol. ;)

(Still, not all that convinced we need to adopt this work [yet].)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 21 Nov 2008 01:09:42 -0500

> are used". Though this won't get read by the DNS admins who do silly 
Loops in the transfer graph aren't necessarily just a "mistake", they 
can be an attempt to provide optimal zone convergence even in the face 
of a single-point failure.

If your Graph Theory is superior to mine, feel free to come up with a 
non-looping graph meeting the requirement that all running slaves 
automatically get the latest copy of the zone that was transferred from 
the primary master before the single-point failure occurred. We can 
include a description of that graph that in the BCP.

The only thing I'm aware of that really *doesn't* work about loops in 
the graph, is expiration. I support Mark's draft and its attempts to 
remedy that deficiency.

- Kevin

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 24 Nov 2008 12:11:15 -0800

>      - Continue to define all options as ignorable

My experience is that (at least some) current DNS implementations  
return FmtErr (1) when they receive a DNS Query with an unrecognized  
EDNS0 option.

Therefore the de facto reality appears to be that all current EDNS0  
option are "reject if unknown".

Whether a given EDNS0 option is ignorable may depend on context. I  
suggest we let the client choose, by defining the top bit as the "may  
ignore" flag. In other words, EDNS0 options 1, 2, 3, 4 are "reject if  
unknown" options, and 0x8001, 0x8002, 0x8003, 0x8004 are the "ignore  
if unknown" versions of those same options.

> mostly "local scope" for MDNS/Bonjour should these be treated

I think there's some misunderstanding here:

EDNS0 option 1: Long-Lived Query
Allows client to be notified of information changes without continual  
polling.
Status: Nothing to do with Multicast DNS.

EDNS0 option 2: Update Leases
Avoids unbounded amount of cruft accumulating on DNS server,  
remaining there indefinitely until a human operator comes along to  
clean it up.
Status: Nothing to do with Multicast DNS.

EDNS0 option 3: Name Server Identifier
Identifies which (unicast) DNS server responded to a query.
Status: Nothing to do with Multicast DNS.

EDNS0 option 4 (requested): Wake-On-LAN Owner tag
Proposal to implement the much-underutilized Wake-On-LAN capability  
into a Dynamic DNS server.
Status: Not dependent on, but compatible with, Multicast DNS.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

---

From: Shane Kerr <[email-masked]>
Date: Tue, 25 Nov 2008 13:16:23 +0100

Stuart,

> if unknown" versions of those same options.

Not a bad idea. Should the server return a code indicating which options
it does and does not understand? (This is beginning to smell a bit like
DHCP, BTW.)

--
Shane

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 25 Nov 2008 08:34:03 -0800

> it does and does not understand? (This is beginning to smell a bit  

I personally think this is overkill.

My expectation is that mandatory options will be fairly rare, and  
packets with more than one mandatory option even rarer.

---

From: Peter Koch <[email-masked]>
Date: Tue, 25 Nov 2008 18:28:01 +0100

> 	dnsext to adopt draft-andrews-dnsext-expire-00.txt as a wg

this draft seems to assume that EXPIRE is a tool to deterministically bring
a zone out of service, controlled by and to the benefit of the zone
maintainer.  My reading of RFC 1034, section 4.3.5 is different: EXPIRE
is just a relief for the slave, so it doesn't have to waste more resources
on SOA checks.  I do not see how self-sustaining XFR-loops would hurt there.
Actually, many zones use dangerously low EXPIRE values and accelerating
expiration (independent of loops) might be counterproductive for them.

This suggests that a clarification of the meaning of the EXPIRE field is
probably needed. If EXPIRE was a reliable zone removal tool, how would slave
servers be expected to maintain state -- or would they be allowed to
occasionally re-query?  What's the operational scenario in which zone
removal would apply? Shouldn't this question be better addressed by a
name server control protocol?

That said, I do not believe adopting the draft is the best way forward, because
it is too deep in solution space.  Seeking clarification of EXPIRE is a
different work item and I'd support that.

-Peter

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Nov 2008 09:53:05 +1100

> expiration (independent of loops) might be counterproductive for them.

	The purpose of expire is to stop stale data being served.

	"If the secondary finds it impossible to perform a serial
	check for the EXPIRE interval, it must assume that its copy
	of the zone is obsolete an discard it."

	No where do I see any text which says that a slave will
	stop attempting to transfer the zone if it's old copy has
	expired.

	As for dangerously low EXPIRE values they are a problem with
	or without loops in the zone trasnfer graph.

> name server control protocol?

	It's not a zone removal tool.  It a stale data removal tool.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Nov 2008 23:03:22 -0500

>different work item and I'd support that.

Should that be in AXFR clarify? I know, I promise, I'm home for a while now.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 26 Nov 2008 00:50:04 -0500

> 	stop attempting to transfer the zone if it's old copy has
Indeed, unless one interprets "discard" in the RFC as implying actual 
zone removal. I interpret it as more of a "defined but disabled" status.

One would hope, however, that implementations, if any, which continue to 
attempt refreshes after expiration, would be reasonable and prioritize 
refreshes of "live" zones over ones which are expired and -might- become 
available again. Maybe an exponential backoff to some baseline, largish 
refresh interval (e.g. a day or more) would be appropriate.

               - Kevin

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 26 Nov 2008 08:44:26 +0100

Hi,

> packets with more than one mandatory option even rarer.

At this time all EDNS options are (formally) optional.

  4.4.2. Any OPTION-CODE values not understood by a responder
  or requestor MUST be ignored.

It is sad to hear there are broken implementations that do not ignore
but fail on unknown options.  The update draft may add emphasis on it,
or note that EDNS options may cause failure and cause combinatorial
explosion of trials to determine remote support.

Best regards,
   Wouter

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 26 Nov 2008 10:07:43 +0100

>different work item and I'd support that.
    
    Should that be in AXFR clarify? I know, I promise, I'm home for
    a while now.

Seems like the proper place to me.

I'll read your homework when you're done.

	jaap

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 26 Nov 2008 09:47:29 -0800

> explosion of trials to determine remote support.

The document can say whatever we like -- and that won't change the  
actual behavior in the real world.

If you want to write robust EDNS0 client code for widespread use,  
that code has to be written to expect that servers/caches/forwarders  
written before EDNS0 (or written by people who choose to ignore  
EDNS0) may return errors if there are *any* EDNS0 options in the packet.

---

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 27 Nov 2008 09:23:22 +0100

Hi Stuart,

> actual behavior in the real world.

Agreed.  And our code (or future protocols) must work in that real world.

> If you want to write robust EDNS0 client code for widespread use, that
> code has to be written to expect that servers/caches/forwarders written
> before EDNS0 (or written by people who choose to ignore EDNS0) may
> return errors if there are *any* EDNS0 options in the packet.

Was I misunderstanding you? Do you mean formerr because of the EDNS OPT
record.  Or do you mean formerr because of an EDNS option field inside
the OPT record, where presumably that same EDNS OPT record without that
option field would have succeeded?

The latter worries me more. We have EDNS support detection now, but
EDNS-option-field detection, as you say, is a lot of trouble.

Best regards,
   Wouter