Subject: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00)

From: Ondřej Surý <[email-masked]>
Date: Tue, 7 Jul 2009 13:23:55 +0200

Hi everybody,
this little draft is an outcome of our little discussion with Shane about
allowing slave server to refuse fallback to AXFR or maybe better: to allow
more fine-grained control whether AXFR is provided/asked and
accepted/refused. F.e. you can try IXFR-ONLY on all masters and only after
it fails on all of them, you will do AXFR. There is little benefit for small
zone, but great benefit for large zones (with DNSSEC).

Shane did a great work on I-D and most information is said in the
introduction.

Feel free to ask us about details and comments (and nitpicks :)), I or Shane
will be happy to explain it or fix the I-D.

Ondrej.

On Tue, Jul 7, 2009 at 12:24 PM, IETF I-D Submission Tool <
[email-masked]> wrote:

>
> A new version of I-D, draft-kerr-ixfr-only-00.txt has been successfuly
> submitted by Shane Kerr and posted to the IETF repository.
>
> Filename:        draft-kerr-ixfr-only
> Revision:        00
> Title:           IXFR-ONLY to Prevent IXFR Fallback to AXFR
> Creation_date:   2009-07-07
> WG ID:           Independent Submission
> Number_of_pages: 6
>
> Abstract:
> Presents IXFR-ONLY, a way for a DNS slave to prevent a DNS master
> from falling back from IXFR to AXFR.
>
>
>
> The IETF Secretariat.
>
>
>

-- 
Ondrej Sury
technicky reditel/Chief Technical Officer
-----------------------------------------
CZ.NIC, z.s.p.o.  --  .cz domain registry
Americka 23,120 00 Praha 2,Czech Republic
mailto:[email-masked]  http://nic.cz/
sip:[email-masked] <[email-masked]> tel:+420.222745110
mob:+420.739013699     fax:+420.222745112
-----------------------------------------

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 07 Jul 2009 14:28:12 +0200

On 07/07/2009 01:23 PM, Ondřej Surý wrote:
> Feel free to ask us about details and comments (and nitpicks :)), I or
> Shane will be happy to explain it or fix the I-D.

Hi,

Interesting draft, other TLDs may find the feature useful too.

One comment, it is a little heavy on the mandatory configuration
options.  I would like it to be backwards compatible, and "just work".
Do you foresee that much trouble in deployment ahead that all these
mandatory configuration knobs help the operator?

Best regards,
   Wouter

--
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: Shane Kerr <[email-masked]>
Date: Tue, 07 Jul 2009 15:41:40 +0200

Wouter,

> mandatory configuration knobs help the operator?

The only mandatory configuration option is:

   Implementations MUST allow slaves to disable IXFR-ONLY completely.

I guess we can change this to SHOULD. If IXFR-ONLY breaks things then
implementors will either add such an option, or people will stop using
their software. If it doesn't break things (or cause extra delays,
packets, and so on), then such a knob is not necessary after all. :)

The other configuration options are:

   Implementations SHOULD allow slaves to disable IXFR-ONLY for a given
   master, if this is known in advance.  These masters are treated as if
   they replied with an RCODE other than CannotIXFR or NoError, although
   no query with IXFR-ONLY is actually sent.

   Implementations SHOULD allow slaves to disable IXFR-ONLY for a
   specific zone.  This may be useful for small zones, where fallback to
   AXFR is cheap, or in other cases where IXFR-ONLY is causing problems.

I guess either of these could be changed to a MAY. Neither of these is
required, because they are merely optimizations.

--
Shane

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 07 Jul 2009 15:59:37 +0200

Hi Shane,

> packets, and so on), then such a knob is not necessary after all. :)

I think you missed yet-another option where the master could disable
IXFR-ONLY support for a particular zone.  But agreed with you above.

> required, because they are merely optimizations.

So, all of them are not necessary.  They are not needed to make
IXFR-ONLY work.  Therefore I propose to delete the text about the
options entirely.

Best regards,
   Wouter

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 07 Jul 2009 16:02:52 +0200

Ondřej Surý wrote:
> Hi everybody,
> 
> this little draft is an outcome of our little discussion with Shane 
> about allowing slave server to refuse fallback to AXFR or maybe better: 
> to allow more fine-grained control whether AXFR is provided/asked and 
> accepted/refused. F.e. you can try IXFR-ONLY on all masters and only 
> after it fails on all of them, you will do AXFR. There is little benefit 
> for small zone, but great benefit for large zones (with DNSSEC).
> 

looks nice. I only gave it a cursory read, but one thing that came to mind was 
that a master could also respond with AXFR because that is simply smaller than 
the IXFR it would have made. In that specific case sending the axfr would be 
more in the spirit of the draft than returning cannotIXFR.

It could be in between the lines ("..for the serial requested") but in that case 
i'd make it quite a bit more explicit.

Jelte

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 08 Jul 2009 05:57:33 +0900

Ondrej Sury wrote:

First of all, I recommend you not to use ISO 8859 specific characters
for your name, because they are not internationally available including,
but not limited to, Japanese environment.

If you want to be internationalized, stick to characters of ISO 646
IRV or ASCII.

Or, can I expect you recognize and input formal representation of
my name, which is in Chinese characters of JIS X 0201?

I have no input method to input non-ASCII ISO8859 characters.

So called "internationalized DNS" is NOT international at all and
is meaningful only assuming some local characters.

> Shane did a great work on I-D and most information is said in the

Quite interesting topic and I appreciate that the ID is concise.

>    For example, master NS1 may have serials 1, 2, and 3 for a zone, and
>    master NS2 may have serials 1 and 3.  A slave that is at serial 2

Can't the problem better solved operationally by configuring
masters always request IXFR and never answer to other masters
with condensation of RFC1995:

   An IXFR server may optionally condense multiple difference sequences
   into a single difference sequence, thus, dropping information on
   intermediate versions.

						Masataka Ohta

---

From: Shane Kerr <[email-masked]>
Date: Wed, 08 Jul 2009 11:15:37 +0200

Wouter,

> IXFR-ONLY work.  Therefore I propose to delete the text about the

I disagree. I think it is helpful to implementors if an RFC points out
some options that they may want to think about, and the reasoning behind
adding them.

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Wed, 08 Jul 2009 11:47:29 +0200

Jelte,

> i'd make it quite a bit more explicit.

Interesting. I can't think of a reason not to support such a method,
although I have a vague notion that it might be bad in some
circumstances. I'll update the draft to allow this behavior.

Thanks,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Wed, 08 Jul 2009 12:14:05 +0200

Ohta-san,

> but not limited to, Japanese environment.

This is my fault, trying to render Ondřej's name as it is, rather than
an ASCII-approximation. The XML source actually uses the funky markup
codes which should translate into the appropriate encoding (Unicode for
example), but I guess xml2rfc isn't smart enough to convert it to plain
ASCII when the output is... plain ASCII.

I have fixed this for the next version of the draft.

>    into a single difference sequence, thus, dropping information on

Not necessarily. Masters only keep a limited number of old versions of
zones. A slave may still be able to IXFR from some of its masters but
not all in this case.

IXFR-ONLY also supports best-possible IXFR no matter how the masters got
their data, even if it is not via the DNS protocol itself.

Thanks for your attention,

--
Shane

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 08 Jul 2009 23:12:11 +0900

Shane Kerr wrote:

> This is my fault, trying to render Ondrej's name as it is,

In your mail, you, again, spelled  Ondrej's name not in ASCII, which
I corrected, because I can't send a ISO8859 mail from my environment.

> rather than an ASCII-approximation.

Just as I am "Masataka Ohta", it is not an ASCII approximation but
an ASCII representation.

> The XML source actually uses the funky markup

Many applications in Japan on MS windows support Shift JIS only, which
is not a super set of ISO8859.

> I have fixed this for the next version of the draft.

I'm saying you shouldn't use ISO8859 characters for international
mails, if you want to communicate not intra EU but internationally.

> zones. A slave may still be able to IXFR from some of its masters but

Operators, not necessarily, operate servers to keep all the old
versions, of course.

However, I'm saying operators trying to fully utilize IXFR SHOULD
keep as many old versions as appropriate on master servers and use
them for IXFR reply to queries from other master servers, even if
AXFR reply is shorter.

Replies from the master servers to other servers MAY still be
condensed.

To do so, it is required for the operators to configure master
servers know IP addresses of other master servers. But, thanks
to AXFR fallback, failing to do so will only result in possible
inefficiencies, not incorrectness.

						Masataka Ohta

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 8 Jul 2009 18:29:47 +0200

[resent since Trend Micro blocked first try]
[could IETF lists stop using fast-flux block list? this is not a first
time my email from gmail got blocked :( ]

Masataka-san,

> I corrected, because I can't send a ISO8859 mail from my environment.

Sorry, but neither I nor Shane is using ISO8859, but Unicode (namely UTF-8
according to my mail reader). And Unicode 1.0.0 came out in 1991. I
generally try to avoid writing correct spelling of my name in email body to
avoid base64 encoding of the body. So your complaint is really about From:
field.

> Just as I am "Masataka Ohta", it is not an ASCII approximation but

That goes for you. Shane is correct that "Ondrej Sury" is just ASCII
approximation.

> my name, which is in Chinese characters of ?

I am just fine receiving emails in UTF-8 and I receive many of them (f.e. in
Debian) and I have no problems receiving and sending emails including
non-ASCII and non-ISO8859 since some time.

> mails, if you want to communicate not intra EU but internationally.

MIME was standardize in June 1992. How long should we stick to crippling our
names?

> them for IXFR reply to queries from other master servers, even if

They should, but in case that one master is not able to keep up (for
whatever reason, f.e. new server, outdated zone, disk space...), slave
should be able to skip it and use next master for IXFR-ONLY.

Fallback is just fine if requested. Right now slave has no mean how to
refuse AXFR.

Ondrej
sip:[email-masked] tel:+420.222745110

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 09 Jul 2009 06:33:49 +0900

Ondrej Sury wrote:

> Sorry, but neither I nor Shane is using ISO8859, but Unicode

I said ISO8859 characters, which is contained in Unicode.

> That goes for you. Shane is correct that "Ondrej Sury" is just ASCII

Historically, diacritical marks were small ASCII characters used to
approximate local pronunciations by ASCII characters that, in that
sense, all the representations are approximations.

> MIME was standardize in June 1992. How long should we stick to crippling our

It is an evidence of failure of MIME and Unicode that local
environment of MS in Japan does not really support it, even
after so many years, even though MS is a major sponsor of
Unicode.

MIME, Unicode and (to avoid off topic discussion :-) IDN are
fundamentally broken w.r.t. internationalization.

People should use small set of internationally supported characters,
if they want there messages internationally useful.

People may use additional locally supported characters in messages
to local people. I and other Japanese has been extensively using
Japanese characters in messages to people in Japan over RFC821/822
long before MIME was standardized.

> whatever reason, f.e. new server, outdated zone, disk space...),

That's an operational issue to be resolved operationally.

Operators can copy several generations of zone contents by hand
and if there is not enough disk space, it is an operational error.

> Right now slave has no mean how to refuse AXFR.

Slave operators can ask master operators.

							Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Jul 2009 18:49:59 -0400

[moderator hat on]

This is not to pick on one correspondent in this thread, but to try to
bring the thread to a close.  

> MIME, Unicode and (to avoid off topic discussion :-) IDN are

Too late, I fear.

If the topic is whether MIME mail parts will be accepted on this list,
in any format (even, apparently, broken ones), then the ship has
sailed, the horse has left the barn, Elvis has left the building, and
$ones_favorite_cliche_here.  MIME is standardized, and if anyone
thinks we need mime-bis or whatever it would be, consider this a plea
to write that draft and take it to the appropriate IETF area (this WG
is not it).  Until MIME is changed, however, even if one doesn't like
non-ASCII in one's INBOX, one is out of luck unless one stops using a
MUA that can accept multipart messages.  Experimentation with such
mailers may reveal limitations that they impose.

If the topic is whether UTF-8 works properly for internationalization,
this is not the list for that discussion.  I understand there to be a
consortium whose whole existence is devoted to that very question.  I
am aware that there are limitations in actual experience of
deployment; it is beyond my pay grade to have an opinion on whether
that is the right thing, and it is outside the job of this WG to
evaluate such arguments.

If the topic is whether ASCII generally sucks for capturing non-ASCII
spellings of people's names, namedroppers is _also_ not the list for
that discussion.  I note (in my case, speaking personally, with some
chagrin) that there is a thread currently on the IETF general list
where all manner of topics may be conflated to include the
ASCII-sucks/no-it-doesn't topic.  In passing, I will also note that
the current rules are quite clear: non-ASCII characters are not
allowed in RFCs and therefore, presumably, in Internet Drafts (or at
least those destined for the standards track).  It is outside the
remit of this WG to evaluate arguments about how RFCs ought to be
formatted, but it is perfectly reasonable to note as an editorial
matter that an I-D to be considered has non-ASCII characters.  This
need not entail debate, since it is a matter of fact and nothing more.

If the topic is the internationalization of domain names for
applications, there's a whole working group currently dedicated to
trying to fix those issues, and if anyone here has something to say
about it, I strongly encourage those people to go over there and talk
about that topic.  I mean this sincerely: the IDNABIS WG is in urgent
need of people with DNS operational and protocol experience to
evaluate those drafts (as I think I may have suggested on previous
occasions).  Please, go forth and review!

If the topic is the header portion of emails, then I encourage those
interested to take this variously to YAM; or some future BOF where the
controversial things about email will be discussed; or to the EAI
working group, who are busily moving their existing experimental
drafts along to get them into shape for making internationalized email
addresses safe for the world.

But whatever among the above strategies you pick, whether non-ASCII
characters are acceptable on this mailing list is not a topic for the
mailing list, please.

Thanks,

A

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

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 09 Jul 2009 08:09:04 +0900

> Too late, I fear.

I and other Japanese have been using, without any problem,
ASCII internationally and Japanese characters not encoded in
Unicode locally long before MIME and Unicode were standaradized
and standardizations did not change it.

So, I'm perfectly fine people locally use any encoding including
but not limited to Unicode.

							Masataka Ohta

---

From: Shane Kerr <[email-masked]>
Date: Wed, 08 Jul 2009 12:14:05 +0200

Ohta-san,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Wed, 08 Jul 2009 11:47:29 +0200

Jelte,

Thanks,

--
Shane

---

From: Douglas Otis <[email-masked]>
Date: Thu, 9 Jul 2009 17:02:59 -0700

> [resent since Trend Micro blocked first try]

Unless this represents an older transfer list service, as a customer  
selectable option, there is a less aggressive list available that  
normally does not affect gmail.

-Doug