Home / Blogs

AFNIC and DNS Server Redelegation

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

By Brendan Becker

Related topics: DNS, Internet Protocol, Security

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

Re: AFNIC and DNS Server Redelegation Simon Waters  –  Dec 14, 2006 1:58 PM PDT

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....

Re: AFNIC and DNS Server Redelegation Jay Daley  –  Dec 14, 2006 1:59 PM PDT

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.

Re: AFNIC and DNS Server Redelegation Jay Daley  –  Dec 14, 2006 2:11 PM PDT

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.

Re: AFNIC and DNS Server Redelegation Joe Abley  –  Dec 14, 2006 2:12 PM PDT

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.

Re: AFNIC and DNS Server Redelegation Mark Jeftovic  –  Dec 14, 2006 10:22 PM PDT

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.

Re: AFNIC and DNS Server Redelegation Stephane Bortzmeyer  –  Dec 15, 2006 1:45 AM PDT

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.

Re: AFNIC and DNS Server Redelegation Stephane Bortzmeyer  –  Dec 15, 2006 1:48 AM PDT

> 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.

Re: AFNIC and DNS Server Redelegation Stephane Bortzmeyer  –  Dec 15, 2006 1:53 AM PDT

> 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.

Re: AFNIC and DNS Server Redelegation Edward Lewis  –  Dec 15, 2006 5:27 AM PDT

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.

Re: AFNIC and DNS Server Redelegation Lenz Gschwendtner  –  Dec 15, 2006 5:57 AM PDT

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)

Re: AFNIC and DNS Server Redelegation Mark Jeftovic  –  Dec 15, 2006 7:52 AM PDT

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

Re: AFNIC and DNS Server Redelegation Stephane Bortzmeyer  –  Dec 15, 2006 9:10 AM PDT

> 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.

Re: AFNIC and DNS Server Redelegation Ram Mohan  –  Dec 15, 2006 1:25 PM PDT

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.

Re: AFNIC and DNS Server Redelegation Neil johnson  –  Feb 08, 2007 4:13 PM PDT

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.

Re: AFNIC and DNS Server Redelegation Stephane Bortzmeyer  –  Feb 09, 2007 1:30 AM PDT

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 :-)

To post comments, please login or create an account.

Related Blogs

Related News

Topics

Industry Updates – Sponsored Posts

New from Verisign Labs - Measuring Privacy Disclosures in URL Query Strings

DotConnectAfrica Delegates Attend the Kenya Internet Governance Forum

3 Questions to Ask Your DNS Host about Lowering DDoS Risks

Continuing to Work in the Public Interest

Verisign Named to the OTA's 2014 Online Trust Honor Roll

4 Minutes Vs. 4 Hours: A Responder Explains Emergency DDoS Mitigation

Dyn Acquires Internet Intelligence Company, Renesys

Tips to Address New FFIEC DDoS Requirements

Smokescreening: Data Theft Makes DDoS More Dangerous

Introducing getdns: a Modern, Extensible, Open Source API for the DNS

Why We Decided to Stop Offering Free Accounts

dotStrategy Selects Neustar's Registry Threat Mitigation Services for .BUZZ Registry

Tony Kirsch Announced As Head of Global Consulting of ARI Registry Services

24 Million Home Routers Expose ISPs to Massive DNS-Based DDoS Attacks

Dyn Acquires Managed DNS Provider Nettica

What Does a DDoS Attack Look Like? (Watch First 3 Minutes of an Actual Attack)

Joining Forces to Advance Protection Against Growing Diversity of DDoS Attacks

Why Managed DNS Means Secure DNS

SPECIAL: Video Interviews from NamesCon 2014 in Las Vegas

Rodney Joffe on Why DNS Has Become a Favorite Attack Vector

Sponsored Topics