Due to scheduling conflicts, I'll have to cancel the announced Beer
Event on Monday, 3rd December 2018.
It seems, the Beer Events have come to an end. If someone would like to
take the lead for 2019, please let me and/or Steven know off-list.
Viktor (aka Stony)
We sometimes get requests from business customers, with own mailserver,
which directly receives email via smtp, for an outgoing smtp-relay.
I then argue with:
* Their server is absolutely capable of sending emails directly
* They have better control of the sending process.
* They can look for problem them self in their logs.
* Anti-Spam thresholds aimed at end users, not companies.
* They are not affected if another customer is spaming and therefore the
IP of the relay blacklisted.
But still, I then often get an "BUT... you are our ISP, isn't it your
duty to offer such a relay service? Other ISP do this!"
rly? Do other ISP still offer smtp relaying services to business
customers with own email infrastructure?
Mit freundlichen Grüssen
I m p r o W a r e A G - Leiter Commerce Kunden
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
I'm currently experimenting to host DNS zones on dynamic IP addresses
and dynamic DNS.
But I'm encountering more difficulties than expected on "broadband
connections" in receiving UDP port 53 DNS query packets. In one case
they're filtered completely (TCP port 53 works, UDP port 53 is blacked
out), while on some there seems to be some adaptive filtering requiring
like 10 minutes to "open up".
Does this ring a bell? I would be thankful about any hint what could be
interfering, PM or here.
Could someone from Sunrise contact me off-list?
We received a message about an invalid ROA of one of our customers IP-ranges, which is managed by Sunrise.
I've tried contacting ip-reg(a)sunrise.net multiple times already, but I'm not getting any response.
Teamleader Network & Security
Phone: + 41 44 872 20 00
Direct: + 41 44 872 20 30
Mobile: + 41 79 421 17 78
for your information, SWITCH will perform a DNSSEC algorithm rollover
from RSA to ECDSA for ch. and li.
ECDSA uses smaller keys and signatures than their RSA counterparts,
which means responses to DNS queries are smaller.
ECDSA was already standardised for use in DNSSEC in 2012. While
switch.ch has been signed with ECDSA since 2016, IANA the root zone
operator has only recently allowed TLDs to use it.
The changes to the ch. and li. zones DNSKEY record are as following with
times reported in UTC:
2018-11-21T13:30 Add new ECDSA key to DNSKEY record set
2018-12-21T13:30 Remove old RSA key from DNSKEY record set
Between this interval, the chain of trust for ch. and li. will be
updated in the root zone to point to the new ECDSA key only.
Operators of DNSSEC validating DNS resolvers do not need to do anything.
In the unlikely case that your validating DNS resolver only understands
RSA but not ECDSA, then it will answer to ch. or li. queries as if they
were not DNSSEC signed.
You can test which DNSSEC algorithms are supported by the DNS
resolver(s) configured on your system by visiting:
Daniel Stirnimann, SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 24
It seems like Salt is no longer supplying their own DNS servers when
establishing an LTE connection. Instead, the network responds with Google DNS
servers (126.96.36.199 188.8.131.52).
Is there a particular reason for that?
I'd rather not send all my DNS requests to Google.
Perhaps it's time to switch to private resolvers everywhere, if not even ISPs
are providing that service any more...
Thanks for any info.