Subject: [dnsext] draft-kerr-ixfr-only-01

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 May 2010 10:59:56 -0400

Dear colleagues,

There has previously been some interest expressed in the draft
draft-kerr-ixfr-only-01, and we've had a request to adopt it.
However, we have not had the requisite five people committing to
review through WGLC.

In my opinion, the document is mostly complete.  We could knock this
off pretty quickly if we had committed reviewers.  So far we have two
people who said they'd review, with a third conditional offer.

If we do _not_ have committed reviewers by 17:00 UTC on 2010-05-21,
the Chairs will take that as an indication of a lack of interest in
the draft, and will assume that the WG does not want to do this work.

Best regards,

Andrew

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

---

From: Ray Bellis <[email-masked]>
Date: Mon, 17 May 2010 11:13:52 +0000

> people who said they'd review, with a third conditional offer.

+1 for another conditional offer.

In particular I'd also like to see discussion around Alfred's text (below)

> Since ixfr-only needs EDNS anyway (for a new [extended] RCODE),
> it should be considered to signal new behavior for IXFR (and allow
> for additional feedback if necessary) via a new EDNS Option (for
> use with IXFR only), thus avoiding the introduction of a new QTYPE.

Ray

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 17 May 2010 13:35:03 +0200

> the draft, and will assume that the WG does not want to do this work.

I'll sign up for reviewing it

Jelte

---

From: Sebastian Castro <[email-masked]>
Date: Tue, 18 May 2010 09:10:37 +1200

> +1 for another conditional offer.

Count with me as reviewer.

>> use with IXFR only), thus avoiding the introduction of a new QTYPE.

I'd like to extend on the "additional feedback" thought. Given EDNS is
needed, it shouldn't be better that, when an IXFR client requests an
IXFR-ONLY to an IXFR Server and the size of the AXFR is lower than the
IXFR the IXFR Server signals this situation, letting to the IXFR client
the final decision of requesting IXFR or AXFR based on their own policy?
Given the IXFR client already has to keep some state about the IXFR
Servers (which RCODE they replied), this a little piece of state that
may help the client to decide if going to the faster (lower latency)
server offering AXFR or slower server serving IXFR.

Besides that, I have some additional comments:

On Section 1, paragraph 2: The text starts with "In the document", but
given the context, sounds more reasonable to say" In this document".

On Section 3, paragraph 6 reads: "normally in situatians" and should
read "normally in situations".

And just being picky: Why the choice for CannotIXFR instead of
IXFRNotAvail, for example? Cannot sounds to me like "I can't give you
this for some reason", "NotAvail" sounds more like "I can't give it to
you because I don't have it".

Cheers!

-- 
Sebastian Castro
DNS Specialist
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 495 2337
mobile: +64 21 400535

---

From: Joe Abley <[email-masked]>
Date: Tue, 18 May 2010 18:13:30 -0400

> However, we have not had the requisite five people committing to

I will review it.

Joe

---

From: "Rose, Scott W." <[email-masked]>
Date: Wed, 19 May 2010 13:45:29 -0400

> Count with me as reviewer.
Considering I just read the draft, I guess I'm now a reviewer too.

> you because I don't have it".

For that matter, why not use rcode= NotImp?  Isn't that why it's there since the document defines a new Opcode?  

Scott

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 20 May 2010 14:46:56 +0200

Hi,

I'm still not convinced of why we need a protocol change for this.
I think this problem can be tackled configuration-wise.

For the client:
NSD already has configuration settings for turning off AXFR fallback.

For the server:
You need to update the server in order to understand IXFR-ONLY. Well, in
that case the server software might just as well implement a ixfr-only
option, instead of this technical solution, in order to implement this
behavior.

Best regards,

Matthijs

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 20 May 2010 15:33:00 +0200

On 19.5.2010 19:45, Rose, Scott W. wrote:
>>> On 14/05/2010 15:59, "Andrew Sullivan"<[email-masked]>  wrote:
>>>
>>>> Dear colleagues,
>>>>

Because it has another meaning.

CannotIXFR (or IXFRNotAvail) indicates that server is willing to provide 
IXFR, but it doesn't have needed data.  The new RCODE allows client to 
mark server as temporarily unable to provide IXFR-ONLY and it will try 
to do it in next run.

NotImp indicates lack of IXFR-ONLY support at all.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/R&D manager
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Joe Abley <[email-masked]>
Date: Thu, 20 May 2010 13:14:23 -0400

> NSD already has configuration settings for turning off AXFR fallback.

What if you want to disable AXFR responses to IXFR queries only for certain servers, or at certain times of day, or at times of low network congestion, or due to some other heuristic that the authority-only server author did not think of?

There is more flexibility to be found by allowing clients to specify the type of zone transfer response they can tolerate than in configuring the server.

Joe

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 20 May 2010 21:26:21 +0200

> What if you want to disable AXFR responses to IXFR queries only for certain servers, or at certain times of day, or at times of low network congestion, or due to some other heuristic that the autho…

Point taken, but imho this is irrelevant: the IXFR-ONLY draft does not
implement these heuristics either.

The problem definition in my eyes is that you want to prevent a full
zone transfer. I can see perfectly valid reasons why you want to. I
think a turn on|off configuration option suits more than a technical
solution to solve this.

Best regards,

Matthijs

---

From: Joe Abley <[email-masked]>
Date: Thu, 20 May 2010 16:04:01 -0400

> implement these heuristics either.

The point is not whether those heuristics are anticipated by the IXFR-ONLY proposal, but that some mechanism exists for a client to request an IXFR without receiving an AXFR response.

he important bit to understand is that it's the client that ought to make the decision, and that the decision is in the general case not predictable by the server.

> think a turn on|off configuration option suits more than a technical

Sure, an on/off configuration option on the client seems like an entirely reasonable way (amongst others) to implement this. But the client still needs a way to signal to the server that it does not want to receive an AXFR response. This proposal seems to encapsulate a clean way of carrying out that signalling.

Joe

---

From: Dave Knight <[email-masked]>
Date: Thu, 20 May 2010 17:18:53 -0400

> Sure, an on/off configuration option on the client seems like an entirely reasonable way (amongst others) to implement this. But the client still needs a way to signal to the server that it does no…

It's not that the client doesn't ever want an AXFR response, rather it wants the opportunity to get an IXFR by walking through each master to see if one of them can provide the required delta. In the case where no master can provide the required delta the client may then want to fall back to AXFR. 

I an conceive of a situation where a client will walk through the set of masters for a zone, each time requesting IXFR-ONLY, and each time receiving CannotIXFR, then going back to the first master and requesting IXFR as a last resort.

In this scenario a master server is required to exhibit different behaviour to the same client for the same zone, this needs to be signalled to the server by the client.

dave

---

From: Sebastian Castro <[email-masked]>
Date: Fri, 21 May 2010 10:51:54 +1200

Dave Knight wrote:
>>>> What if you want to disable AXFR responses to IXFR queries only
>>>> for certain servers, or at certain times of day, or at times of
>>>> low network congestion, or due to some other heuristic that the
>>>> authority-only server author did not think of?
>>> Point taken, but imho this is irrelevant: the IXFR-ONLY draft
>>> does not implement these heuristics either.
>> The point is not whether those heuristics are anticipated by the
>> IXFR-ONLY proposal, but that some mechanism exists for a client to
>> request an IXFR without receiving an AXFR response.
>> 
>> he important bit to understand is that it's the client that ought
>> to make the decision, and that the decision is in the general case
>> not predictable by the server.
>> 
>>> The problem definition in my eyes is that you want to prevent a
>>> full zone transfer. I can see perfectly valid reasons why you
>>> want to. I think a turn on|off configuration option suits more
>>> than a technical solution to solve this.
>> Sure, an on/off configuration option on the client seems like an
>> entirely reasonable way (amongst others) to implement this. But the
>> client still needs a way to signal to the server that it does not
>> want to receive an AXFR response. This proposal seems to
>> encapsulate a clean way of carrying out that signalling.
> 
> It's not that the client doesn't ever want an AXFR response, rather
> it wants the opportunity to get an IXFR by walking through each
> master to see if one of them can provide the required delta. In the
> case where no master can provide the required delta the client may
> then want to fall back to AXFR.
> 
> I an conceive of a situation where a client will walk through the set
> of masters for a zone, each time requesting IXFR-ONLY, and each time
> receiving CannotIXFR, then going back to the first master and
> requesting IXFR as a last resort.

I envisioned similar scenario, that's why I think the following part of
the text should be changed:

-----------------------------------------
   If the IXFR result is larger than an AXFR, then an IXFR server MAY
   reply with an AXFR result instead.  This is an optimization, and IXFR
   servers MAY only reply with AXFR if they are certain that the reply
   using AXFR is smaller than an equivalent IXFR reply.
-----------------------------------------

and, instead of sending the AXFR, the IXFR server signals the client
that the AXFR result size is smaller than the IXFR result size, allowing
the client to take the final decision of what to do.

> 
> In this scenario a master server is required to exhibit different
> behaviour to the same client for the same zone, this needs to be
> signalled to the server by the client.
> 
> dave

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 27 May 2010 10:38:07 +0200

> then want to fall back to AXFR.

Well, the client could also fallback to some other "more efficient"
method of getting full zone (f.e. pulling diff via ssh :)).

Ondrej