In message <4db829e3.5010...@mailclub.fr>, Laurent Bauer writes: > On 27/04/2011 15:03, Karl Auer wrote: > > On Wed, 2011-04-27 at 17:45 +0530, kshitij mali wrote: > >> we are unable to lookup the domain "goelexports.com" > >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63082 > > > > A trace shows the likely problem: > > > > dns2-rz-ap:[log]$ dig +trace goelexports.com > > [...] > > ;; Received 505 bytes from 192.58.128.30#53(j.root-servers.net) in 32 ms > > > > goelexports.com. 172800 IN NS ns.hostsearchindia.com. > > goelexports.com. 172800 IN NS ns2.hostsearchindia.com. > > ;; Received 116 bytes from 192.52.178.30#53(k.gtld-servers.net) in 29 ms > > > > dig: Couldn't find server 'ns.hostsearchindia.com': node name or service > > name not known > > > > Neither of those allegedly authoritative nameservers appears to exist. > > > > Has there been a very recent change to the nameservers for this domain? > > My servers seem to have it cached and are responding with what looks > > like good data: > > > > dns2-rz-ap:[log]$ dig goelexports.com > > [...] > > ;; ANSWER SECTION: > > goelexports.com. 14057 IN A 69.16.253.121 > > > > ;; AUTHORITY SECTION: > > goelexports.com. 84408 IN NS ns5.webcomindia.net. > > goelexports.com. 84408 IN NS ns4.webcomindia.net. > > > > ;; ADDITIONAL SECTION: > > ns4.webcomindia.net. 12408 IN A 69.16.253.121 > > ns5.webcomindia.net. 12408 IN A 69.16.253.122 > > Hello, > > It looks like the delegation has not changed, but the zonefile itself has : > > $ dig -t ns goelexports.com @l.gtld-servers.net. > ;; AUTHORITY SECTION: > goelexports.com. 172800 IN NS ns.hostsearchindia.com. > goelexports.com. 172800 IN NS ns2.hostsearchindia.com. > > ;; ADDITIONAL SECTION: > ns.hostsearchindia.com. 172800 IN A 69.16.253.121 > ns2.hostsearchindia.com. 172800 IN A 69.16.253.122 > > *.gtld-servers.net still hold the correct glues for > ns[2].hostsearchindia.com, but the parent's answer is not authoritative. > If you request the IP addresses for those records, you will see the new > NS records, and also you will no longer see an answer for the glues > themselves : > > $ dig -t ns goelexports.com @69.16.253.121 > ;; ANSWER SECTION: > goelexports.com. 86400 IN NS ns5.webcomindia.net. > goelexports.com. 86400 IN NS ns4.webcomindia.net. > > $ dig -t ns ns.hostsearchindia.com @69.16.253.121 > ;; ->>HEADER<<- opcode: QUERY, status: *NXDOMAIN*, id: 47931 > ;; AUTHORITY SECTION: > hostsearchindia.com. 86400 IN SOA ns4.webcomindia.net. > amit.sood.webcomindia.net. 2009090712 86400 7200 3600000 86400 > > Maybe the zone administrator intended to change the NS names, but did > that the wrong way.
Perhaps. This is also something the registry is supposed to be checking regularly. RFC 1034 As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. Unfortunately lots of TLD administators think they don't need to follow the proceedures in RFC 1034. All of the TLD administrators took on their roles *after* RFC 1034 was written so they have no excuse to not ensuring that these checks are being made. > I guess some DNS clients won't use the glue records if they are not part > of an authoritative answer, and some clients will try anyway, using the > IP they have from the parent (additional section). > In my case (dig version 9.6) 'dig' does the former, and 'dig +trace' the > latter. > > I have already had a similar issue, see : > https://lists.isc.org/pipermail/bind-users/2010-December/082051.html > for example. > > Regards, > > Laurent > _______________________________________________ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
