I am running the latest cvs build of freebsd 4.9 stable.. I'm trying to connect via ftp to ftp.perl.org to do an automatic cpan perl module installation. I am getting an error message [rick@cherry ~]: ftp ftp.perl.org ftp: ftp.perl.org: Non-recoverable failure in name resolution ftp> however, ping works fine for name resolution and other ftp sites resolve and connect fine as well.. This happens on 2 different freebsd servers.. Works great from a windows box.. Any clues? -Rick
> I am running the latest cvs build of freebsd 4.9 stable.. > > I'm trying to connect via ftp to ftp.perl.org to do an automatic cpan perl > module installation. > > I am getting an error message > > [rick@cherry ~]: ftp ftp.perl.org > ftp: ftp.perl.org: Non-recoverable failure in name resolution > ftp> > > however, ping works fine for name resolution and other ftp sites resolve > and connect fine as well.. > > This happens on 2 different freebsd servers.. Works great from a windows box > .. > > Any clues?Their nameservers are not RFC 103[45] compliant. NXDOMAIN is the *wrong* answer to this query. AAAA records came into existance 8 years ago. There no excuse for a name server to not handle queries for them. Mark Network Working Group S. Thomson Request for Comments: 1886 Bellcore Category: Standards Track C. Huitema INRIA December 1995 DNS Extensions to support IP version 6 ; <<>> DiG 9.2.3 <<>> ftp.cpan.ddns.develooper.com @ddns5.develooper.com aaaa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51034 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ftp.cpan.ddns.develooper.com. IN AAAA ;; Query time: 207 msec ;; SERVER: 63.251.223.178#53(ddns5.develooper.com) ;; WHEN: Tue Mar 16 16:59:07 2004 ;; MSG SIZE rcvd: 46> > -Rick > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
I've run across this issue with a few websites in the last 18 months. It might help to ask if they're using a "load balancer" on ddns5.develooper.com (the nameserver for ddns.develooper.com which is the zone containing ftp.cpan.ddns.develooper.com which is CNAMEd from ftp.perl.org). One DNS-based load balancing product exhibited this broken behavior, though I don't know which product it was. When queried for type A or any type, the correct responses are returned, but when querying for AAAA, NXDOMAIN is returned, which is evil because it communicates false information that there are no records of any type at that name. Since IPv6-enabled clients query AAAA before A or any, they tend to trip up 100% of the time. I've not yet heard of a general-purpose DNS server getting this wrong, I assume any such offenders were fixed earlier in the 8 years of AAAA. DNS-based load balancers are on average greener. I ran across this first with a major computer reseller website and complained to their admins. It took many months for them to get the fix from their load-balancing vendor and convince themselves it was safe, but they did eventually correct the fault. ask <at> develooper.com is listed as the contact in the SOA for ddns.develooper.com, hopefully including them on this email will get the ball rolling. Dave Hart davehart@davehart.com
On Mon, Mar 15, 2004 at 11:27:50PM -0500, Rick Knospler wrote:> I am getting an error message > > [rick@cherry ~]: ftp ftp.perl.org > ftp: ftp.perl.org: Non-recoverable failure in name resolution > ftp>Just to elaborate on what Mark said... The nameserver for ftp.perl.com has a problem when asked for any records other than A (ie. an IPv4 address). When asked for any other type of record, it returns NXDOMAIN, and this means "ftp.perl.com" does not exist. It should return "0 records of this type". I've a cgi script for diagnosing these sort of problems at: http://www.cnri.dit.ie/cgi-bin/check_aaaa.pl?dom=ftp.perl.org You should probably mail ask@develooper.com and domains@develooper.com and let them know you have had a problem and ask when they will be able to fix their DNS load balancer. David.
Am 16. M?rz 2004 um 07:57:07 +0000 schrieb David Malone:> The nameserver for ftp.perl.com has a problem when asked for any > records other than A (ie. an IPv4 address). When asked for any other > type of record, it returns NXDOMAIN, and this means "ftp.perl.com"Asking for MX and TXT works: # host -t TXT ftp.perl.org ftp.perl.org is an alias for ftp.cpan.ddns.develooper.com. ftp.cpan.ddns.develooper.com text "serviced by cpan.noris.de." # host -t MX ftp.perl.org ftp.perl.org is an alias for ftp.cpan.ddns.develooper.com. ftp.cpan.ddns.develooper.com mail is handled by 10 miette.develooper.com. ftp.cpan.ddns.develooper.com mail is handled by 11 relaybackup.netcetera.dk. Liebe Gr??e, Nora. -- nora@sappho-net.de IM-NETZ Neue Medien, Berlin http://www.im-netz.de/ WWW von Frauen f?r Frauen, Hamburg http://www.w4w.net/ Lesbian Computer Networks, Helsinki http://www.sappho.net/
> On Tue, Mar 16, 2004 at 09:27:27AM -0500, Louis A. Mamakos wrote: > > > > Wouldn't it be nice to be able to configure the default behavior of > > the resolver to not query AAAA records first, before looking for A > > records? [...]Tim Robbins noted:> This was discussed recently on -current: > http://marc.theaimsgroup.com/?l=freebsd-current&m=107607971200977&w=2That thread might lead one to believe that destination address selection in -CURRENT would give the described behavior, but I'm not so sure. Destination address selection comes into play after you have resolved names to addresses. My guess is even with IPv4 destination addresses preferred in /etc/ip6addrctl.conf the resolver will still query for both AAAA and A records when the client is IPv6-enabled. If the AAAA query comes first and a bork load balancer returns NXDOMAIN, the negative response will likely be cached and result in the subsequent A query failing as well, meaning no IPv4 address to prefer. Dave Hart davehart@davehart.com