[tor-relays] Recommended specifications for 1Gbps exit

[Matt Joyce]

On 05/03/13 03:29, Steve Snyder wrote:
>
> On 02/26/2013 08:46 AM, Matt Joyce wrote:
>> I am wondering if anyone with experience in this area could advise me
>> some on recommended specifications for a 1Gbps exit
> [snip]
>
> What DNS configuration will/are you using to handle the avalanche of
> resolution requests?
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I considered that a possible concern also I have set up a local bind 9
daemon on the server as a DNS cache and also because I believe it is
probably better at handling issues if an upstream server is performing
poorly especially when give multiple options for forwarding.  Currently
it forwards on to the hosts DNS or alternatively to google public DNS
who have servers very close response times on both (8.8.8.8 and 8.8.4.4)
are around 4.5msec so I'm guessing that Google likely has a facility
close by probably in the Amsterdam area for the peering opportunities at
AMS-IX.

The setup seems to be working well enough for now, usage is at 110Mbit/s
each direction and I'm not seeing any unusual number eventdns messages,
there are some but presumably tor can't tell if it is receiving a
servfail reply because of a local issue or because the authoritative
servers for the domain are failing which will produce the same.  Not
sure if it makes much of a difference as network doesn't appear to be a
bottleneck but traffic prioritisation is set with TC such that UDP dpt
53 is handled at a higher priority than the outgoing TCP traffic, would
rather get the small time sensitive packets on the wire than have them
waiting for a batch of full sized TCP packets which I figure can better
handle a que anyway, after all a TCP receiver application has to expect
and hopefully sanely handle retransmission delay of 2*RTT or more.

Having the local DNS server does have a small cost the named process
uses ~1-2% of a core worth of CPU time and around 2% RAM but it's fairly
minor, average incoming query load calculated based on the totals for
~29h is approx 11.234qps.  7,980 SERVFAIL results from 1,169,495 queries
or around 0.7% low enough I suspect most are probably failure of the
authoritative server or transient reachability issues.

Query RTT Stats (Based on 1,651,610 queries sent)
541,253 queries with RTT < 10ms
616,239 queries with RTT 10-100ms
247,249 queries with RTT 100-500ms
12,565 queries with RTT 500-800ms
17,740 queries with RTT 800-1600ms
2,307 queries with RTT > 1600ms

The DNS server does have DNSSEC validation also, disabling that would
almost certainly reduce load as it results in additional queries for the
needed records DNSKEY, DS etc but at the moment it's working well so
doesn't hurt to leave it on and hopefully help make the network that
little bit more resistant to possible cache poisoning attacks as well,
at least for clients that don't have their own validating resolvers
which I believe still includes a number of browsers unless plugins have
been installed to add it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20130305/ada5c2c9/attachment.pgp>