Verisign's wildcards and TTLs - TCP-IP

This is a discussion on Verisign's wildcards and TTLs - TCP-IP ; One thing I haven't seen mentioned among the many postings on Verisign's obnoxious addition of wildcards *.com and *.net is the effect on TTLs, and hence on caching. The responses generated from the wildcards have a TTL of 15 minutes. ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Verisign's wildcards and TTLs

  1. Verisign's wildcards and TTLs

    One thing I haven't seen mentioned among the many postings on Verisign's
    obnoxious addition of wildcards *.com and *.net is the effect on TTLs,
    and hence on caching. The responses generated from the wildcards have
    a TTL of 15 minutes. This is much smaller than the negative TTLs from
    the SOAs for the zone, which are 1 day. Of course, many servers use a
    cutoff value on negative TTLs shorter than that (e.g. 3 hours is the
    BIND default) but even so the result is that the positive responses
    will be cached for a much shorter time than the previous NXDOMAIN
    responses were.

    Chris Thompson
    Email: cet1 [at] cam.ac.uk

  2. Re: Verisign's wildcards and TTLs

    In article ,
    Chris Thompson wrote:
    >One thing I haven't seen mentioned among the many postings on Verisign's
    >obnoxious addition of wildcards *.com and *.net is the effect on TTLs,
    >and hence on caching. The responses generated from the wildcards have
    >a TTL of 15 minutes. This is much smaller than the negative TTLs from
    >the SOAs for the zone, which are 1 day. Of course, many servers use a
    >cutoff value on negative TTLs shorter than that (e.g. 3 hours is the
    >BIND default) but even so the result is that the positive responses
    >will be cached for a much shorter time than the previous NXDOMAIN
    >responses were.
    >
    >Chris Thompson
    >Email: cet1 [at] cam.ac.uk


    And now instead of one negative cache entry you have one per
    type queried other than A.

    For SMTP

    A record
    -ve AAAA
    -ve MX vs -ve NXDOMAIN
    -ve CNAME

    Three+ times the cache load.

    Mark

  3. Re: Verisign's wildcards and TTLs

    >>One thing I haven't seen mentioned among the many postings on Verisign's
    >>obnoxious addition of wildcards *.com and *.net is the effect on TTLs,
    >>and hence on caching. The responses generated from the wildcards have
    >>a TTL of 15 minutes. This is much smaller than the negative TTLs from
    >>the SOAs for the zone, which are 1 day. Of course, many servers use a
    >>cutoff value on negative TTLs shorter than that (e.g. 3 hours is the
    >>BIND default) but even so the result is that the positive responses
    >>will be cached for a much shorter time than the previous NXDOMAIN
    >>responses were.
    >>
    >>Chris Thompson
    >>Email: cet1 [at] cam.ac.uk

    >
    > And now instead of one negative cache entry you have one per
    > type queried other than A.
    >
    > For SMTP
    >
    > A record
    > -ve AAAA
    > -ve MX vs -ve NXDOMAIN
    > -ve CNAME
    >
    > Three+ times the cache load.
    >
    > Mark


    Maybe you should try DJBDNS or some other more efficient
    (than BIND) software, to say nothing of the greater security.


    --
    OEM parts - Benz: http://parts.mbz.org BMW: http://buyeuroparts.com
    http://www.mbz.org | Mailing lists: http://lists.mbz.org
    633CSi 250SE/C 300SD | Classifieds: http://ads.mbz.org
    2 X 280SE | Wrist Watch list: http://watches.list.mbz.org

  4. Re: Verisign's wildcards and TTLs

    In article , Richard J. Sexton (At work) replied
    to ISC's Mark Andrews:

    > Maybe you should try DJBDNS or some other more efficient
    > (than BIND) software, to say nothing of the greater security.


    :-)

    Unless I am mistaken Mark Andrewws is one of the developers of BIND.
    --
    #include adamo+news@dblab.ece.ntua.gr
    Don't be silly. People who have a life don't post on Usenet. --Maarten Wiltink

  5. Re: Verisign's wildcards and TTLs

    MA> A record
    MA> -ve AAAA
    MA> -ve MX vs -ve NXDOMAIN
    MA> -ve CNAME
    MA>
    MA> Three+ times the cache load.

    Actually four, counting the rows in Mark's own diagram.

    RJS> Maybe you should try DJBDNS or some other more efficient
    RJS> (than BIND) software, to say nothing of the greater security.

    Whilst Mark's comments in the past about the impact of various things upon
    BIND's caching have indicated that it is, according to him, surprisingly far
    less efficient in this area than "dnscache" is, an increase in cache load will
    occur when using "dnscache" too.

+ Reply to Thread