|
As an American, I could go for the ignorant stereotyping of the French. But being the good global citizen I try to be, I’ll just see if someone can tell me if I’m missing something here, or if indeed AFNIC has lost its mind.
I recently requested for one of my .FR domains to be delegated to new DNS servers. I got everything set up at my new DNS provider. But, AFNIC won’t perform the transfer because of the following “fatal” reason:
>——fatal——
>
> 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.
In actuality, their error statement is not true. The primary/master server does listen/answer to TCP Port 53, just not to AFNIC’s DNS servers, or anyone else’s servers for that matter.
TCP Port 53 is used for zone transfers (as indicated in RFC1035). Nowhere in the RFC does it say that any DNS servers outside of the secondary/slave servers must have access to the Primary/Master server via that port. My provider has it set up that if you are not one of their slave servers, you don’t get to access their DNS servers via TCP port 53. Last time I checked, that’s called good and appropriate security.
None of the DNS servers at AFNIC are or will be authoritative for this domain. So why does AFNIC think that they have the right to usurp every DNS provider’s security so that they can grab a zone file?
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.”
Being that AFNIC grabs the SOA record at the new DNS servers, they should be able to ascertain the validity of the zone file.
I know of no other Registry on the planet that requires zone file transfers to be allowed to non-authoritative names servers as a basis of compliance. Essentially, as a Registrant, I am being held hostage by this registry because of my unwillingness to drop security precautions.
Can anyone give me any logic that would give the people in France the thought that what they’re doing is correct?
I’m at a loss, both because I can’t understand their logic (or lack thereof) and the fact that I may have to steer my .FR domains away from my preferred DNS provider.
Tres stupide, if you ask me.
Thanks,
Bren
Sponsored byRadix
Sponsored byCSC
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byDNIB.com
Sponsored byWhoisXML API
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 :-)