Re: [atlas] Tagging probes which are using the ISP's DNS server?
On this topic: Is there an Atlas-preferred setting for this? Should the probe I host ideally use the ISP's DNS, or ideally a DNS from a global player? Or ideally an academic/non-profit DNS? BR Daniel AJ On 10/5/22 18:38, Max Grobecker wrote: Hi, a few days ago I wanted to debug a name resolution problem of one of our domains. For this reason, I wanted to test if probes inside a specific ASN are having difficulties to resolve a specific name (because only customers of this ISP were complaining). This lead to very mixed results, mostly because some of the selected probes did queries to a public DNS service like Google, Quad9 and so on. The problem existed only with the provider's DNS servers for some reason. It did take some time to make a script which tried to filter out these probes, so I wondered if anyone else had the same use-case and problem. Is there a way to automatically tag probes, which are (seemingly) using the ISP's own DNS servers, or, at least, not a well-known public service? This could be done maybe by querying a special DNS name which returns the IP address from where the query was received (like "whoami.akamai.net"). By comparing the ASN of the probe and the ASN of the IP address returned by the DNS query, one could determine, if the ISP's servers are used. This would also be true for people running their own recursor, but this could be filtered as well very easy. If an ISP is using multiple ASN, this could be a problem. Maybe there's an easy solution for this as well. Probes which pass this test, could then be tagged with "DNS-using-ISP-server" or something like that and explicitly be selected for specific DNS resolution tests. Greetings, Max -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] V5 probes
Have applied for v5 probe just now Colin Sent from my iPod > On 6 Oct 2022, at 06:15, Lia Hestina wrote: > > Hi Colin and all, > > You can request for a replacement when your current probe is broken or has > become unstable. > Kindly apply directly here: https://atlas.ripe.net/apply/ > > Regards, > Lia > >> On 3 Oct 2022, at 13:33, Colin Johnston wrote: >> >> Can someone put me down for a v1 to v5 replacement please ? >> My v1 at present powered by usb from bt homehub >> >> Thanks in advance >> >> Colin >> >> Sent from my iPod >> On 3 Oct 2022, at 12:19, Robert Kisteleki wrote: >>> >> >> -- >> ripe-atlas mailing list >> ripe-atlas@ripe.net >> https://lists.ripe.net/mailman/listinfo/ripe-atlas > -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] V5 probes
Hi Colin and all, You can request for a replacement when your current probe is broken or has become unstable. Kindly apply directly here: https://atlas.ripe.net/apply/ Regards, Lia > On 3 Oct 2022, at 13:33, Colin Johnston wrote: > > Can someone put me down for a v1 to v5 replacement please ? > My v1 at present powered by usb from bt homehub > > Thanks in advance > > Colin > > Sent from my iPod > >> On 3 Oct 2022, at 12:19, Robert Kisteleki wrote: >> > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Tagging probes which are using the ISP's DNS server?
Hi, a few days ago I wanted to debug a name resolution problem of one of our domains. For this reason, I wanted to test if probes inside a specific ASN are having difficulties to resolve a specific name (because only customers of this ISP were complaining). This lead to very mixed results, mostly because some of the selected probes did queries to a public DNS service like Google, Quad9 and so on. The problem existed only with the provider's DNS servers for some reason. It did take some time to make a script which tried to filter out these probes, so I wondered if anyone else had the same use-case and problem. Is there a way to automatically tag probes, which are (seemingly) using the ISP's own DNS servers, or, at least, not a well-known public service? This could be done maybe by querying a special DNS name which returns the IP address from where the query was received (like "whoami.akamai.net"). By comparing the ASN of the probe and the ASN of the IP address returned by the DNS query, one could determine, if the ISP's servers are used. This would also be true for people running their own recursor, but this could be filtered as well very easy. If an ISP is using multiple ASN, this could be a problem. Maybe there's an easy solution for this as well. Probes which pass this test, could then be tagged with "DNS-using-ISP-server" or something like that and explicitly be selected for specific DNS resolution tests. Greetings, Max -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] RIPE Atlas SMTP Measurement
Hi Simon, Thanks for the rundown, that helps. The Atlas measurement code uses something different than nc, but that isn’t really relevant, the process is roughly the same. I have a question, though. Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes? Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process? As to the TCP traceroute, this is something used by people to measure service availability using Atlas. It isn’t something I came up with perse, but yes its to measure response time as well as availability of the service at the TCP level. With regard to additional check such as DANE, these lie somewhere between DNSSEC and TLS measurement. I’ll make a note of this, thanks for the suggestion. As to measurements in general, all currently support IPv6 to my knowledge. I agree that new ones should support this too. Regards, Michel > On 1 Oct 2022, at 17:11, ripe@toppas.net wrote: > > Hi Michel, > >> That would would indeed mean a combination of TCP and SSL measurement to >> achieve all 3 required functions. Is it problematic if the result comes from >> multiple steps? If so, can you explain how? >> The intent of the measurement would be to validate whether an SMTP server is: >> reachable >> responsive >> capable of secured transmissions > > First, let's define the testmethod. In my opinion: > > - reachable > 3-way TCP Handshake with target on tcp/25 successful? > > - responsive > when establishing and SMTP connection, does the smtp-server signalize > readiness of the service (SMTP 220)? > > - capable of secured transmissions > when sending an EHLO, the server will tell us his features. 250-STARTTLS > should be there. > > > For all three checks, it's the easiest to use netcat. > > Reachability: >> $ nc -vz mahimahi.ripe.net 25 >> mahimahi.ripe.net [193.0.19.114] 25 (smtp) open > > Note, that we have not measured the response time. That's why you wanted to > use TCP Traceroute, right? We can also go with TCP Traceroute here. > > > Responsiveness (wait for 220): >> $ nc -C mahimahi.ripe.net 25 >> 220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:25:22 +0200 >> quit >> 221 mahimahi.ripe.net closing connection > > You might want to use the -w option here, to specify a timeout. > > > capable of secured transmissions (send EHLO and check response): >> $ nc -C mahimahi.ripe.net 25 >> 220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:54:04 +0200 >> EHLO p123456.probes.atlas.ripe.net >> 250-mahimahi.ripe.net Hello p123456.probes.atlas.ripe.net [123.123.123.123] >> 250-SIZE 52428800 >> 250-8BITMIME >> 250-ETRN >> 250-PIPELINING >> 250-PIPE_CONNECT >> 250-STARTTLS >> 250 HELP > > > To check the Certificate validity and if encryption is indeed successful, we > can use OpenSSL: >> $ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 > (output to long, i stripped it) > > > >> You’re correct, the current SSL measurement does not support any form of >> STARTTLS, this is something that would have to be considered for >> implementation. I assume, much like with SMTP, similar cases could be made >> for IMAP4/POP3 or XMPP. > Yeah, as far as i know, STARTTLS is also used for imap, pop3, xmpp and ftp > (ftps, not sftp). > > > As i said before, there are additional e-mail security features that we could > check. There's MTA-STS, where we would have to perform a combination of HTTP > and SSL check. Also, there is DANE, where we would perform a combination of > DNS and SSL check (including DNSSEC). But DANE can be used for other > protocols as well, not only SMTP. DNSSEC/DANE are perhaps worth a separate > check type. > > Last but no least, we should check for Forward-confirmed reverse DNS and > matching SMTP banner, which is a combination of DNS and netcat check. This > would be a reasonable part of every smtp measurement. > > > Please note, that the creator of the measurement should either specify the > exact mailserver FQDN, or the target Domain. In the latter case, an MX record > lookup has to be performed before the measurement starts, not while the > measurement is running. Otherwise it could cause credit consumption trouble, > if suddenly multiple mx records are added the domain, while the measurement > is running. > > Oh, and please make the SMTP measurement IPv6 capable :) > > > BR, > Simon > > > > On 29.09.22 11:50, Michel Stam wrote: >> Hi Simon, >> >>> >Can we achieve the first 2 items of this measurement by doing a TCP >>> >traceroute on port 25? >>> I would say no. Using TCP Traceroute, you can may check for >>> reachability/responsiveness of the host, but not the actual service (smtp). >> >> That would wo
Re: [atlas] API error
L.S. If for some reason this api error bug takes longer to resolve and the data is important for you, a work around is to download this data from ripestat. Click on the link on your builtins page for the larger graph and click the download button top right. Use this download link to download future data by changing the start and end time in the URL. Reason I use the data from the first hop latency is that my CentOS probe in a VMware Player VM on Windows 10 (bridged) takes 2-3 ms. for the first hop. To get more realistic data for other measurements I subtract this first hop latency data from data of other measurements. Wrote some Freebasic code for this and created my own graphs using the good, old, trusted application ploticus. >From the host Windows 10 PC first hop is max 0.5 ms. so the VMware software >bridge is not very efficient to get a connection going. If the CentOS VM is >kept busy, the first hop is much faster. It is as if Windows and/or VMware >suspends/sleeps the thread of the bridge when not active. I searched but did >not find any more reports let alone solutions for this weird first hop >phenomenon in VMware/Windows environments. Regards, Ernst J. Oud -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] API error
Hi Dimeji, The fix for this issue is currently being tested, I will update the list when it's ready. There is no workaround for the issue, but you can expect it to be resolved this week. Regards, Chris On 05/10/2022 06:32, Dimeji Fayomi via ripe-atlas wrote: Hi, I have also been experiencing this authorization error when I attempt to download first and second hop ping data of public probes. I'd please appreciate any tips or pointers to dealing with this. Thanks Dimeji -- Dimeji Fayomi -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
