Don't do what the "dnslife.com" announcement invites you to do.

  • Thread starter Thread starter Jonathan de Boyne Pollard
  • Start date Start date
J

Jonathan de Boyne Pollard

[This is cross-posted to the same places that the announcement was
multi-posted, in order to save the unsuspecting, who might otherwise have
naïvely trusted it and done as it suggests, any grief.]

KD> Here is our new site. It will take everyone to make it happen.
KD> [...]
KD> all are invited to set their name server info to 64.146.111.234
KD> to join our community or to just look around.

I strongly recommend _not_ changing one's "name server info" to
64.146.111.234. The DNS server listening on that IP address is both grossly
misconfigured and egregiously broken.

One example of its gross misconfiguration is that in response to an "NS" query
for "." it returns a list combining the "." content DNS servers from two
entirely separate "." content DNS service organizations, with itself included
as well (seemingly just for the heck of it). This is a recipe for disaster -
even for a _working_ DNS server software.

One example of its brokenness is that it cannot decide whether domain names
exist or not. Ask it an "A" query for "aroot.pacroot." (the intermediate name
of one of the "." content DNS servers that it lists) and it will return an "A"
resource record. Ask it another type of query for that very same domain name,
and it will respond with either "no such name" or "server failure".

Another example of its brokenness is that in response to queries with the RD
bit set to 0 it returns empty resource record sets, even where the responses
to the same queries with the RD bit set to 1 show that it has the real
(non-empty) answers in a cache, and _even_ where the cached answer would
actually be a "no such name" answer.

Next to the sheer wrongness of the responses that the software used by the
64.146.111.234 DNS server gives and the incompetent way that that DNS server
has been configured, the fact that the content HTTP server for the relevant
web site doesn't have virtual hosting correctly configured and operational
seems relatively minor in comparison.
 
d> you can test the server at http://www.dnsstuff.com
d> then you can say more about it. What a little snot.

I can say more about it right now, thank you. Welcome to (amongst the other
newsgroups that you chose to multi-post in)
"microsoft.public.windows.server.dns" and "comp.protocols.tcp-ip.domains",
where you'll find quite a few people who are capable of diagnosing
misconfigured systems running broken softwares, like yours, directly, without
the need for armbands and floatation devices.

It's (alas!) all too consistent with your inept misconfiguration and your
choice of using broken server software that you point for supposed validation
at a suite of web utilities that aren't actually capable of testing a
(non-ICANN) "." content DNS server, such as you are claiming to be providing.
So now we have yet further grounds for recommending that one _not_ change
one's "name server info" to 64.146.111.234, in addition to the reasons already
posted: Its administrator doesn't appear to have actually tested its "."
content DNS service, because he/she refers to testing it with tools that are
entirely unsuited for that purpose.

I strongly recommend that you obtain a DNS diagnosis tool such as "dnsqry",
"dnsq", "dig", "dnsquery", or "askmara", learn how to operate it and what its
output means, and use it to look at the misfunctional mess of your DNS
service.

d> what would you do to fix these "issues"

I'd do at least these:

* Fix the egregiously broken DNS server software, that treats the RD bit
eccentrically and that cannot decide whether domain names exist; either by
complaining to its author (whoever that is) and thereby getting it fixed, or
by simply throwing it away and using a different software ("djbdns",
Microsoft's DNS server, ISC's BIND, or whatever) that can at least provide
content DNS service that works in these respects.

* Follow PacificRoot's instructions, for replicating its DNS data in order to
provide a mirror of its root, _correctly_.

* Configure the content HTTP server so that virtual hosting was actually
working, so that the rest of Internet would see something _other_ than error
pages everywhere.
 
Back
Top