Historically all DNS operations were allowed, and expected over TCP, and there were TCP only resolvers. The RFC as you see is explicit that TCP queries should be allowed and answered.

Now please comply with the RFC and stop projecting your own assumptions about how things should work ;)

Realistically, not supporting TCP isn’t going to cause many issues. Those people who wanted TCP only resolvers have long been stuffed by people with slack attitudes to standards compliance. TCP only resolvers are practically immune to certain spoofing attacks.

Although I’d also want to know that your servers support extensions to handle packets sizes over 512 bytes, and what it will do if an answer is larger than 512 bytes and the client doesn’t support those extensions and requests a TCP connection….

Sorry, but you are completely wrong about the need for TCP. 

A client can use TCP whenever it wants, and has to use TCP when the response it gets via UDP is truncated because it is too long.  AXFR is one example of where this is needed. EDNS0 gets around the UDP size limitation that but support for that is not ubiquitous.

I know that the checks that .fr do are technically sound even if I personally wouldn’t implement any such technical checks.

I should have added that whilst AXFR is an example of TCP use it is not why .fr require it.  As far as I know they do not require AXFR access to your zone.  They require TCP, which is completely different.

You are confused.

Nameservers which do not answer queries on TCP as well as UDP transport are broken.

TCP is not only used for zone transfers.

Refusing to delegate to a server which is broken is perfectly valid, especially if your motivations are driven by technical matters rather than the desire to minimise support costs (or lose a perceived competitive advantage to a competitor who is less diligent).

Instead of complaining about AFNIC, you should fix your servers.

Allowing TCP or not aside, AFNIC also insists on RFC1912 style serials in the SOA as another reason for refusing delegations, which I’m sure is fine for the theological purists, but there really is no reason for a registry to have an opinion on what method is used in a second-level serial.

In a more general sense, there are many ccTLDs which try to enforce all kinds of silly conventions. Hidden primaries come to mind (having a non-delegated master in the origin of an SOA record)

As DNS architectures become more complex, second guessing configurations in the manner AFNIC and others do accomplishes little more than antagonizing their users and I’d be surprised if this kind of nonsense ever actually solved or pre-empted a network stability issue.

Check if the nameservers are authoritative for the name and be done with it already. That’s about the only thing the registry should be concerned with when it comes to their subdelegations.

I can confirm what many people already said here: AFNIC does not
require zone transfer and never did. Our Zonecheck tool
(http://www.zonecheck.fr/) does not even attempt to do a zone
transfer.

Indeed, our policy is to require TCP and UDP connectivity to all name
servers of the domain, because that’s what in the RFC (see the posts
by Jay Dailey and Joe Abley) and because large requests require it (in
the future, it may change to a rule like “TCP *or* EDNS0 mandatory).

Sorry for bashing a customer :-) but the original post is seriously
clueless, specially for mixing TCP and zone transfer.

> My Registrar called AFNIC asking for their logic.
> They said something along the lines of “We need
> to check the zone file for errors. If you drop the
> security and let us do the zone transfer, you can
> then re-start that security rule and everything
> will be okay.

I strongly doubt that anyone at AFNIC wrote such a stupidity. I
welcome actual details in private, shoud you want to check.

Let me repeat again: AFNIC never required zone transfer of the
delegated zones.

> AFNIC also insists on RFC1912 style
> serials in the SOA as another reason
> for refusing delegations,

This is absolutely wrong and I wonder where do you take this
information.

Our policy is to test the style of the serial number and to warn if
it is not YYYYMMDDNN. It is a warning, not a fatal error and it never
was ground to refuse a delegation. (The delegation or change of is
refused only when there is a fatal error, not when there are
warnings, whatever their number.)

Anyone can check by himself.

Besides adding a “metoo” to the comments by Jay Daley, Joe Abley, Simon Waters, et.al., I suggest that you check out http://www.nanog.org/mtg-0410/pdf/toyama.pdf.  It makes a plea for authoritative servers to be available on TCP.  The presentation was also given at the 61st IETF.

those discussions arise on our support lines once a week minimum. ccTLDs have certain requirements (afnic not beeing alone here) that are not known in the gTLD zones. many of those requirements have historic sources but they are still there and we have to live with them. american providers seem to have problems to understand that and their customers have problems with those ccTLDs therefor.

suggestion: go to european providers :-)

(the thing I never got is the requirement that the hostmaster email address in the SOA record has to actually exist… however, ours does)

Sorry about the confusion about the RFC1912 serial, that was my mistake.

> many of those requirements have historic sources

If some requirments of AFNIC seem obsolete or just plain wrong, tell us. We always listen.

> but they are still there and we have to live
> with them.

No, you can ask for changes.

I wonder whether contacting AFNIC directly (Stephane is quite well known, as are others from <.fr>

in the community) rather than posting first and researching later would have resulted in faster resolution.

I am experiencing the same issue while trying to update the nameserver information for a .fr domain. 

==Server doesn’t listen/answer on port 53 for TCP protocol | Ref: IETF RFC1035 (p.32 4.2.  Transport) |  The DNS assumes that messages will be transmitted as > datagrams or
in a byte stream carried by a virtual circuit. While virtual circuits can be used for any DNS activity, datagrams are preferred for
queries due to their lower overhead and better performance.
> > `——-——-  -  -
> >  =>  ns2.addr.com./38.113.244.196
> > =>  ns.addr.com./38.113.244.55
> >
> > ==>  FAILURE (and 2 warning(s))
+++++++++++++++++++++++++++++++++++++++++++++++++

How do we resolve this issue?

Thanks for your help.

Neil Johnson asked: “How do we resolve this issue?”.

Well, first, you can check that Zonecheck is indeed right:

% dig +tcp @ns.addr.com SOA addr.com

; <<>> DiG 9.3.2-P1 <<>> +tcp @ns.addr.com SOA addr.com
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

While the same namserver replies fine in UDP, so it is not a connectivity issue.

Since it seems to be a recent BIND, I assume that TCP connectivity is filtered by an external firewall so you need to change the given firewall’s configuration. Port 53 was probably dropped by some rule.

I’ve left ns2.addr.com as an exercice :-)