Max Grobecker writes:
> 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
>
Alexander Burke via ripe-atlas writes:
> Micro-USB is mechanically inferior: less reliable (easier to
> accidentally disconnect) and less robust than USB Type-C.
Maybe...
But you can do a lot better than Type-C for power connector if that's
the criteria. Even the smallest barrel connectors
Alexander Burke via ripe-atlas writes:
> I really hope that's USB-C and not Micro USB.
Why would that matter? It's not like you're going to share the cable
with other devices, or ever unplug it from the probe.
The only factor I can imagine matter to anyone would be plug-n-play
replacement of
Gert Doering writes:
> "What happens inside your network happens inside your network" (and
> the RFC explicitly permits that, of course), but we do not want to
> see it on someone else's network.
Exactly my point. My traceroute example is all in "my" network if you
include the mobile access
Gert Doering writes:
> On Fri, Sep 17, 2021 at 03:43:29PM +0200, Bjørn Mork wrote:
>> Gert Doering writes:
>> > On Fri, Sep 17, 2021 at 03:23:24PM +0200, Bjørn Mork wrote:
>> >> Using RFC1918 on links in your own network is fine. And having
>> >>
Gert Doering writes:
> On Fri, Sep 17, 2021 at 03:23:24PM +0200, Bjørn Mork wrote:
>> Using RFC1918 on links in your own network is fine. And having
>> them show up in traceroutes is a feature.
>
> s/feature/sign of sloppy network design, and a RFC1918 violation/
Sorry for b
Jeroen Massar via ripe-atlas writes:
> If one sees RFC1918 in a traceroute (especially >5 hops away, thus
> just not the client->CPE hops), it indicates that every hop in the
> middle is not filtering at least RFC1918; more likely they are thus
> just doing any kind of reverse prefix filtering
Philip Homburg writes:
> On 2021/09/15 21:59 , Bjørn Mork wrote:
>> I believe it's better to ignore the formalities here and forward those
>> packets. It's certainly harmless. At least as harmless as forwarding
>> any other ICMP error messages.
>
> In my opinion
Jeroen Massar writes:
> If you can't verify the source, which with LL you cannot as they are
> on every interface around the world, it is spoofable.
Yes.
> Do you really want to receive a fe80::/10 at your recursive DNS
> service as a request (which could be valid, locally).
If you allow
Philip Homburg writes:
> As far as I know, this a well known Juniper bug where their routers
> forward errors ICMPs without checking whether the source address is
> link local.
Thinking about this... Is there any reason except formalities why you
shouldn't forward those packets? The won't
Lia Hestina writes:
>> On 18 Aug 2020, at 10:41, Bjoern Franke wrote:
>>
>> Hi,
>>
>>> For this one, unfortunately not, but there will be more soon and depending
>>> how many people attend we have other option which is Adobe connect.
>>> As soon as a new date is known, we will share it in the
Stephane Bortzmeyer writes:
> On Sun, Sep 08, 2019 at 06:53:12PM +0200,
> Stephane Bortzmeyer wrote
> a message of 26 lines which said:
>
>> I assume that the "connect failed Invalid argument" is the fault of
>> the ISP, which advertises a wrong DNS resolver? Or is the Atlas probe
>> unable
Carsten Schiefner writes:
>> Am 03.09.2019 um 13:35 schrieb Bjørn Mork :
>>> The tricky bit, however, comes if you want to use this very certificate
>>> in a TLSA RR as well: all of a sudden the RR points to a non-existing
>>> certificate when Letsencrypt's cro
Carsten Schiefner writes:
> The tricky bit, however, comes if you want to use this very certificate
> in a TLSA RR as well: all of a sudden the RR points to a non-existing
> certificate when Letsencrypt's cron job has flipped the certificate.
>
> I haven't yet really gotten my head around it -
Randy Bush writes:
>> Which is the reason why no major browser does TLSA validation.
>
> well. there is the extra protocol turn. agl tried and backed off,
> seemingly because of that.
I hear that. And I see them pushing DNS over HTTPS at the same
time. Doesn't really compute...
They are so
Jóhann B. Guðmundsson writes:
> How on earth is having a CAA record which pin points who is allowed to
> issue certificates
No, it doesn't. It's merely a hint to CAs. It cannot prevent spoofed
certificates if any CA is compromised, or fails to validate the CAA
record for other reasons. TLS
Thomas Schäfer writes:
> Am Dienstag, 25. Juni 2019, 12:47:57 CEST schrieb Bjørn Mork:
>
>> Hmm I see at https://f-lga1.f.de.net.dtag.de/index.php?pageid=lg
>> that AS3320 seems be missing all the Bytemark IPv6 routes. Looks like
>> they don't have any connectivi
Jasper den Hertog writes:
> This feature was disabled per accident. It has been revived,
I believe there used to be a NSID column in the last results listed on
the "Probes" tab of DNS measurements too? Was this also removed by
accident? Or is my memory failing me?
Bjørn
18 matches
Mail list logo
