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

This is a discussion on Don't do what the "dnslife.com" announcement invites you to do. - TCP-IP ; [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 ...

+ Reply to Thread
Results 1 to 2 of 2

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

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

    [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.

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

    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.

+ Reply to Thread