Pinging Lumen and RADB (was: Notice to IRRd operators)
After the change, NTT IRR is correctly mirroring the new IP address (thanks for that), but rr.level3.net and radb.net seem to be stuck with the old IP, and since the old IP address is non-authoritative (flag N), replication to those IRRs has in effect stopped. So, if those two IRR operators could act on it, it would be nice. Thanks, Rubens (on behalf of TC) On Sat, Apr 10, 2021 at 4:27 PM Rubens Kuhl wrote: > > Hi there. > TC, a large IRR database focused on Brazilian networks, just changed its > IP addresses. In most IRRd implementations it's necessary to sighup the > daemon to move to the new IP addresses, so we kindly ask those running > public and private IRR instances to sighup in order to move to the new IP > addresses. > > The new addresses of bgp.net.br are: > bgp.net.br has address 177.128.210.126 > bgp.net.br has IPv6 address 2804:890:0:102::102 > bgp.net.br mail is handled by 10 bgp.net.br. > > The old machine will be up and serving mirroring requests until we see > most, if not all, of requests being served by the new machine. > > Thanks, > TC > >
Re: Time to validate the TLS configuration on your SMTP servers (was: Re: AS5 ipv6 hijack?)
A slightly nicer tool than just using "openssl s_client" is testssl.sh, handles STARTTLS and some other non-trivial cases. https://testssl.sh/ Back when I first used it I did read the source, these days at ~650k of shell script, that's a little less practical. On 12/4/21 10:58 pm, Bjørn Mork wrote: > OK, so that email bounced. Or will eventually because this does not go > away with someone doing something: > > ... Deferred: 403 4.7.0 TLS handshake failed. > > I am posting this in public because it unfortunately is a very common > problem. > > Debian buster was released on July 6th, 2019. It includes openssl 1.1.1 > with this configuration update among number of other improvements: > > openssl (1.1.1~~pre6-1) experimental; urgency=medium > > * New upstream version > * Increase default security level from 1 to 2. This moves from the 80 bit > security level to the 112 bit securit level and will require 2048 bit RSA > and DHE keys. > > -- Kurt Roeckx Tue, 01 May 2018 16:00:55 +0200 > > > I assume similar policies have been applied to all modern and maintained > operating systems by now. > > Everyone should verify their own SMTP servers to avoid losing email due > to TLS failures. Doing so is simple from e.g Debian: > > > bjorn@canardo:/usr/local/src/openwrt$ cd > > > bjorn@canardo:~$ host interhost.net > > > interhost.net has address 185.18.204.66 > interhost.net mail is handled by 10 pineapp.interhost.co.il. > > bjorn@canardo:~$ openssl s_client -quiet -connect pineapp.interhost.co.il:25 > -starttls smtp > depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global > Root CA > verify return:1 > depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL RSA CA > 2018 > verify return:1 > depth=0 CN = *.interhost.co.il > verify return:1 > 139901908640896:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too > small:../ssl/statem/statem_clnt.c:2150: > > > The fix obviously depends on the server, but is usually as simple as > regnerating the DH parameters. See for example > https://forums.freebsd.org/threads/sendmail-dh-key-too-small.51985/ > > > > Bjørn >
Time to validate the TLS configuration on your SMTP servers (was: Re: AS5 ipv6 hijack?)
OK, so that email bounced. Or will eventually because this does not go away with someone doing something: ... Deferred: 403 4.7.0 TLS handshake failed. I am posting this in public because it unfortunately is a very common problem. Debian buster was released on July 6th, 2019. It includes openssl 1.1.1 with this configuration update among number of other improvements: openssl (1.1.1~~pre6-1) experimental; urgency=medium * New upstream version * Increase default security level from 1 to 2. This moves from the 80 bit security level to the 112 bit securit level and will require 2048 bit RSA and DHE keys. -- Kurt Roeckx Tue, 01 May 2018 16:00:55 +0200 I assume similar policies have been applied to all modern and maintained operating systems by now. Everyone should verify their own SMTP servers to avoid losing email due to TLS failures. Doing so is simple from e.g Debian: bjorn@canardo:/usr/local/src/openwrt$ cd bjorn@canardo:~$ host interhost.net interhost.net has address 185.18.204.66 interhost.net mail is handled by 10 pineapp.interhost.co.il. bjorn@canardo:~$ openssl s_client -quiet -connect pineapp.interhost.co.il:25 -starttls smtp depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL RSA CA 2018 verify return:1 depth=0 CN = *.interhost.co.il verify return:1 139901908640896:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2150: The fix obviously depends on the server, but is usually as simple as regnerating the DH parameters. See for example https://forums.freebsd.org/threads/sendmail-dh-key-too-small.51985/ Bjørn
Re: AS5 ipv6 hijack?
Dmitry Sherman writes: > I see ipv6 bgp hijack of our prefixes via AS5. Or misunderstood prepending attempt, like hijacks from low AS numbers often are? Bjørn
