[HN Gopher] Show HN: How did your computer reach my server?
___________________________________________________________________
Show HN: How did your computer reach my server?
Author : archmaster
Score : 412 points
Date : 2023-12-05 14:56 UTC (8 hours ago)
(HTM) web link (how-did-i-get-here.net)
(TXT) w3m dump (how-did-i-get-here.net)
| archmaster wrote:
| Hi! I'm Lexi. I'm 17, and one of the things I'm interested in
| right now is gaining a deeper understanding of how computers work
| and showing that in new ways.
|
| A few months ago I published https://cpu.land (discussion:
| https://news.ycombinator.com/item?id=37062422). After cpu.land, I
| felt a lot of pressure to make another Big Giant Thing but didn't
| really have anything compelling. So I just hacked away on
| personal projects and, through some coincidental learning on how
| the Internet works, ended up hacking together a traceroute
| program that could live stream to a website from scratch!
|
| I realized I had never seen this sort of thing on the web before,
| and it was actually a kind of cool and novel way of visualizing
| the structure of the Internet, so I polished it up and built a
| pretty site around it. In the process, I learned some really
| interesting things about how BGP and the structure of The
| Internet, so I melted the traceroute tool with an article sharing
| that knowledge.
|
| I'm still hacking on this and I'm sure my code will manage to
| break somehow, so please let me know if you have any suggestions!
| :)
|
| (Side note: why Rust? I don't think programming language choice
| matters that much, but I wanted to quickly write a very
| dependable low-level program, and I really like Rust's error
| handling primitives. Why do you care about this?)
| Multicomp wrote:
| Good work, a nice site explaining the traceroute is very handy!
| I could see myself using this to explain what traceroute is for
| various technicians I'm training to maintain corporate
| networks.
|
| (Now if only I could figure out how to enable traceroute to
| work on each hop from a given workstation through corporate
| cisco access switch, core switch, BGP tunnel to aws transit
| gateways, and eventually land at the VPC route table on the EC2
| instance, then i might actually be able to call myself a
| network guy)
| bongodongobob wrote:
| You can't use traceroute for switching as it operates on
| layer 3. Switches use MAC addresses, not IP. Switches are
| essentially transparent as they just forward traffic, they
| don't route.
| epistasis wrote:
| The switch and router terminology distinction has become
| fairly meaningless at enterprise level hardware as
| discussed in that comment. The same corporate access or
| top-of-rack "switch" is just as capable of layer 3 routing
| as it of layer 2 network handling. This happened because
| the desire to expand a layer 2 fabric across multiple
| physical switches basically reinvented a lot of layer 3
| concepts on layer 2. The silicon is the same for both, just
| different algorithms.
| dfox wrote:
| There are multiple motivations and resulting technologies
| there:
|
| - "L3 Switches", which in essence are routers that do not
| have discrete ports and instead have closely coupled
| switch. Alternatively the same thing can be viewed as
| switch with powerful enough control-plane CPU that it can
| do routing (pure L2 managed switches usually have
| ridiculously underpowered CPUs). This can be and often is
| combined with some amount of offloading the routing and
| even more complex upper-layer processing into hardware.
|
| - things like Shortest Path Bridging, which uses L3-style
| routing protocol (IIRC it is IS-IS) in order to build L2
| FIB tables for L2 switches. The idea there is to not only
| have (R)STP-like redundant paths for ethernet, but to use
| full capacity of such paths when it is available.
|
| On the hardware level it is mostly about accelerating the
| fast-path, where the hardware FIB contains some cache of
| bit patterns seen in the received frame, where it should
| be forwarded and maybe how it should be rewritten. And
| packets that are not matched by HW FIB are passed to the
| CPU to be processed. In a "dumb" bridge (ie. L2 switch),
| such frames would be simply broadcasted to all ports.
|
| While the general idea is the same, there is material
| difference in the silicon complexity between matching
| destination MAC of ethernet frame and matching arbitrary
| bit patterns somewhere in TCP header of IPv6 packet.
| ta988 wrote:
| I found about "Lying for Money" on your website a few months
| ago when you posted your CPU thing. Thanks that was totally
| worth a read. I recommend you "When Mckinsey comes to town"
| (the book) in a similar vein, that was entertaining in human
| mischief as well.
| ReactiveJelly wrote:
| Cool! I was nervous it was gonna show my Tor circuit o_o
|
| Unfortunately so many nodes ignore traceroute packets that it
| basically said my exit node connected to Linode and then Linode
| connected to your computer. I have the same experience with
| forward traceroutes, my router replies, my server replies, and
| if I'm lucky, one node in my ISP's network. The rest is locked
| up tight.
| archmaster wrote:
| (Part of this might be that all this HN traffic is
| overwhelming my tiny server a bit, I'm working on getting it
| smoother live rn)
| mring33621 wrote:
| Would love an update for what you had to do to make it
| "smoother" under the HN load!
| dfox wrote:
| Tor works on the level of circuits and from the inside of the
| circuit has nothing to do with IP. The exit node is the first
| node where that is converted to an actual TCP connection.
| This among other things means that the only protocol on the
| public internet that works over Tor is TCP.
| solardev wrote:
| Hey Lexi,
|
| Total side note, your other post (about cpu.land) is at exactly
| 1337 upvotes now :D https://share.cleanshot.com/ktVWL2pr
|
| How fitting.
| archmaster wrote:
| I KNOW, right?! It's perfect.
| RSMDZ wrote:
| You are working on a lot more cool things than I was when I was
| 17. Rock on! If you enjoyed "I, Robot" I recommend Ted Chiang's
| "Stories of Your Life and Others". The movie Arrival was based
| of one of the short stories in this collection.
| archmaster wrote:
| Oh, thank you, I'll buy a copy! I thought Arrival was a fun
| movie
| solardev wrote:
| Seconding that... Ted Chiang is one of my favorite authors!
| His short stories are a really fun mix of
| technology/sociology/religion/history, and each one only
| takes like half an hour to read.
| forgotpwd16 wrote:
| Both submitted and previous are cool and very well made.
| Grants!
| animal_spirits wrote:
| Keep up the awesome work, Lexi. You are very skilled and I can
| tell that you will rise very quickly as an engineer and a
| teacher
| sonicanatidae wrote:
| Most of the really cool things on the interwebs started just
| like this.
|
| Kudos and carry on!
| farmeroy wrote:
| Your projects are super inspiring!
| zerojames wrote:
| This is incredible, Lexi. I have had a lot of fun learning
| about the low levels of networking; there are so many
| interesting details. Documenting those -- and making them so
| intuitive, like you do here -- is amazing.
|
| Keep up the amazing work!
| DylanSp wrote:
| Cool project! Two suggestions, one serious, one frivolous:
|
| - I wonder if you could get more accurate results by using TCP
| or UDP instead of ICMP. I think traditional traceroute has an
| option to use UDP, mtr [1] can use TCP or UDP, and
| tcptraceroute [2] can use TCP.
|
| - This would be a _perfect_ fit for some Talking Heads
| references. "And you may ask yourself, well, how did I get
| here?" [3]
|
| [1] https://github.com/traviscross/mtr
|
| [2] https://linux.die.net/man/1/tcptraceroute
|
| [3]
| https://en.wikipedia.org/wiki/Once_in_a_Lifetime_(Talking_He...
| archmaster wrote:
| 1. ICMP seemed a lot faster / more reliable, but you're right
| that UDP does sometimes bring out better results. Something I
| want to do is make it use a hybrid approach -- sending both
| ICMP _and_ UDP packets and using the best of both.
|
| 2. Wayy ahead of you, check for HTML comments :))
| nullindividual wrote:
| ICMP isn't as reliable for trace routes. ICMP typically
| flows through the management plane instead of the data
| plane. The management plane is often driven by low-power
| MIPS processors, which can appear as additional latency in
| the traceroute results.
|
| When a network device is busy, ICMP may be dropped
| entirely.
|
| ICMP is a great tool to establish baseline connectivity,
| assuming the device responds to it. TCP will provide more
| accurate results (or UDP given the device responds to UDP
| packets) if you know a specific port is open.
|
| traceroute uses UDP by default. tracert.exe only uses ICMP.
| archmaster wrote:
| "Reliable" may have been crufty wording but I did get
| more responsive results using it. MTR uses ICMP by
| default. Definitely want to do a hybrid thing in the
| future though!
| globular-toast wrote:
| Interesting, I didn't know traceroute used UDP by
| default. Just did some testing with the best traceroute
| tool, mtr[0], and using the -u flag for UDP seemed to
| give the worst results. -t for TCP seemed OK. I never
| thought about the difference between how TCP and ICMP
| packets are handled.
|
| [0] https://bitwizard.nl/mtr/
| nullindividual wrote:
| Yep! UDP/3343 by default.
|
| You can use the -P flag to set the protocol (TCP, UDP,
| ICMP Other, GRE) and -p to set the port number, if
| applicable.
|
| Microsoft should have stuck to the BSD traceroute. I
| don't know why they "invented" tracert.exe (which I
| believe is _based_ on BSD traceroute, like most of those
| early network tools in Windows). I wonder if this was a
| Winsock (or STREAMS[0]!) limitation.
|
| [0] https://web.archive.org/web/20151229084950/http://www
| .kuro5h...
| dfox wrote:
| I assume that tracert using ICMP is not that much an
| WinSock limitation but limitation of the underlying NT
| security architecture without suid binaries, which was
| worked around with ICMP-only non-privileged "raw
| sockets". But that is mostly an educated guess.
| nullindividual wrote:
| This is a limitation that dates back to NT 3.1 where
| SOCK_RAW was callable by standard User accounts. Only
| starting with Windows 2000 [0] does creating a RAW socket
| require local administrator rights.
|
| [0] https://learn.microsoft.com/en-
| us/windows/win32/winsock/tcp-...
| inowland wrote:
| While ICMP isn't as reliable, I think the reasons are a
| little different. Its not that ICMP gets punted to the
| management plane in general - i.e. when you "ICMP echo
| request" ping a host, that packet doesn't go through the
| management plane of all the network devices in between.
| You know that as ping doesn't have the latency/loss
| problems traceroute does.
|
| Rather what is going on is most network device data
| planes are going to punt _all_ IP packet's "time-to-live
| exceeded" case to the management plane, and so it will
| have the problems you describe (latency, throttling).
|
| So why is ICMP still worse? First of all it misses having
| the UDP/TCP "port" information that allows it to be flow
| hashed through different routes. Secondly if the route
| hits any firewalls, they often have very different
| configuration for ICMP then they do for the TCP/UDP that
| they are configured to let through.
| nullindividual wrote:
| This is sourced from https://archive.nanog.org/sites/defa
| ult/files/traceroute-201..., Page 32-36. Feel free to
| disagree with the presentation, but it would be nice if
| you could offer a source rather than "I think".
| inowland wrote:
| Thats a nice reference, but those slides agree with me.
| He is explicitly talking about "ICMP Generation" getting
| punted, exactly as I am.
| marcus0x62 wrote:
| You misunderstand how TTL errors are signaled.
|
| In IPv4, ICMP is used to send TTL exceeded messages
| regardless of what upper level protocol was used in the
| packet that expired in transit. UDP, TCP, ICMP, doesn't
| matter.
|
| The slides you linked to are correct, in general, about
| router slow path behavior, but that isn't what makes UDP
| ping "more reliable". It's "more reliable",
| theoretically, because UDP is less likely to be subject
| to indiscriminate filtering than ICMP.
|
| Additionally, generally only ICMP sent to or generated
| from a router goes through the slow path. An IP packet
| being sent through a router generally goes through that
| device's fast path, regardless of the payload type.
| Hikikomori wrote:
| We're not disagreeing with the presentation, you're
| misunderstanding it.
|
| No matter which protocol you use the packet only has one
| destination, the destination IP, so it does not go
| through the slow path on any hop on the way just because
| its ICMP. When a packet hits the TTL limit on a hop it
| will go through the slow path as the CPU will generate
| the response ICMP. The protocol used for traceroute makes
| no difference here.
| DylanSp wrote:
| <!-- This is not my beautiful house. --> <!-- This is
| not my beautiful wife. -->
|
| The kids are all right. :)
| dylan604 wrote:
| Every now and then, I am less afraid for them with
| examples like this. However, they do seem to be getting
| more rare
| js2 wrote:
| > I realized I had never seen this sort of thing on the web
| before.
|
| Search for: "looking glass bgp" and you'll find some[1]. One of
| the first CGI programs I wrote nearly three decades ago
| (ugh...) was a Perl script that wrapped traceroute and streamed
| the results via server push[2]. Everything old is new again.
| :-)
|
| That said, your site has a very nice presentation.
|
| BTW, ipv4 TTL is dejure seconds even though it's defacto hop
| count since no router takes more than a second and the minimum
| decrement is 1 (except middleboxes which wish to remain hidden
| won't decrement at all). Also, Linux/Unix traceroute by default
| use UDP to a high numbered (and usually closed) port for probe
| packets instead since UDP historically is less likely to be
| dropped/filtered than ICMP.
|
| Aside: asking how traceroute works is one of my interview
| questions, most people don't know (if they do the question is
| no good) and many are unable to figure it out from first
| principles no matter how many questions I answer about TCP/IP.
| I still think being able to figure it out is a reasonable
| problem solving question.
|
| 1. e.g. https://www.bgplookingglass.com/
|
| 2. https://www.oreilly.com/openbook/cgi/ch06_06.html
| archmaster wrote:
| BGP looking glasses are very fun, although a bit of a
| different concept.
|
| And WOAH, that's really interesting about TTLs. Thanks for
| sharing! That's awesome and terrifying!
| js2 wrote:
| The looking glass sites often include a traceroute tool
| too, but "looking glass traceroute" may return better
| results. Unfortunately most of them have bitrotted. :-(
| 0x0000000 wrote:
| > Aside: asking how traceroute works is one of my interview
| questions, most people don't know...
|
| Curious what type of roles you interview for, are they
| networking-centric? Iirc this is CCNA-level material, I'd
| expect anyone working in networking to be able to describe
| how traceroute works. I've used it more as a smoke test
| question than a question that most people don't know.
| js2 wrote:
| Unix sys admin, build & release, developer tooling,
| operations.
|
| We use the Internet every day. I like folks to have an idea
| how it works, to be intellectually curious, and to be
| generally informed about the technology they use.
|
| The traceroute man page explains how it works.
|
| FWIW, my CS degree included a networking class.
| Hikikomori wrote:
| Describing how it works and using it to troubleshoot real
| problems and drawing the correct conclusions are very
| different things. If you believe it is simple then you have
| a shallow understanding of traceroute, which is why it's a
| good interview question as you can go really deep on your
| answer.
|
| Even seasoned network engineers get it wrong.
|
| https://youtu.be/WL0ZTcfSvB4?si=dtihJG1pGJwiyj1u
| 0x0000000 wrote:
| Your linked 1+ hour video includes things like IATA
| airport codes for geolocation and such. None of that is
| relevant to the fact that all traceroute implementations
| make use of very basic networking fundamentals: in
| particular, by sending out a series of packets with
| artificially limited TTL, to [hopefully] receive ICMP
| type 11 code 0 "TTL expired" packets from the hops along
| the path to your target.
|
| Traceroute _is_ simple. Sure, there 's lots you can do to
| enrich the data you receive (e.g, reverse DNS and
| geolocation), or sending multiple sequences to identify
| equal cost multipath. But these are not inherent or
| necessary to perform a traceroute.
|
| And understanding why different protocols exhibit
| different behavior / observe different metrics, or why
| some nodes don't send ICMP TTL expired, is important. But
| that's more in line with what you call "using it to
| troubleshoot", which is not "how it works."
|
| But "how traceroute works" is simple: First you send a
| packet with TTL=1, then you send a packet with TTL=2, and
| so on. That's it, that's how it works.
| deathanatos wrote:
| > _ipv4 TTL is dejure seconds_
|
| Huh. TIL. But how would a router know how long a packet took
| to traverse the hop? The packet doesn't have the information
| to figure that out ... were they expecting people to
| configure routers to know how far away the previous hop was?
|
| Also >1 second is most of the way to moon. (Yes, yes, speed
| in a non-vacuum is blah blah and switches blah buffers
| blah...)
| js2 wrote:
| Here's what Jon Postel wrote in IEN 41[1] in June 1978:
|
| > The time to live is set by the sender to the maximum time
| the segment is allowed to be in the internetwork system. If
| the segment is in the internetwork system longer than that
| the segment should be destroyed. This field should be
| decreased at each point that the internet header [is]
| processed to reflect the time spent processing the segment.
| Even if no local information is available on the time
| actually spent, the field should be decremented. The time
| is measured in units of seconds (i.e. the value 1 means one
| second). Thus the maximum time to live is 255 seconds or
| 4.25 minutes.
|
| A router would have to track of when each packet enters and
| leaves and then round to the nearest number of seconds.
|
| [1]: https://www.rfc-editor.org/ien/ien41.pdf
| hiAndrewQuinn wrote:
| > Also, Linux/Unix traceroute by default use UDP to a high
| numbered (and usually closed) port for probe packets instead
| since UDP historically is less likely to be dropped/filtered
| than ICMP.
|
| thanks! ive been wondering about this for ages!
| gumby wrote:
| > many are unable to figure it out from first principles no
| matter how many questions I answer about TCP/IP
|
| TBF it's neither TCP nor IP, but ICMP :-)
|
| Edit: I meant to write "neither TCP nor UDP" -- but even
| though I could make the correction I'll leave my error in
| place.
| js2 wrote:
| It's IP and ICMP and possibly UDP, which are all part of
| TCP/IP, aka the Internet protocol suite.
| geraldcombs wrote:
| The traceroute that ships with macOS supports ICMP, UDP,
| TCP, and GRE. As I recall, the one(s) available on most
| Linux distributions do as well.
| foobarian wrote:
| Since you're in the weeds with traceroute you might appreciate
| this one (if you haven't seen it already):
|
| traceroute bad.horse
| archmaster wrote:
| +1, love it
| herodotus wrote:
| Is there music that goes along with these lyrics?
| archmaster wrote:
| https://www.youtube.com/watch?v=F7GDaLijr1w
| aidenn0 wrote:
| if you don't have traceroute: tracepath
| -m128 bad.horse
|
| works just as well.
| mgkimsal wrote:
| Great job!
|
| I was reminded of working at a company in 1996... we had
| windows 95(!) with Trumpet WinSock and a dial-up modem (24k,
| IIRC). I was just learning how all this stuff worked and fit
| together. I stumbled on a traceroute screen that would slowly
| drip out each hop and... it was _magical_ to me. Suddenly
| realizing the idea of 'a big global network' I'd read about
| was actually... right at my fingertips, and I could _see_ which
| computers my traffic was being routed through... that kept me
| up at night for a while. Not sure I 'll say it was life-
| changing, but it sort of felt like it for a bit at that time :)
| globular-toast wrote:
| Nice. I'm wearing black jeans and I'm always surprised by how
| little developers know about basic networking. I was always
| interested in it but also learnt about it at uni. I don't
| remember all the details, of course, but just generally knowing
| what routing is, what IP is etc. pays dividends when building
| anything that runs on networks/internet.
| lanewinfield wrote:
| Nice work, Lexi. Let me add that your design skills are pretty
| excellent as well.
| readyplayeremma wrote:
| Really awesome project!
|
| A technical nitpick though: Routes can be asymmetric--going
| across one path in one direction and another for the opposite.
| This means that your tool potentially doesn't show the route
| packets from the user took to reach your server, but rather the
| route packets took from your server to reach the user. I
| believe that querying with BGP looking glass tools would allow
| you to construct the route in either direction, but it is maybe
| a bit less cool looking than the real-time traceroute that is a
| result of actual traffic.
| monkeyjoe wrote:
| On my device, there are no intermediate steps shown between my
| device and the server. Just FYI.
| archmaster wrote:
| Yeah, sorry, Hacker News has successfully made my server chug a
| lot :)
|
| I'm working on it right now and hopefully will be working
| better soon! In the meantime I've increased timeouts so loading
| will be longer but it should work better.
| macksd wrote:
| Same here! But I'm gonna bookmark this and try it another
| day. Kudos for sharing this - love to see younger folks
| hacking. This is a cool idea.
| archmaster wrote:
| Should work a little better now! It's still chugging, but I
| made the rest of the article load (although now it's a bit
| janky when you have JS disabled, but not much I can do)
| noort wrote:
| Doesn't work at all with Enhanced Tracking Protection enabled in
| Firefox, and times out when it is disabled.
|
| I guess it's supposed to do something like this:
| https://dnschecker.org/online-traceroute.php
| archmaster wrote:
| Shouldn't have anything to do with Enhanced Tracking
| Protection, but my server is buckling under the traffic
| pressure! I'm working on it, maybe check back in 40m or so
| (SORRY!)
| Rastonbury wrote:
| Do you have a VPN on as well? It works for me on FF mobile with
| Enhanced protection
| ibejoeb wrote:
| Here's some earlier work on reverse traceroute:
|
| https://research.cs.washington.edu/networking/astronomy/reve...
|
| paper:
| http://www.cs.washington.edu/homes/ethan/papers/reverse_trac...
|
| video: http://www.usenix.org/multimedia/nsdi10katz-bassett
| c0pium wrote:
| You might be interested to know that many times, packets in a TCP
| session take asymmetric routes across the internet. In my
| experience, the most common reasons for this are business rules
| related to cost and human error.
|
| If you think about how IP works, you'll see that this doesn't
| particularly matter but that it can make understanding the
| routing more difficult.
| supermatt wrote:
| This is "how your server reaches my computer but reversed" rather
| than "how my computer reaches your server". The routing in each
| direction will most likely be very different.
| archmaster wrote:
| Yeah, there is actually a whole section about this in the
| article! Called "Front to Back, Back to Front".
|
| tl;dr in my experience the networks traversed are usually very
| similar, and the content is relevant and interesting either way
| around
| Mountain_Skies wrote:
| Back in the days of bang paths, it was interesting to see how
| different a sender's bang path might be to the bang path for
| your reply and try to figure out what network connection
| differences caused the asymmetry.
| nullindividual wrote:
| Here's a paper you might be interested in with regards to how
| traceroute works. One thing that many (non-network) folks miss is
| that traceroute is not necessarily symmetrical -- the return path
| may differ.
|
| https://archive.nanog.org/sites/default/files/traceroute-201...
| archmaster wrote:
| TY, will read! I touched on this duality in the article
| actually :)
| justsomehnguy wrote:
| It's extremely rare but the data paths can be asymmetrical too.
| Eg satellite with a ground based uplink.
| ta1243 wrote:
| Due to internet problems in Egypt earlier today with Telecom
| Egypt, I had a traceroute to the same destination going via _8_
| different paths. Have to say that's twice the higher number of
| ECMPs I've seen on the internet in the past.
|
| And yes, traffic is routing different ways from my Cairo office
| to my UK core --London ->Cairo is direct and still suffering
| massive loss, Cairo->London is now routing via ntt and seems
| fine. If they haven't fixed it by tomorrow might have to change
| some local prefs.
| Hasz wrote:
| I think it's also worth mentioning mtr, which is what I use much
| more frequently than traceroute. It can help diagnose
| intermittent packet loss, and gives you an averaged sense of how
| things flow.
|
| This article from APNIC explains more about mtr and how to read
| it (plus some interesting details about how MPLS can obscure true
| paths)
|
| https://blog.apnic.net/2022/03/28/how-to-properly-interpret-....
|
| Also worth noting: It's also sometimes useful to trace with UDP,
| and many routers will drop ICMP selectively under strain.
|
| Nice article, and excellent presentation!
| magnat wrote:
| You can go one step further and instead of separate ICMP ECHO
| trace, use existing HTTP TCP connection between client's browser
| and your web server. That way you can traverse client-side NAT
| and/or stateful firewall.
| archmaster wrote:
| Ooh, that's compelling. I wonder how that would work for an
| actual traceroute.
| ryan-c wrote:
| called a "parasitic traceroute"
| mikewarot wrote:
| SQUIRREL!!!
|
| How did you manage to tilt the section header text? I've not seen
| that done before.
| archmaster wrote:
| CSS transforms! transform: rotate(-2deg)
| skew(-2deg); transform-origin: bottom left;
| kazinator wrote:
| There should be a traceroute protocol whereby a "specially marked
| packet" is understood to be traceroute, and generates an ICMP
| response even though its TTL is still positive. The ICMP response
| will carry the observed TTL value.
|
| Then one packet will get all the echoes in one go instead of
| having to send a tirade of packets with increasing TTL values.
| plingbang wrote:
| Combined with IP source address spoofing, it would probably
| help greatly with DDoS amplification attacks while only saving
| up <50% packets for good users.
|
| If you care about time rather than packet count, you can send
| packets with all reasonable TTL values at once.
| kazinator wrote:
| Oh no question; the amplification is concerning. Send one
| packet, get 19 responses, versus having to send 19 packets to
| get 19 responses: it's a "gain" of 19 to 1.
| ta1243 wrote:
| Have enough problems with routers not sending normal ttl
| expired messages
|
| Just use a better client. Takes about 3 seconds to do an mtr -b
| over 15 responding hops from a server in London to something
| like 43.249.179.0 in the south pacific.
| netfortius wrote:
| NANOG relevant talk (PDF):
| https://archive.nanog.org/sites/default/files/10_Roisman_Tra...
| Kinrany wrote:
| Do the h3 heading tags look like they're tilted a little bit?
| CSS/font trickery? Just me?
| WaffleIronMaker wrote:
| Yes, they are tilted: .text h3 {
| margin-top: 60px; margin-bottom: -4px;
| transform: rotate(-2deg) skew(-2deg); transform-
| origin: bottom left; }
| denton-scratch wrote:
| > WHOIS is actually an... interesting protocol to make a parser
| for.
|
| It's actually impossible. Responses are essentially free-form (if
| the server responds at all). I tried my hand at this; you can
| make an ad-hoc "parser" that works for 90% of addresses/domains
| (or you could, ten years ago when I tried). But the remainder are
| intractable.
|
| Nowadays it's much worse; nearly everything is hidden behind
| privacy shields, which purport to protect PII. But WHOIS records
| aren't supposed to contain personal information; they're supposed
| to contain contact information for network operators.
|
| This is ICANN's doing, I'm afraid. ICANN had a rule that networks
| should provide public WHOIS servers. They never enforced the
| rule, and now they've scrapped it.
| deathanatos wrote:
| RDAP contains some of the WHOIS information in a machine-
| readable format. (JSON) Not everything, but I think it's
| better.
|
| Not everything runs an RDAP server, though; I do wish
| ICANN/IANA or whoever would enforce that.
|
| > _Nowadays it 's much worse; nearly everything is hidden
| behind privacy shields, which purport to protect PII. But WHOIS
| records aren't supposed to contain personal information;
| they're supposed to contain contact information for network
| operators._
|
| Network operator info can also be PII. My info is PII, but I
| have a domain name, so putting my info into WHOIS is putting
| PII into WHOIS.
|
| The privacy guard just forwards everything to me, minus spam.
|
| (If it's a corporation, I don't think there's a good reason to
| permit privacy guards. But not all domains are owned by BigCos,
| yet.)
| squeaky-clean wrote:
| > But WHOIS records aren't supposed to contain personal
| information; they're supposed to contain contact information
| for network operators.
|
| Doesn't a whois have to include email, phone number and
| physical address? For a company that's not really PII, but I
| don't understand how it wouldn't be considered personal
| information in the whois for my personal website.
| quantum5 wrote:
| > BGP is the protocol that gives the Internet its shape, and you
| can't directly speak it yourself.
|
| It's actually surprisingly easy to get an ASN for yourself and
| speak BGP. If you find building something like this tool
| interesting, you should give it a try. I wrote an introduction of
| sorts earlier (https://qt.ax/asn) if that interests you.
| at0mic22 wrote:
| As it was mentioned above, you are not measuring connection from
| the client to the server, but from the server to the client. It
| can be a completely different route, and internal routing behind
| the IP is hidden. You should try 0trace to get the real route
___________________________________________________________________
(page generated 2023-12-05 23:00 UTC)