On Mon, Aug 16, 2004 at 02:12:00PM +0200, Lee Wilmot wrote:
The reason for ns-sec.ripe.net returning an answer is an unfortunate curiousity of RIPE NCC's current nameserver rearrangement which is irrelevant since it will never be listed as a nameserver for 2.0.0.2.ip6.arpa.
BTW... $ dig ip6.arpa. NS @a.root-servers.net. +short NS.APNIC.NET. NS.ICANN.ORG. NS.RIPE.NET. TINNIE.ARIN.NET. $ dig ip6.arpa. NS @ns.ripe.net +short ns.apnic.net. ns.icann.org. ns-sec.ripe.net. tinnie.arin.net. NS RRset in zone ip6.arpa is not matching the NS RRset for ip6.arpa in the root zone. ns.ripe.net != ns-sec.ripe.net by IP address, but still both are auth for 2.0.0.2.ip6.arpa: $ dig @ns.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 $ dig @ns-sec.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 So the relevance is given, no matter why ns-sec gets involved (because the in-zone NS RRset overwrites the NS RRset from the roots in caches). I think it would be a good idea[tm] to remove the 2.0.0.2.ip6.arpa zone from ns.ripe.net and ns-sec.ripe.net if you don't intend to publish the zone... Best regards, Daniel