At 9:42 PM +0000 11/27/07, [EMAIL PROTECTED] wrote:
but its not example.orgs call if ns.isi.edu changed its ip
address to 127.0.3.12... is it? that would be the call of the
admin for ns.isi.edu.
Yeah - but - it is example.org's call to de-list ns.isi.edu because
of the change. I mean, what if ns.isi.edu changes it's name to
ns1.isi.edu, or becomes IPv6 only (and there's no way for
example.org's admin to reach it anymore)? Or changes the admin to
some organization you don't want to deal with?
Anyway, this is a red herring. The issue isn't about example.org
crimping ns.isi.edu's style, it's about example.org maintaining more
information about its delegation. When the change happens at
ns.isi.edu, the correct next step is to have example.org change the
IP it registers.
and if there were no contact information on that nameserver in
the form of a HOST record in the whois or comments (w/ glue) in
the DNS, then debugging an apparent problem is going to be much
harder. one could ask if its a service that the .org registry
is willing to offer on behalf of its clients and the Internet
community,
My assumption is that debugging requires getting on the phone and
getting a live support person somewhere or maybe even a legal request
for information. (Being without a law degree, I can't correctly
spell "subpeona.") The time is long gone when I can look something
up on-line and feel I have a reasonable handle on debugging a
situation. I suspect that these extra IP addresses might at best be
in WhoIs, but more likely just filed away somewhere internally as
they have no operational (packet-flowing) value.
Frankly though, I don't see this information collection happening
unless there is some strong motivation given.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Think glocally. Act confused.
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
