'[RFCI-Discuss] Why NXDOMAIN should not be cause for de-listing or'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rfci-discuss
Subject:    [RFCI-Discuss] Why NXDOMAIN should not be cause for de-listing or
From:       Administrative Account <hostmaster () Plectere ! com>
Date:       2005-09-30 14:55:30
Message-ID: 200509301455.j8UEtUP7011305 () Plectere ! com
[Download RAW message or body]

	This is a new thread, but related to the abuse of host/server
entries in Whois previously reported/discussed.

	It is seemingly important that the return code of NXDOMAIN from a
DNS query *not* be a valid reason for de-listing a domain because it can
trivially be controlled/manipulated by the domain's operator.  Quite likely
this is arguably a flaw in the system, but it does exist and *is* being used
to avoid blacklisting on other lists.  Until it is "fixed" in a systematic
fashion, it is important the rfci actually strictly use the criteria, as
listed, on the rfci site.

	For a proof by example of how this may be performed, immediately
below are a sequence of steps that will allow a domains operator to change
back and forth the response of a DNS query from the normally expected response
to and from NXDOMAIN, all the while maintaining the domain's status at the
registrar and at the internic/ICANN.

	This example uses specific registrars, because their policies and
typical update times are known to me, but the same or a similar sequence
will work (possibly with different delays involved) at all except a few
registrars (who are the exceptions and also are the ones who often check
registration data thoroughly - the exceptions in the industry).  Please
note the choice of GoDaddy is not accidental - they are one of the rare
registrars for whom this generally would not work (they however are subject
to the same manipulation if the domain was transferred to them rather than
created at their registry - they only check at creation time, when a domain's
registration records are modified or when a complaint is filed - not when a
domain is transferred).

--------------------------------------------------------------------------------
	Create domain_a.tld at GoDaddy

	Create "listed hosts" ns{0,1,2,3}.domain_a.tld also at GoDaddy
	Set the name servers for domain_a.tld to ns{0,1}.domain_a.tld (or
	any other valid name servers)

	Create domain_b.tld at Network Solutions
	Set the name servers to ns{2,3}domain_a.tld

	Allow domain_b.tld's record to propagate to the roots (between
	a few minutes to a couple of hours).

	The domain domain_b.tld now "resolves" via the traditional tests.

	For some reason, domain_b.tld gets listed at rfci

	At GoDaddy, delete the hosts ns{2,3}domain_a.tld

	wait ~1hr.

	Apply for de-listing domain_b.tld since there are no valid name
	servers in the roots and  a value of NXDOMAIN is returned to any
	DNS query on domain_b.tld.

	domain_b.tld gets de-listed at rfci

	Re-Create "listed hosts" ns{2,3}.domain_a.tld also at GoDaddy or
	even at yet a third registrar, such as BookMyName or eNom (with
	the added advantage, that getting domain_a.tld suspended or
	de-listed will not ever remove the server/host entries - different
	registrar!).

	wait ~1hr.  Now the domain resolves "normally" again (without NXDOMAIN)
--------------------------------------------------------------------------------

	NOTE:  Even when a check of the roots returned NXDOMAIN, most Windows
clients could/would still resolve the domain as long as ns{2,3}.domain_a.tld
were in the zone file for domain_a.tld - so domain_b.tld is "almost" fully
functional during the entire manipulation process.

	Also, that the status of domain_b.tld in Whois as noted from either
the registrar or from the internic is invariant throughout this process.
Further, if the registration data was bogus (as it was for himhelp.com),
the data is still bogus after this process;  An addition advantage (to the
domain operator) is that any mail delivery from most *nix hosts will bounce
with a "Host not found" cause during the period of the manipulation if any
delivery is attempted in that time frame.

	By a similar argument, a test on NXDOMAIN prevents any domain without
name servers, though valid in the eyes of the internic/ICANN from ever being
listed at all (examples previously given were all cleared by the registrar
yesterday - so someone does read these diatribes - but more examples are
available).  The previous option of listing a domain in rfci's whois list
by virtue of no valid name servers was argued against (compellingly) by
Derek about two months ago - sp now we have a situation where any domain
with no name servers gets a "free ride", no matter how bogus the registration
data is, or whether the domain can be used for any purposes (even if just to
justify the creation of host/server records at the same or some different
registrar - which then also get a "free ride").

	Paul Shupak
	track@plectere.com
_______________________________________________
RFCI-Discuss mailing list
RFCI-Discuss@lists.megacity.org
http://lists.megacity.org/mailman/listinfo/rfci-discuss
[prev in list] [next in list] [prev in thread] [next in thread] 