Recent changes to UltraDNS, problems?
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. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net PGP: http://www.inoc.net/~dev/ Key fingerprint = 1E02 DABE F989 BC03 3DF5 0E93 8D02 9D0B CB1A A7B0 Profanity is the one language all programmers know best.
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
#!/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.
-- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net PGP: http://www.inoc.net/~dev/ Key fingerprint = 1E02 DABE F989 BC03 3DF5 0E93 8D02 9D0B CB1A A7B0
Profanity is the one language all programmers know best.
On Mon, Aug 23, 2004 at 07:53:13PM -0400, Robert Blayzor wrote:
Has anyone else noticed any strange problems lately when querying UltraDNS for name server records?
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. :-) John
participants (3)
-
John Osmon -
Mark Andrews -
Robert Blayzor