Subject: AXFR over UDP is available

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2008 13:35:36 -0500

http://www.ietf.org/internet-drafts/draft-lewis-axfr-over-udp-00.txt

Haven't seen the announcement yet, but the URL works.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Mail archives, backups.  Sometimes I think the true beneficiaries of
standards work are the suppliers of disk drives.

--
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: Masataka Ohta <[email-masked]>
Date: Sat, 09 Feb 2008 09:10:46 +0900

> http://www.ietf.org/internet-drafts/draft-lewis-axfr-over-udp-00.txt

I'm afraid you completely misunderstand the previous discussion.

First of all, you failed to convince us that changes to enable
AXFR over UDP is desirable. But, let's ignore it for the rest of
my message.

RFC1995 says:

   When an IXFR request with an older version number is received, the
   IXFR server needs to send only the differences required to make that
   version current.  Alternatively, the server may choose to transfer
   the entire zone just as in a normal full zone transfer.

As full zone (AXFR) over UDP is already available with IXFR, the only
thing we need to support AXFR over UDP is to disable differences (IXFR)
over UDP.

That is, an configuration option on IXFR servers to disable UDP
differential transfer and to encourage UDP full transfer is just
fine.

An IXFR server which is incapable of any differential transfer is
also fine.

IXFR clients, against zone administrators policy to allow differential
transfer, insisting on full transfer can ignore UDP differential
transfer responses and initiate TCP AXFR, which causes no extra packet
exchanges.

There is absolutely no protocol work left.

						Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2008 20:54:34 -0500

>I'm afraid you completely misunderstand the previous discussion.

No, but I clearly was judging the discussion through different eyes.

>AXFR over UDP is desirable. But, let's ignore it for the rest of

I wasn't trying to.  I wanted to get flesh out the protocol to see 
first if it is viable.  It's an engineering document, not a marketing 
one.

The initial discussion convinced me that it is worth proposing.  If 
the extension is viable, then a use case can be added.

The reason I went forward on "weak evidence" of demand is that I know 
that if there's AXFR over UDP in a separate document, it will get the 
traction of people  issuing RFPs for DNS and DNS-like service.  There 
is a tendency for folks to do a quick search of titles for 
capability, rarely/never have I seen any one go inside an RFC and 
profile a set of services.

>    the entire zone just as in a normal full zone transfer.

The problem with the above is that it either means:
1) You have to go to TCP
2) You attempt to do the transfer over UDP - but fall into the 
problems of mis-ordered packets, etc. (which I disucss in one of the 
two drafts, I forget which already)

We'd have to clear that up in IXFR.

>There is absolutely no protocol work left.

Except for what you prescribed in your message and clear up my note 
about the RFC 1995 passage.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 09 Feb 2008 01:58:08 +0000

> There is absolutely no protocol work left.

i agree.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 09 Feb 2008 21:05:48 +0900

> I wasn't trying to.

That's your fault.

> 2) You attempt to do the transfer over UDP - but fall into the problems 
> of mis-ordered packets, etc. (which I disucss in one of the two drafts, 
> I forget which already)

You, merely confusingly, mentioned that UDP reply should be one
message (though RFC1035, further, remotely restrict the message
contained in one packet), while RFC1995 clearly restrict reply
one packet (which could be fragmented into multiple packets without
causing misorderging):

   Transport of a query may be by either UDP or TCP.  If an IXFR query
   is via UDP, the IXFR server may attempt to reply using UDP if the
   entire response can be contained in a single DNS packet.

--
Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Sat, 9 Feb 2008 09:43:00 -0500

>one packet (which could be fragmented into multiple packets without

What do you mean by "merely confusingly?"  Is there something unclear 
in my draft?

>    entire response can be contained in a single DNS packet.

If that's the case, okay.  I didn't have time to read RFC1995 to find that.

In IXFR, can the client 'force' a full zone transfer?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 09 Feb 2008 23:57:28 +0900

Edward Lewis wrote:

> I didn't have time to read RFC1995 to find that.

Again, that's your fault.

					Masataka Ohta