Subject: AXFR over UDP

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Jan 2008 12:37:40 -0500

I was going to save this issue for -07 to -08 but I figure it should 
be asked sooner rather than later.

In -06 of AXFR clarify I wrote on doing AXFR over UDP.  It's a 
protocol change, an extension I think, and as I've said I don't want 
to push these things.  But it seemed like a good idea to at least 
flesh out the idea.  I figured someone would pounce on it.  No one 
did, so far.

RFC 1035 says mildly (the same style anything else is said there) 
that AXFR runs over TCP.  If you look at the situation closely, AXFR 
has to run on TCP because the first and last segments have special 
contents.  Within AXFR there is no way to guarantee that the last 
segment might pass what's supposed to be an intermediate segment, 
this is one item that kind of necessitates TCP.

Since then there some things have changed. One is the network is a 
little healthier (a minor adjustment, meaning UDP probably gets 
through more and more in order than back then), EDNS0 has happened, 
and we have a need for lots of small zones popping up (as for web 
hosting).  It seems like AXFR over UDP might fit a need and might be 
easily added to the definition.

My thinking on it makes me feel that AXFR over UDP has to be 
restricted to one segment, meaning SOA in the first RR, same in the 
last RR, and in between all other records.  The limit on the size is 
that defined by EDNS0 or 512 by default.  The TC bit becomes 
important here - it can be used to signal that the zone is too big 
for a single segment.

I'm seeking some discussion on this.

Is AXFR over UDP a good and needed thing?
Is the restriction to a single segment and use of the TC bit wise?
   (As in, are the implementations that already have another way of doing
    AXFR over UDP?)
Should this be removed from this document and let the doc just update 
the Standards Track 1035 (et.al.)?
Should a separate doc be done for AXFR over UDP with a status of 
Experimental, or maybe Proposed Standard?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

--
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: Paul Vixie <[email-masked]>
Date: Fri, 25 Jan 2008 18:12:19 +0000

> ...
> My thinking on it makes me feel that AXFR over UDP has to be restricted to
> one segment, meaning SOA in the first RR, same in the last RR, and in
> between all other records.  The limit on the size is that defined by EDNS0
> or 512 by default.  The TC bit becomes important here - it can be used to
> signal that the zone is too big for a single segment.

i think we can skip the final SOA in this case.  (we know where the end is.)

> Is AXFR over UDP a good and needed thing?

yes.

>    (As in, are the implementations that already have another way of doing

sounds great to me.

> Should this be removed from this document and let the doc just update the
> Standards Track 1035 (et.al.)?

yes.

> Experimental, or maybe Proposed Standard?

yes.

masataka showed us in RFC 1995 that a single-packet could be useful and would
not cost extra round trips or anything else.  i believe that QTYPE AXFR over
UDP would be ignored or failed by all existing servers, none will crash or
return unambiguous results that might look like a zone.  but this would cost
us an extra round trip in some cases.  i'd prefer we modify the signalling of
the SOA SERIAL probe so that a full zone response is also welcome.  to do this
we could add an EDNS0 option, "whole zone welcome", which only had meaning if
the QTYPE was SOA and if TSIG was also present.  (we cannot open up the
possibility of a MiTM attack that replaces a whole zone by QID guessing.)

in this way, a new initiator could solicit a whole-zone response using an
EDNS0 buffer size of 64K (who cares about IP fragmentation if it's rare
enough?).  if EDNS0 isn't supported, it was going to take a round trip to
discover that anyway, so cache the EDNS0 failure and move on.  if whole-zone
isn't supported, you at least did learn the SOA SERIAL so you can move on.

this requires that the EDNS0 option for whole-zone-welcome include the client
SOA SERIAL, and the server will have to do "serial number arithmetic" to
compare this and only send a whole zone if it's "more recent" than the
client's.  these two things are changes to the model, a master server does
not have to know how to compare serial numbers right now, and a client does
not have to expose its local serial number to the network or the master server
right now.  i think those model changes are worthwhile to get the benefits.

this is a good idea.

---

From: David Conrad <[email-masked]>
Date: Fri, 25 Jan 2008 10:19:03 -0800

Ed,

> Is AXFR over UDP a good and needed thing?

Sure.  Lots of zones these days can probably fit into a single segment and I
suspect it might help out folks who are hosting zillions of tiny zones.

>    (As in, are the implementations that already have another way of doing

I think so.

> Experimental, or maybe Proposed Standard?

Don't have a strong opinion.  Having UDP AXFR as a "MAY" implement doesn't
seem like a big extension to the clarification of AXFR to me, but I don't
care that much...

Regards,
-drc

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 25 Jan 2008 15:03:03 -0500

AXFR historically is over TCP lets keep it that way.

?XFR over UDP is a new protocol extension, define it in a separate document
without any of the AXFR issues, this implies a new QTYPE.

         Olafur

At 12:37 25/01/2008, Edward Lewis wrote:
>flesh out the idea.  I figured someone would pounce on it.  No one did, so far.
>
>Should this be removed from this document and let the doc just 
>update the Standards Track 1035 (et.al.)?

---

From: Paul Vixie <[email-masked]>
Date: Fri, 25 Jan 2008 20:47:45 +0000

> ... the AXFR issues, this implies a new QTYPE.

disagree.

---

From: Joe Abley <[email-masked]>
Date: Fri, 25 Jan 2008 16:29:34 -0500

> without any of the AXFR issues, this implies a new QTYPE.

I'm not sure if the ongoing references to this as _A_XFR over UDP are  
intentional or not.

As an operator of some large zones which update very frequently (e.g.  
many times per minute) but whose individual deltas are often small, a  
single-packet IXFR response is of greater interest than a single- 
packet AXFR response.

(A single-packet NOTIFY with a complete, small delta in its hand  
luggage would also be interesting to consider; in some cases this  
might achieve in a single packet what we currently need about ten  
packets to achieve.)

I'm not sure I understand the ramifications of the QTYPE choice  
sufficiently to make a comment on that.

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 25 Jan 2008 16:33:27 -0500

On 25-Jan-2008, at 16:29, Joe Abley wrote:

> I'm not sure if the ongoing references to this as _A_XFR over UDP  
> are intentional or not.
>
> As an operator of some large zones which update very frequently  
> (e.g. many times per minute) but whose individual deltas are often  
> small, a single-packet IXFR response is of greater interest than a  
> single-packet AXFR response.

Oh! RFC 1995 already defines IXFR responses over UDP. Never mind, then.

> might achieve in a single packet what we currently need about ten  

This still seems interesting to me, however, the demonstrated Friday- 
afternoon decrease in brain capacity notwithstanding.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Fri, 25 Jan 2008 22:02:50 +0000

> Oh! RFC 1995 already defines IXFR responses over UDP. Never mind, then.

yes.  but, as far as i know, no IXFR initiator implementation has an option
to offer a 64K EDNS0 buffer size (assuming the host's IP stack can handle it)
and so, the definition of "small" is still somewhat obstructive to your goal.

> > (A single-packet NOTIFY with a complete, small delta in its hand  luggage
> > would also be interesting to consider; in some cases this  might achieve
> > in a single packet what we currently need about ten  packets to achieve.)
> 

the NOTIFY initiator is a potential IXFR/AXFR master and as such it knows its
own serial number.  it does not know the serial number of the NOTIFY responder
and so it has no basis for a delta.

right now the ideal sequence is:

	NOTIFY (new serial number) -------------> IXFR/AXFR slave
	                          <------------- thank you

	IXFR/AXFR master <------------------ IXFR request (old serial number)
	zone delta (old to new) ----------->

so, four packets.  not too bad.  dunno if it's worth optimising further.

---

From: Edward Lewis <[email-masked]>
Date: Sat, 26 Jan 2008 13:14:10 -0500

>>  ... the AXFR issues, this implies a new QTYPE.

A response to a few messages on this thread.

I see the point of a new QTYPE because in a way we are breaking 
layering, that is, the preparation and handling of the message is 
impacted by the choice of transport.  But I still think it fits into 
AXFR, because the biggest impact still is in the preparation of the 
transport, and may be the only impact if I disagree with something 
else Paul said:

>i think we can skip the final SOA in this case.  (we know where the end is.)

Here is my thinking on this.

When an AXFR server receives an AXFR query it has to remember the 
transport it came in on, but otherwise gather data the same way. 
Remembering the transport isn't too far fetched (I guess) because 
today the server has to remember the EDNS0 and TSIG/SIG(0) situation 
too.

I think that the inclusion of the closing SOA is still needed.  An 
aside, I assume that as it stands today, two SOA's would be in one 
AXFR response on TCP.  If it is that way with TCP, maintaining that 
with UDP means one less special consideration, that it, the payloads 
are equivalent.

On transmitting the AXFR, the AXFR server would have to prepare the 
response on UDP just a bit differently.  After fitting into the 
proper AXFR response message size, if there are extra records left 
over the server would need to signal this via the TC bit and not 
prepare another message.  (Also, the lack of the SOA would signal 
that you don't have everything.)

As far as the AXFR client is concerned, if they see an AXFR response 
on UDP that means only one special code branch is needed - check the 
TC bit and if it is one, do AXFR over TCP and discard this answer. 
(I know that sometimes an AXFR client can make use of a truncated 
message, but in the case of AXFR it doesn't make sense because you 
are trying to replicate the zone.)  If the TC bit is clear, then it 
no longer matters which transport was used, especially if we don't 
optimize out the second SOA RR.

Oh, and BTW, yes, this all will be moved to another document.  That 
goes back to my goal of being able to have "RFC 7503" define AXFR 
service, with "RFC 7792" define the option of having AXFR over UDP. 
Also, the AXFR over UDP is something new, at least in spec.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 27 Jan 2008 10:05:34 +0900

Edward Lewis wrote:

> little healthier (a minor adjustment, meaning UDP probably gets through 
> more and more in order than back then), EDNS0 has happened, and we have 
> a need for lots of small zones popping up (as for web hosting).  It 
> seems like AXFR over UDP might fit a need and might be easily added to 
> the definition.

Considering that such small zones needs very infrequent updates
that there is virtually no load reduction.

Moreover, changes, if any, will likely fit within single UDP IXFR
messages and, in most cases, the messages will be less than
512B long.

So, I can see no reason for protocol extension of AXFR over UDP.

Or, are there any real example where AXFR over UDP is helpful?

						Masataka Ohta

PS

IXFR over UDP could be useful to reduce load of servers for
zones such as "com" which is frequently queried and frequently
updated. Larger zones needs more frequent update. Anycast reduces
query load but does not reduce update load.

---

From: Edward Lewis <[email-masked]>
Date: Sun, 27 Jan 2008 10:12:03 -0500

>Or, are there any real example where AXFR over UDP is helpful?

You have a good point that IXFR is probably technically sufficient to 
accomplish the same task as far as performance goes.  But one of the 
changes in the industry is the call for delivery of DNS data via zone 
transfer.  What I mean is the DNS operator is being asked to give 
AXFR access to the zone data (in addition to a query interface) 
presumably because the customer wants to also run an ersatz 
authoritative server they control.  (To be more precise, "to be able 
to run one" if they choose.)

IXFR is a great addition to DNS and it is in use in large, churning 
zone environments.  But AXFR is still much simpler, especially when 
it comes to a human understanding it.  For people unaccustomed to the 
DNS protocol's inner workings, AXFR is what is known and is what is 
requested most often.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Paul Vixie <[email-masked]>
Date: Sun, 27 Jan 2008 16:39:46 +0000

> transfer.  ...

this sounds like a need for "IXFR from serial 0" to return a full zone then.

> IXFR is a great addition to DNS and it is in use in large, churning zone
> environments.  But AXFR is still much simpler, especially when it comes to
> a human understanding it.  For people unaccustomed to the DNS protocol's
> inner workings, AXFR is what is known and is what is requested most often.

if we can fit a whole dns zone into a single udp datagram, then the largest
cost in the whole transaction will be the round trip.  that's why i think we
should optimise the transaction to avoid these.  one example is to have the
response to an SOA query be, if solicited and available, a full zone.  (i
sent this proposal here the other day.)  there may be other ways to do this,
but the important piece is, if it's not going to work (like, UDP AXFR is not
supported) then let's not make everybody waste an extra round trip finding
out that it's not going to work.

---

From: Robert Elz <[email-masked]>
Date: Mon, 28 Jan 2008 00:25:41 +0700

Date:        Sun, 27 Jan 2008 10:12:03 -0500
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06240801c3c24e3d3f11@[192.168.1.106]>

  | For people unaccustomed to the 
  | DNS protocol's inner workings, AXFR is what is known and is what is 
  | requested most often.

I think you missed Matasaka-san's point, which was that AXFR over
TCP is just fine for this purpose, the extra overhead of TCP is
irrelevant as any zone small enough to fit in a rational (including
using EDNS0) response isn't going to have enough data in it for it
to almost ever alter.   The zones with high frequency updates, the
ones likely to be responsible for most AXFR requests, are the bigger
ones (say 10-20 names in them, which is getting beyond UDP).

While I'm here, in an earlier message 

| From: Paul Vixie <[email-masked]>
| Subject: Re: AXFR over UDP 

| i think we can skip the final SOA in this case.  (we know where the end is.)

That won't work in an (unusual, not really legal, but happens) case
(imagine a zone containing only the SOA, and nothing else - I know it
should have NS as well, but ...)

 | in this way, a new initiator could solicit a whole-zone response using an
 | EDNS0 buffer size of 64K (who cares about IP fragmentation if it's rare
 | enough?).

Really Paul, you should know better than that, fragmentation is just
plain evil, and anything to avoid it is a good idea.   A 64KB UDP packet
is something of the order of 40 wire level datagrams.   At the internet
typical 1-2% packet drop rate, someone who knows more probability maths
then me can work out how many times on average that 64KB datagram is
going to have to be sent before one copy of it all arrives successfully - and
that most probably wouldn't be taking account of the 40 (or so) packets being
sent back-to-back, which considerably increases the drop probability of
those fragments (in some environments, to close to certain for some of them.)

If the transfer is in a local LAN, where drop probabilities are 0 (more or
less) then the extra overhead (RTTs and ACKs) for TCP are totally irrelevant.

I have no objection to anyone who feels the desire implementing AXFR
over UDP, provided that's the only change made to the AXFR protocol (just
to allow it to happen).   And then I'd assume that in practice it wouldn't
be used enough for anyone to notice it.

And then from a much more recent message from Paul ...

  | but the important piece is, if it's not going to work (like, UDP AXFR
  | is not supported) then let's not make everybody waste an extra round
  | trip finding out that it's not going to work.

Surely, AXFR (whether via TCP or UDP) is going to remain a config (setup)
time decision, not something that's being performed dynamically on random
zones for fun?   Given that, is one extra round trip, when the first
attempt is made (assuming one assumes UDP AXFR is worth doing at all)
a cost worth speding more than 2 or 3 seconds deciding not to bother saving?

Let's optimise wheat needs optimising, and not just anything that we think
we can be clever about.

kre

---

From: Paul Vixie <[email-masked]>
Date: Sun, 27 Jan 2008 17:55:27 +0000

> zones for fun?

not random zones.  every change to axfr, like for example ixfr, recommends
that it be tried first and then fall back to axfr if it doesn't work, unless
overridden by a local config option.  if you're secondary for a lot of zones
then the manual config option is so burdensome that the automation is used.

---

From: Robert Elz <[email-masked]>
Date: Mon, 28 Jan 2008 01:50:33 +0700

Date:        Sun, 27 Jan 2008 17:55:27 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | not random zones.  every change to axfr, like for example ixfr, recommends
  | that it be tried first and then fall back to axfr if it doesn't work,

That's reasonable - "once" doesn't have to mean "once for each xfr operation"
the server could just remember what worked last time (and if it really
wanted, try again once a week in case the environment altered.)

Apart from that, compared with configuring the name of the zone, and the
primary server (or its address), which protocol variant to use is in the
noise as far as burdensome goes.

kre

---

From: Florian Weimer <[email-masked]>
Date: Sun, 27 Jan 2008 22:38:33 +0100

> So, I can see no reason for protocol extension of AXFR over UDP.

Some operators will certainly hate us if their DNS software suddenly
starts accepting AXFR over UDP because they thought that blocking 53/TCP
prevented zone transfers.

I'm not sure if this is a real argument against AXFR over UDP, but IMHO,
there aren't any real arguments for it, either.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 28 Jan 2008 09:13:52 +1100

> noise as far as burdensome goes.

	Also does anyone envision AXFR over UDP without IXFR?

	Remember you don't have to do deltas when you add IXFR
	support.  Every response can be one of up-to-date,
	axfr-style-ixfr or fallback to TCP.  The only time where
	the client does a AXFR in a AXFR/IXFR world is when the
	client is bootstrapping itself (never loaded or the zone
	expired).

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

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 28 Jan 2008 16:02:36 +0900

> this sounds like a need for "IXFR from serial 0" to return a full zone then.

Then, an IXFR client with really serial 0 will receive unexpected
result.

> cost in the whole transaction will be the round trip.

The number of RTTs will really be a problem if XFR frequency is once
in ten seconds or more.

kre;

> to almost ever alter.

Yes. Thank you.

> The zones with high frequency updates, the

If contents of each name changes once a day, we need 8640 names to
make XFR occur once in ten seconds.

							Masataka Ohta

PS

Are you all aware that poor DNSSEC is properly ignored in this thread? :-)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 28 Jan 2008 10:31:46 +0100

On Sun, Jan 27, 2008 at 10:38:33PM +0100,
 Florian Weimer <[email-masked]> wrote 
 a message of 15 lines which said:

> starts accepting AXFR over UDP because they thought that blocking
> 53/TCP prevented zone transfers.

If they do it that way, they will have many other problems, anyway...

---

From: Florian Weimer <[email-masked]>
Date: Mon, 28 Jan 2008 10:35:14 +0100

> If they do it that way, they will have many other problems, anyway...

Sure, I'm strongly in favor of unconditionally providing DNS over TCP,
but there is little consensus to make this a requirement or even a
recommendation.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 28 Jan 2008 22:18:03 +0900

> Then, an IXFR client with really serial 0 will receive unexpected

Oops, as I reread RFC1995, it explicitely allows, with an explicite
example in section 7, IXFR server perform AXFR with a single message
which could be carried over UDP.

So, if a namesever adminisrator wants so, an IXFR capable server may
avoid incremental reply, even though serial is not 0, and always choose
to use entire zone transfer over UDP or, if the non-incremental reply
is lengthy, TCP AXFR.

Sorry for my confusion.

							Masataka Ohta

---

From: Kenji Rikitake <[email-masked]>
Date: Mon, 28 Jan 2008 22:48:16 +0900

In the message <[email-masked]>
dated Mon, Jan 28, 2008 at 10:34:51AM +0100,
> Sure, I'm strongly in favor of unconditionally providing DNS over TCP,

I second that idea of unconditionally providing DNS over TCP, regarding
the trend of DNS answers which keep getting larger and larger.

// Kenji Rikitake

---

From: Joe Abley <[email-masked]>
Date: Mon, 28 Jan 2008 09:58:38 -0500

> the trend of DNS answers which keep getting larger and larger.

I'm not sure I understand what these comments mean.

If they mean that DNS service should always be available over TCP,  
then I thought that was the status quo (modulo firewall configuration  
incompetence).

If they mean that DNS service should only be available over TCP, then  
I am concerned about the practicalities of answering 100,000 queries  
per second from a client population which might have a significant RTT  
from the server.

Perhaps they mean something else?

Joe

---

From: Josh Littlefield <[email-masked]>
Date: Mon, 28 Jan 2008 10:54:48 -0500

Masataka Ohta wrote:
> is lengthy, TCP AXFR

The IXFR server can decide to send a full response, even over UDP, but
the client can't request one.  Making serial number 0 "special", in
signalling the request for a full response, could be OK, since RFC 1982
encourages avoiding the use of serial number 0, since it was already
considered "special" by some implementations.  Of course, if the server
actually uses serial 0 as a real number, then the client sending an IXFR
request from serial 0, when the real serial is 10 or 20, might instead
get a series of changesets from 0 to 10 or 20.

An alternative form of IXFR request indicating the need for a full
response could be to omit the SOA entirely in the request.  I'm aware of
some servers that already implement that.  It takes what is currently a
format error request and gives it meaning, which allows backward
compatibility.  It does not allow the server to avoid sending the
response, because the server can't observe that the client is already up
to date.  But then, AXFR doesn't allow that either (on its own).

-josh

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Jan 2008 17:07:14 +0000

> An alternative form of IXFR request indicating the need for a full response
> could be to omit the SOA entirely in the request.  I'm aware of some servers
> that already implement that.  It takes what is currently a format error
> request and gives it meaning, which allows backward compatibility.  It does
> not allow the server to avoid sending the response, because the server can't
> observe that the client is already up to date.  But then, AXFR doesn't allow
> that either (on its own).
> 
> -josh

i love this signalling, both for the reasons josh gave above, and because
it literally means "ixfr please, and i have no zone to send deltas against."

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Jan 2008 11:21:36 +1100

> it literally means "ixfr please, and i have no zone to send deltas against."

	This is a BAD idea.

	AXFR over UDP should get a FORMERR from old and new servers.
	IXFR over UDP, no serial, is just a ordinary query to old
	servers and a FORMERR to new servers.

	What happens to a old server if you send:

		 dig ixfr zone +rec +notcp
 
	AXFR and IXFR over UDP should only send the complete zone content
	when the request is signed or otherwise authenticated.  AXFR
	and AXFR style IXFR over UDP make it increadibly easy to
	poison a slave server if you don't have a authenticated
	response.  TCP gives you weak authentication but is generally
	good enough to prevent slave poisoning.

	Mark

---

From: Kenji Rikitake <[email-masked]>
Date: Tue, 29 Jan 2008 09:41:01 +0900

In the message <[email-masked]>
dated Mon, Jan 28, 2008 at 09:58:15AM -0500,
> then I thought that was the status quo (modulo firewall configuration  

I also think in most part of the Internet this is the status quo, but
I feel more strong message is needed.

> per second from a client population which might have a significant RTT  

I don't mean this - I think DNS MUST support UDP as it is now.

// Kenji Rikitake

---

From: Joe Abley <[email-masked]>
Date: Mon, 28 Jan 2008 23:15:51 -0500

> I feel more strong message is needed.

Ah, thanks. I now understand your point, and I agree with it.

Joe

---

From: Florian Weimer <[email-masked]>
Date: Tue, 29 Jan 2008 20:49:59 +0100

> then I thought that was the status quo (modulo firewall configuration

No, I don't think there is consensus to make TCP support a MUST, neither
operationally or as a feature.  Even for resolvers, it's currently just
an old-style SHOULD (but with a caveat that TCP support may become
necessary).

Here's the relevant paragraph from RFC 1123:

|           DNS servers MUST be able to service UDP queries and SHOULD
|           be able to service TCP queries.  A name server MAY limit the
|           resources it devotes to TCP queries, but it SHOULD NOT
|           refuse to service a TCP query just because it would have
|           succeeded with UDP.

To some operators, not following the recommendation regarding TCP seems
to be quite important.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Jan 2008 10:33:20 +1100

> To some operators, not following the recommendation regarding TCP seems

	And I wonder how many actually know enough about the DNS to
	make a properly informed decision, as is required, to disobey
	the SHOULD.

         *    "SHOULD"
         
              This word or the adjective "RECOMMENDED" means that there
              may exist valid reasons in particular circumstances to
              ignore this item, but the full implications should be
              understood and the case carefully weighed before choosing
              a different course.

	I also wonder how many that disable TCP to their authoritative
	nameservers actually end up depending apon others permitting TCP
	connections to their servers.

	This SHOULD has had amazing negative repercusions all over the
	DNS with operators trying to squeeze answers into 512 octets
	because they can't be sure that all of their clients can get
	the answer via TCP.

	The resolving path should become a MUST support answers up
	to 65535 bytes.  That's all the way up into the application.
	As a DNS library developer we learnt this lesson years ago.

	Mark