Recent changes to UltraDNS, problems?

Mailman List Mirror (Read Only)
1

Has anyone else noticed any strange problems lately when querying UltraDNS for name server records?

I have a few scripts that seem to have broken in the past week. A simple PERL script that looks up NS records from the root servers, which worked fine last week, suddenly starts reporting that the query is returning an empty answer.

If I change it to any other TLD servers/domains, it works fine. What is even more strange is that when I use dig, the lookups are just fine. (most of the time) Can anyone at UltraDNS (or anyone else for that matter) shed some light on what might have changed/broken?

#!/usr/bin/perl

use strict;
use Net::DNS; #version 0.48

my @tld = ("tld1.ultradns.net", "tld2.ultradns.net");
my $res = Net::DNS::Resolver->new;
$res->nameservers(@tld);

my $query = $res->query("adaconline.org", "NS");
if($query) {
     print "It worked!\n";
} else {
     print "It failed!\n";
}

exit;

In the above case the query always returns undef and the errorstring returned is no error. My initial thought was a bug in Net::DNS, but I've also heard from others they've started noticing strange lookup problems when asking UltraDNS directly for answers.

2

In article <412A8369.8000609@inoc.net> you write:

Has anyone else noticed any strange problems lately when querying
UltraDNS for name server records?

I have a few scripts that seem to have broken in the past week. A
simple PERL script that looks up NS records from the root servers, which
worked fine last week, suddenly starts reporting that the query is
returning an empty answer.

If I change it to any other TLD servers/domains, it works fine. What is
even more strange is that when I use dig, the lookups are just fine.
(most of the time) Can anyone at UltraDNS (or anyone else for that
matter) shed some light on what might have changed/broken?

  There is nothing wrong. The real NS records for the zone
  can be found in the child zone. The UltraDNS servers are
  returning a referral to them.

  Also when you are querying authoritative only servers it
  is a good idea to disable recursion.

  Mark

; <<>> DiG 8.3 <<>> ns isc.org @TLD1.ULTRADNS.NET
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51679
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; QUERY SECTION:
;; isc.org, type = NS, class = IN

;; AUTHORITY SECTION:
isc.org. 1D IN NS ns1.gnac.com.
isc.org. 1D IN NS ns-ext.isc.org.

;; ADDITIONAL SECTION:
ns-ext.isc.org. 1D IN A 204.152.184.64

;; Total query time: 431 msec
;; FROM: drugs.dv.isc.org to SERVER: 204.74.112.1
;; WHEN: Tue Aug 24 11:28:40 2004
;; MSG SIZE sent: 25 rcvd: 95

3

Not for name server records, but we do have a glue record in .org that
pops up when querying one ultradns.net TLD nameserver, but not the other.
Stranger still -- this glue record had been removed several months ago,
so it almost looks like part of their infrastructure is sending out
(months) old data.

We've sent out requests for help to our registrar, and the registry.
I figure the UltraDNS folks will be involved shortly too. :slight_smile:

  John