Re: ICANN RFC regarding Verisign's TLD wildcard A records - TCP-IP

This is a discussion on Re: ICANN RFC regarding Verisign's TLD wildcard A records - TCP-IP ; Doug Barton wrote: >The Security and Stability Advisory >Committee is sincerely interested in your feedback regarding this >issue. We are currently working on a report that details the impacts >of wildcards at the TLD level, and elsewhere as appropriate. > ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Re: ICANN RFC regarding Verisign's TLD wildcard A records

  1. Re: ICANN RFC regarding Verisign's TLD wildcard A records


    Doug Barton wrote:
    >The Security and Stability Advisory
    >Committee is sincerely interested in your feedback regarding this
    >issue. We are currently working on a report that details the impacts
    >of wildcards at the TLD level, and elsewhere as appropriate.
    >
    >I would like to request that you restrict your comments to actual
    >operational issues. That will help ensure that they get due
    >consideration. We're most interested in issues related to things
    >that worked before, but don't now; and particularly interested in
    >non-obvious cases. Of course, if you have other points of interest on
    >this topic, we're all ears.
    >
    >The e-mail address for your feedback is secsac-comment@icann.org.


    To: secsac-comment@icann.org
    Subject: Re: ICANN RFC regarding Verisign's TLD wildcard A records

    1) The new wildcard A records have broken an important component
    of our spam filters. The time spent dealing with these unsolicited
    emails, and attempting to maintain effective filters, has been
    substantial.

    2) This change has also broken several of the software applications
    we use for domain management, security auditing, and reporting
    spam and network abuse.

    3) Many of the query strings captured by sitefinder.verisign.com
    were not intended to be accessible by third parties. They contain
    usernames, passwords, session and encryption keys, even business
    plans and other confidential information which is all too easily
    warehoused and parsed for economic espionage. End users have
    (had) a reasonable expectation that these URL strings would remain
    private to their local computers and a remote web server.

    4) Such large-scale changes to a critical resource such as DNS,
    without public discussion, notification, or pilot testing,
    illustrates Verisign's excessive risk tolerance, lack of technical
    competence, and disregard for established standards.

    That said the best way to prevent the root server wildcard problem
    from occurring in the future would be to:

    A) restrict root server operators from replying to queries with
    anything other than than NXDOMAIN or NS records,

    B) restrict root server operators from making any changes whatsoever
    without prior public discussion and ICANN approval, and

    C) enjoin Verisign and other DOC contract-holders from acting as
    both a root operator and registrar, or whois operator and registrar,
    or whois operator and root operator, or any other similar conflict
    of interest.

    This latest incident should not be considered separately from
    Verisign's other abuses of the public trust:

    D) by arbitrarily restricting domain owners ability to change
    registrars at will, free from anti-competitive time frames or
    other non-technical considerations,

    E) by illegally holding expired domains. Expired domains are
    public property and should not be "held" by any entity much less
    a registrar, and finally

    F) by Verisign's changing the format of replies to whois queries
    at will.

    The fundamental problem is that ICANN and the US Department of
    Commerce have failed to enact reasonable regulations to protect the
    public interest. This is how Verisign has come to consider themselves
    free to enact such a cornucopia of self-serving, consumer-averse
    policy changes few of which have any technical merit.

    I sincerely hope ICANN considers this most recent incident as the
    proper occasion to close these regulatory loopholes and end all
    contracts with Verisign and its subsidiaries, if not for the public
    trust then for the social and economic interests which depend on a
    secure and reliable Internet.

    Sincerely,
    --
    Roger Marquis
    Roble Systems Consulting
    http://www.roble.com/

  2. Re: ICANN RFC regarding Verisign's TLD wildcard A records

    Roger Marquis said:

    A very well written piece, to which I can only add -

    > F) by Verisign's changing the format of replies to whois queries
    > at will.


    They've had the creation dates incorrect for some months now too.

    Billy Y..

  3. Re: ICANN RFC regarding Verisign's TLD wildcard A records

    In article , abuse@MIX.COM (abuse@MIX.COM) writes...
    > Roger Marquis said:
    >
    > A very well written piece, to which I can only add -
    >
    > > F) by Verisign's changing the format of replies to whois queries
    > > at will.

    >
    > They've had the creation dates incorrect for some months now too.



    That only appears to apply to certain registrars, ie if you're
    registered with Verisign.

    The top of the whois query shows the correct date(s), the
    body of the query where the details are is where it is
    frequently wrong.



    --
    * Few people are capable of expressing with equanimity opinions which *
    * differ from the prejudices of their social environment. Most people are *
    * even incapable of forming such opinions. -- Albert Einstein *
    * *
    * To send email, remove numbers and spaces: pjkusenet64 @ ekahuna27 . com *
    * Simple answers are for simple minds. Try a new way of looking at things. *

  4. Re: ICANN RFC regarding Verisign's TLD wildcard A records

    RM> the [...] way to prevent the root server wildcard
    RM> problem from occurring in the future [...]

    .... and to prevent the "com."/"net." server wildcard problem from
    _re_occurring (by applying the restrictions to the "com."/"net." server
    operator(s), _as well as_ to the _root_ server operators, which is what you
    suggested) ...

    RM> A) restrict root server operators from replying to queries with
    RM> anything other than than NXDOMAIN or NS records,

    This is the wrong actual restriction. The restriction should be that such
    operators be prevented from employing wildcards to generate responses, _not_
    that operators be restricted as to what types of resource record sets they be
    able to publish. (For example: As written, your restriction prevents the
    publication of "A" and "AAAA" resource record sets by "." content DNS servers
    and thus breaks query resolution completely, rendering the DNS completely
    inoperative.) The problem is the generation of synthetic data from wildcards,
    not the use of various types of resource record sets. Address the actual
    problem with any preventative measures. It is the owner domain names of the
    resource records being published, not their types, that should be the focus of
    any restriction.

    RM> B) restrict root server operators from making any changes
    RM> whatsoever without prior public discussion and ICANN
    RM> approval,

    ICANN does not, and cannot, have the power to disapprove what all "." content
    DNS server operators do. It can only have the power to disapprove what _its
    own_ "." content DNS server operators do.

    Of course, this restriction is silly if one wants to apply it to "com." and
    "net." content DNS server operators (where the problem actually lies in this
    case) as well as to "." content DNS server operators. It calls for every
    "com."/"net." subdomain registration, modification, and deletion ("any changes
    whatsoever") to be subject to public discussion.

  5. Re: ICANN RFC regarding Verisign's TLD wildcard A records

    In ba.internet Jonathan de Boyne Pollard wrote:
    >It is the owner domain names of the resource records being published,
    >not their types, that should be the focus of any restriction.


    That would never fly, especially not in this case since nobody "owns"
    ..com despite Verislime's behaving as if they did. The point may be mute
    since ISC's bind patches, and all future releases, already restricts
    the types of responses accepted from root operators.

    >RM> B) restrict root server operators from making any changes
    >RM> whatsoever without prior public discussion and ICANN
    >RM> approval,
    >
    >ICANN does not, and cannot, have the power to disapprove what all "." content
    >DNS server operators do. It can only have the power to disapprove what _its
    >own_ "." content DNS server operators do.


    In fact it can and does.

    Palo

  6. Re: ICANN RFC regarding Verisign's TLD wildcard A records

    In ba.internet Roger Marquis wrote:
    >This latest incident should not be considered separately from
    >Verisign's other abuses of the public trust:
    >
    > D) by arbitrarily restricting domain owners ability to change
    > registrars at will, free from anti-competitive time frames or
    > other non-technical considerations,
    >
    > E) by illegally holding expired domains. Expired domains are
    > public property and should not be "held" by any entity much less
    > a registrar, and finally
    >
    > F) by Verisign's changing the format of replies to whois queries
    > at will.


    Don't forget the $100/domain/year Veriscum ripped us off for when they
    had sole control over .com, net, and org. They kept charging $100 until
    ICANN could establish competing registrars despite independent analysis
    which showed the cost of that service was $7 per year.

    I think a better "root solution" would be to put ICANN under the EU and
    as far from the US Department of Commerce and Congress as possible.
    The DOC and US Congress have time and time again proven themselves
    too amenable to special influence (by corporation$ like Verislime),
    too technically naive, and too unconcerned with the rights of consumers
    to be trusted with this task.

    Palo

  7. Re: ICANN RFC regarding Verisign's TLD wildcard A records

    JdeBP> It is the owner domain names of the resource records being
    JdeBP> published, not their types, that should be the focus of any
    JdeBP> restriction.

    a> That would never fly, especially not in this case since nobody
    a> "owns" .com despite Verislime's behaving as if they did.

    I see that you don't understand the term "owner domain name" when
    applied to resource records. This is "owner" in the sense used in
    RFC 1034 section 3.6.

    a> The point may be mute since ISC's bind patches, and all future
    a> releases, already restricts the types of responses accepted
    a> from root operators.

    .... and thus opens up a vector for denial-of-service attacks that I
    pointed out in "comp.protocols.dns.bind" nearly a week ago and then
    documented alongside the flaws in all of the other published mechanisms.
    (I'm refraining from doing any more such unpaid debugging work for the
    benefit of ISC for a while, though.)



    The word is "moot", by the way.

    JdeBP> ICANN does not, and cannot, have the power to disapprove what
    JdeBP> all "." content DNS server operators do. It can only have the
    JdeBP> power to disapprove what _its own_ "." content DNS server
    JdeBP> operators do.

    a> In fact it can and does.

    Rubbish. ICANN does not, and cannot, have the power to disapprove
    what (to pick an example at random) PacificRoot's "." content DNS
    server operators do. ICANN does not, and cannot, have the power to
    disapprove what people who operate their own "." internal content
    DNS servers do.

    ICANN can only have the power to disapprove what _its own_ "."
    content DNS server operators do.

  8. Re: ICANN RFC regarding Verisign's TLD wildcard A records

    a> I think a better "root solution" would be to put ICANN under
    a> the EU and as far from the US Department of Commerce and
    a> Congress as possible.

    Handing ICANN from one government to another is not the answer.
    Moreover, if you claim that an ICANN clone that is Euro-centric
    is the answer, how come the fact that ORSN exists right now
    hasn't already solved the problem ?

    ICANN is only the problem if it, and the other root server
    organizations, fail to rein Verisign in. Until that point,
    it is _Verisign_ that is the problem.

  9. Re: ICANN RFC regarding Verisign's TLD wildcard A records

    Jonathan de Boyne Pollard wrote:
    > ICANN does not, and cannot, have the power to disapprove what (to
    > pick an example at random) PacificRoot's "." content DNS server
    > operators do. ICANN does not, and cannot, have the power to
    > disapprove what people who operate their own "." internal content
    > DNS servers do.


    Well. ICANN can certainly disapprove; other roots just wouldn't care
    about that opinion.


    paul

  10. Re: ICANN RFC regarding Verisign's TLD wildcard A records

    JdeBP> ICANN does not, and cannot, have the power to disapprove what
    JdeBP> (to pick an example at random) PacificRoot's "." content DNS
    JdeBP> server operators do. ICANN does not, and cannot, have the
    JdeBP> power to disapprove what people who operate their own "."
    JdeBP> internal content DNS servers do.

    PJ> Well. ICANN can certainly disapprove; other roots just
    PJ> wouldn't care about that opinion.

    Roger meant more than just "forming an opinion" when he talked of ICANN
    approving what "." content DNS server operators do in his letter to SaSAC.

  11. Re: ICANN RFC regarding Verisign's TLD wildcard A records

    apalomoro@donotspam.com wrote:
    > In ba.internet Roger Marquis wrote:
    >>This latest incident should not be considered separately from
    >>Verisign's other abuses of the public trust:
    >>
    >> D) by arbitrarily restricting domain owners ability to change
    >> registrars at will, free from anti-competitive time frames or
    >> other non-technical considerations,
    >>
    >> E) by illegally holding expired domains. Expired domains are
    >> public property and should not be "held" by any entity much less
    >> a registrar, and finally
    >>
    >> F) by Verisign's changing the format of replies to whois queries
    >> at will.


    > Don't forget the $100/domain/year Veriscum ripped us off for when they
    > had sole control over .com, net, and org. They kept charging $100 until
    > ICANN could establish competing registrars despite independent analysis
    > which showed the cost of that service was $7 per year.


    > I think a better "root solution" would be to put ICANN under the EU and



    DON'T involve EU in anything importent. ( and lets continue the
    political discussion somewhere else).



    > Palo


    --
    Peter Håkanson
    IPSec Sverige ( At Gothenburg Riverside )
    Sorry about my e-mail address, but i'm trying to keep spam out,
    remove "icke-reklam" if you feel for mailing me. Thanx.

  12. Re: ICANN RFC regarding Verisign's TLD wildcard A records

    Jonathan de Boyne Pollard writes:

    > ICANN is only the problem if it, and the other root server
    > organizations, fail to rein Verisign in. Until that point,


    You mean, like now...?? I notice nothing at all has changed.

    Billy Y..

  13. Re: ICANN RFC regarding Verisign's TLD wildcard A records



    apalomoro@donotspam.com wrote:

    > In ba.internet Roger Marquis wrote:
    >>This latest incident should not be considered separately from
    >>Verisign's other abuses of the public trust:
    >>
    >> D) by arbitrarily restricting domain owners ability to change
    >> registrars at will, free from anti-competitive time frames or
    >> other non-technical considerations,


    I have a problem with this idea.

    I currently am involved with a small business domain that became unavailable around the 25th of September. (Will not
    resolve). My cheap host provider either would not or could not fix it. All I know is that they would not communicate
    with me.

    I am the domain owner, And I should be able to take that domain name anywhere I please, even if I have to pay for
    another domain year; that's not a big deal. However all the Search engine entries pointing to it IS a big deal.

    My new host provider can't make it work either, and I am still out of service. My new host provider does not have a
    business relationship to my registrar so I have to manage it. I don't like that.


+ Reply to Thread