[dns-operations] The possible problems after May 5th

[Mark Andrews]

In message <20100409104121.GA18788 at sources.org>, Stephane Bortzmeyer writes:
> On Fri, Apr 09, 2010 at 09:22:05AM +1000,
>  Mark Andrews <marka at isc.org> wrote 
>  a message of 41 lines which said:
> 
> > Apart for djbdns can you name another nameserver that doesn't listen
> > for TCP by default?
> 
> Akamai's custom written from scratch closed name server. (Apparently,
> they are in the process of deploying an EDNS-capable and TCP-capable
> version.)
> 
> > They may have irewalls in front of them that block incoming TCP but
> > they still listen.
> 
> Frankly, Mark, I do not understand you.

Well when the problem space was split into recursive server, firewall,
and authoritative server and I said that just about all authoritative
servers speak TCP you have Mathew coming out of the wood work and
recombining authoritative servers and firewall when for the issue
in the subject you need to combine recursive server and firewall
if you intend to combine them at all as the root servers don't/won't
block TCP.

> Of course, the TCP problem is,
> in 99.999 % of the cases, in a middlebox (such as a firewall), not in
> the name server software. But what difference does it make? For the
> domains indicated by Dempsky, the domain name cannot be resolved over
> TCP, period. This is a common problem and it is something that must be
> fixed before May 5th.

What do those domains have to do with the subject of this thread?
The answer is absolutely nothing.

> I can testify that the problem is common since AFNIC requires TCP to
> work before an actual delegation of a .fr domain name and it makes a
> lot of phone calls and angry emails.

Again off topic.

> Very often, the problem is
> difficult to solve precisely because it is hidden in a middlebox and
> the name server manager does not understand it immediately. There is
> no point in denying that, we should instead be busy spreading the
> word: "Test and upgrade before May 5th". (Zonecheck
> <http://www.zonecheck.fr/>, the program we use, is an ordinary DNS
> client, it tries with TCP, if it fails, it fails, it cannot know where
> the failure is.)
> 
> [Same thing for the UNability to receive answers > 512 or > 1500, of
> course, it is not the name server software's fault but the result is
> the same.]

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org