[swinog] Anyone else lost traffic around 15:10?

2008-03-27 Diskussionsfäden Matthias Hertzog
Situation is back to normal again, but we saw decreased incoming traffic 
here. Anyone else?


Best wishes,
Matthias
_

mhs @ internet AG
Z├╝rcherstrasse 204, CH - 9014 St. Gallen
Phone +41 71 274 93 93, Fax +41 71 274 93 94
http://www.mhs.ch
_





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Anyone else lost traffic around 15:10?

2008-03-27 Diskussionsfäden Fredy Kuenzler

Matthias Hertzog schrieb:

Situation is back to normal again, but we saw decreased incoming
traffic here. Anyone else?


We had a ugly DDOS to a customer's network, situation is resolved now,
customer is offline ...

Sorry for the circumstances.

F.
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Anyone else lost traffic around 15:10?

2008-03-27 Diskussionsfäden Tonnerre Lombard
Salut, Silvan,

On Thu, 27 Mar 2008 15:42:42 +0100, Silvan Gebhardt wrote:
 here is what I saw:
 
 http://82.197.169.72/cgi-bin/smokeping.cgi

The inside view:
https://admin.ffii.org/cgi-bin/smokeping.cgi?start=2008-03-27+14%3A45end=2008-03-27+15%3A45target=World.Switzerland.Zurich.SolnetTIX1displaymode=nGenerate%21=Generate%21

Apparently (and also conforming with Init7's publications), the Layer
One gate routers smoked out due to heavy traffic load. (This matches
the patterns we observed and which are also partially reflected in the
graphs.)

It could have been worse though; 20 minutes later, the problem was
dealt with.

Tonnerre


signature.asc
Description: PGP signature
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Rant about DNS and TCP [was: Re: [swinog] Has Bluewin a DNS Problem]

2008-03-27 Diskussionsfäden Simon Leinen
Claudio Jeker writes:
 Until recently only AXFR was using tcp,

If you look at the original DNS specs, i.e. RFC 1035, RFC 1123, etc,
you will find that the protocol always specified that any DNS queries
can be performed over TCP.  In particular, this is the normal fallback
method when a query over UDP results in a truncated (TC) response.

Actually, in the olden days there were even resolver implementations
that *only* supported TCP for DNS queries, cf.
http://www.ops.ietf.org/lists/namedroppers/namedroppers.199x/msg01855.html
(I'm not saying this was a good idea :-)

Then people stopped listening to Jon Postel's (may he rest in peace)
advice to be liberal in what you expect, conservative in what you
send.  Instead, concerns of security and short-term optimization
and punishing people with stupid (= unexpected) configurations
became more important.  So IT people and their consultants and ISPs
started to block DNS over TCP in many places, often leaving it open
only for zone transfers, and felt good about it.  Thus the new (you
call it old, maybe I'm just an old fart) rule was born:

 normaly resolver queries had to be udp.

Some people tried to evolve the DNS to carry other information, such
as IPv6 addresses, digital signatures (actually meta-information to
make DNS information more trustable), mail policy information.  And
some zones (such as the root) wanted to have many nameservers for
robustness.

So suddenly, the 512 byte (yes, 512 bytes!) limit became a real issue,
as fallback to TCP would very often just Not Work.

 This rule was a bit relaxed because of the increased space needed
 for IPv6 but many authorative dns servers will only listen to UDP
 port 53 requests..

I would say, the new rule (if you use TCP for DNS queries other
than AXFRs, then you are stupid/up to no good, so I will block you)
proved to harm the long-term evolution of the DNS protocol - as is
quite often the case with these kinds of security best practices
that violate transparency and other design principles.  But since such
rules are/were best practices, you can never really get rid of them.

So what happened instead is that the DNS protocol was extended to
support larger-than-512-byte queries over UDP (EDNS0, RFC 2671).
While dig doesn't use EDNS0 by default (but see the example below),
modern recursive nameservers should normally make use of this, so that
fallback to TCP isn't necessary that often.

The fact that EDNS0 was added to the DNS is probably a good thing.
But I think it would also be good if DNS over TCP generally worked.
Although TCP does have higher overhead than UDP for typical DNS usage,
it has some security advantage, e.g. it is much harder to spoof
requests.

So to me this is another example of short-sighted and badly
thought-out security thinking that has harmed progress and brought
dubious security improvements at best.

Note that some people consider EDNS0 a security risk, because it
facilitates reflection attacks with UDP DNS requests from spoofed
(victim) source addresses that result in very large responses to be
sent to the victim.
-- 
Simon.

$ dig @www.multipop.ch. +edns=0 ptr -x 195.141.232.78

;  DiG 9.5.0a6  @www.multipop.ch. +edns=0 ptr -x 195.141.232.78
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 895
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 30, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;78.232.141.195.in-addr.arpa.   IN  PTR

;; ANSWER SECTION:
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.spacebbs.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.amigaland.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.augsauger.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.begegnung.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.satvision.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.hackernews.ch.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.natel-news.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.satanlagen.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.satantennen.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.wiso-schoch.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.xariffusion.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.sat-receiver.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.estherundpetr.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.luisenstrasse.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.arthurandersen.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.elektronik-news.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.zuerichsee-gastro.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.pop.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.rtv.ch.
78.232.141.195.in-addr.arpa. 38400 IN   PTR mailhost.dsng.ch.