kasperd

Currently testing this platform to decide whether it's the future of social networking.

Curriculum Vitae:
PhD degree from Aarhus University
Worked at Google Zürich and London
Partner at Intempus Timeregistrering - until it was acquired by Visma
Operating nat64.net/

Public Key

npub13sz9ttend6sflgm3faqk2ldwk3c4c9k5mwv5e7v0hcgr99z7334srg5h6r

NIP-05 Address

kasperd@westergaard-social.mostr.pub

Profile Code

nprofile1qqsgcpz44uekagyl5dc57st90khtgu2uzm2dhx2vlx8muypjj30gc6cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsvfmpju

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub13sz9ttend6sflgm3faqk2ldwk3c4c9k5mwv5e7v0hcgr99z7334srg5h6r

Show more details

Last Notes

2026-09-09 13:39:37 UTC

From today I will enact a zero tolerance policy towards AI crawlers. If I notice even a single request from an AI crawler in my webserver logs, I will immediately block the entire IP range from which it came.
Starting with this one:
ip route add unreachable 74.7.0.0/16

2026-08-21 21:43:08 UTC

- reply

When using CLAT it doesn’t make a difference whether MSS clamping is done by CLAT, NAT64, or both. I recommend doing it on both sides to ensure it gets done.
If the NAT64 gateways you use are outside of your control and doesn’t do MSS clamping you will get more reliability by having your CLAT do MSS clamping.
I am not sure how much ping will help troubleshooting MTU problems when protocols can be handled differently. I think to ensure you have addressed all the possible MTU problems you’d have to test TCP, UDP, and ping separately. (As far as I recall no other protocol is required to be supported by the NAT64 RFC).
For TCP you can pretty much avoid MTU problems by using MSS clamping. And for UDP there is an extension to do fragmentation on the UDP layer rather than the IP layer. This extension is intended to work better with NAT than IP fragmentation. But it’s fairly new and not widely supported.
For DNS it’s recommended to switch to TCP if the payload would exceed 1280 bytes on UDP over IPv6. I don’t know if other UDP based protocols also aim to avoid fragmentation.

2026-08-21 20:26:49 UTC

- reply

Fragmentation combined with any sort of NAT is going to be fragile. For TCP traffic my recommendation is for the NAT64 to do MSS clamping to 1220 or less.
MSS clamping is a hack, but so is NAT. And most of the downsides of MSS clamping are going to be present anyway when using NAT.
I don’t know if Tayga supports MSS clamping. If it does not then I think it should be added as it would probably be beneficial to a significant fraction of users.

2026-08-11 22:52:28 UTC

- reply

I am wondering what percentage of these vulnerabilities were reported previously and not fixed. Not all developers are equally willing to fix reported vulnerabilities.
At times I have gotten the impression that some security vulnerabilities would not be taken seriously unless somebody developed a PoC exploit. This is particular counter-productive in cases where it’s a lot more work to develop an exploit than it is to fix the original bug.
This makes me think that maybe for some code bases vulnerabilities now reported by LLM are treated with more urgency than if the same vulnerability had been reported by a person.
There are also cases where bug reports are taken seriously. A TLS downgrade attack I discovered in Django earlier this year was handled very professionally. It could be that the projects now fixing many bugs are ones which already took reports seriously.

2026-08-02 19:01:42 UTC

- reply

Microsoft does not exactly have the best track record when it comes to guarding user privacy. Take for example the 2011 incident where Microsoft was caught snooping on users’ Google searches.
The system you describe sounds like it was designed to be centralized. A much better ecosystem would be one where there is a few different payment handlers who both service providers and users can choose between. There will probably need to be a little bit of money exchanged between them in case users aren’t distributed the same way as service providers. It should be possible to get paid even if user and service provider picked different payment handlers.

2026-07-29 23:04:34 UTC

- reply

Who promises that a sandwich ordered online will arrive within 24 hours?

2026-07-25 19:38:03 UTC

- reply

It could also be somebody is clueless about networking and decided to drop ICMP packets. That can work fine until you need them, and then you break PMTU discovery and get weird timeouts.

2026-07-22 14:08:11 UTC

- reply

Around 10 years ago I filed a feature request for such an integration to be added between Google Slides and Google Hangouts (or whatever Google Meet was called at the time, I have lost track of all the names it has had throughout the years).
I don’t know if any tool had such an integration at the time. I just felt it would make life so much easier for anyone doing presentations and also be less resource consuming.

2026-07-22 13:24:31 UTC

- reply

I once had a customer demanding a screenshot showing that a certain security feature was turned on. I told the customer there is no such setting in the application because we don’t offer any way to turn this security feature off. They kept insisting.

2026-07-07 16:57:38 UTC

- reply

I do have a use case where a stronger preference for IPv6 would be relevant. I have a dual-stack host which acts as IPv4 frontend for hundreds of domains hosted on IPv6-only servers. Clients which have IPv6 access should access the IPv6-only server directly rather than through my frontend.
If the IPv6-only server is slow to respond clients may get SYN-ACK from the frontend faster than from the server. But overall response times are going to be worse because the frontend then has to wait for a connection to the server.

2026-06-27 23:37:43 UTC

- reply

I thought the compression ratio of JPEG was a global setting and not something that could be varied for different parts of the image.
Does this approach actually produce smaller files than other video compression techniques? Or is it done just to produce that effect?

2026-06-14 19:25:05 UTC

I have noticed an ongoing pattern of GRE packets with seemingly random IP addresses. The only thing they all have in common is that the inner packet is UDP and always have the same length.
Anyone have any clue what this is trying to do?
19:31:40.964329 IP 62.64.246.18 > 116.202.1.213: GREv0, length 558: IP 136.59.155.105.925 > 217.154.122.200.59874: UDP, length 512
19:34:17.567755 IP 183.220.223.3 > 116.202.1.213: GREv0, length 558: IP 168.164.81.85.42864 > 234.72.215.4.58801: UDP, length 512

2026-04-22 18:47:25 UTC

- reply

Do you really need .exe if you already have .com?

2026-04-20 15:42:36 UTC

- reply

I think OVH had servers glowing like that a few years ago for a much less pleasant reason.

2026-04-19 11:52:11 UTC

- reply

Client side failover is a necessity if you want reliability. Even when IPv4 is long gone, I predict the failover code is here to stay. The failover code may even get a little bit more sophisticated.
If we want to minimize client side complexity during the transition, then DNS64 is the way to go. Dual-stack and 464xlat both add complexity on the client side, which you can avoid when using DNS64.
I agree transition technologies should not stay forever. Had people been upgrading in due time, we would never have needed DNS64 and NAT64 in the first place.

2026-04-19 09:32:25 UTC

- reply

I assume you never operated a public NAT64 service. There are networks between the NAT64 gateway and the client which are completely outside of my control. But I can achieve high availability by running multiple NAT64 gateways in independent locations.
I have health checks of the gateways which automatically updates DNS64 accordingly. And I give clients addresses using multiple prefixes to allow for client-side failover. Client-side failover is crucial as sometimes individual clients are unable to reach specific gateways for reasons that are on networks that I don’t use myself and thus outside the visibility of my health checks.
A client with a good implementation of fallback between AAAA records works great in this scenario. 464-xlat doesn’t handle this as well.

2026-04-18 23:58:32 UTC

- reply

Yeah, ipv4only.arpa exists on authoritative DNS servers and is served essentially like a name would have been served from any other TLD. As far as I recall there is an RFC recommending that DNS recursors hard-code that particular name in order to not need depend on authoritative DNS for that name. But last I checked BIND 9 would query authoritative servers for the name.
DNS64 can work just fine without special casing ipv4only.arpa. It can just translate it like any other IPv4-only domain name, and clients can use that for discovery.
I can definitely confirm that Android supports ipv4only.arpa for NAT64 discovery by default. It might support other methods as well, and I haven’t verified which order it will try the methods on a network that supports different methods. None of the NAT64 deployments I have personally encountered used the well-known prefix. So I think falling back to the well-known prefix isn’t a great option.
As an operator of public NAT64 gateways I will say that using ipv4only.arpa for NAT64 discovery is not perfect, but all the alternatives I have seen are worse. An inherent drawback of ipv4only.arpa is that it cannot handle scenarios where different NAT64 prefixes are being used depending on IPv4 range. That part is supported when DNS64 is being used.
Another drawback is more of an implementation shortcoming. 464-xlat implementations usually don’t support use of multiple NAT64 prefixes for redundancy and will rather just pick one and stick with it. And it’s not guaranteed that a client will pick up changes of prefix in a timely fashion.
So if a NAT64 gateway goes down for maintenance it may be necessary for 464-xlat users to disconnect and reconnect in order to switch to a different prefix. Use of PREF64 is worse for that use case. Users actually have to change their router configuration in order to apply the changes. There appears to exist no standardized mechanism for a public NAT64 service to communicate prefix changes to routers of users.
In theory a router could make use of ipv4only.arpa to do NAT64 prefix discovery and communicate this downstream using PREF64. But I haven’t heard of any implementation doing this, and I don’t see any advantage of this over the client doing discovery directly using ipv4only.arpa.

2026-04-12 12:46:45 UTC

- reply

One needs to be able to judge whether the output from an AI is trustworthy or not. Anyone who cannot correctly make that judgement isn’t smart enough to be using AI.

2026-04-02 22:05:43 UTC

- reply

I see. Those are following the /64 mappings in RFC 6052. This is not exactly the purpose that RFC 6052 is intended for. And you already identified the scalability challenges of that approach.
I am guessing they use duplicate-address-detection to ensure two machines don’t pick the same address. if that guess is correct you can easily verify what happens. Just make have a machine use all of the addresses ending in c0:0:0:0 ti c0:0:700:0 before the test machine connects to the network.
If the implementation is even just a little bit sensible it will see that its preferred IPv6 addresses are already in use and pick a random IPv6 address instead. It can still use any address in the 192.0.0.0/29 range locally.

2026-04-02 18:39:14 UTC

- reply

Why would the scope of 192.0.0.2/29 expand beyond the individual host?

2025-11-06 07:46:09 UTC

- reply

Something is very messed up with the rendering of that page.
https://static.westergaard.social/pleroma/a7fbd107735b577dd9f5693593d562bc698dedb741f5bea53db935c5fbda39a4.png

2025-05-02 12:23:32 UTC

- reply

I have encountered sales people who will say whatever they think will make a customer buy the product and not care if what they say is true or not.
If they are being too enthusiastic about the product they are selling, I will automatically assume they are lying.

2025-05-01 18:30:38 UTC

- reply

What you wrote sounded slightly odd to me. So I did a bit of searching and found this article: https://www.lrqa.com/en/cyber-labs/flaw-in-putty-p-521-ecdsa-signature-generation-leaks-ssh-private-keys/
Is that the kind of problem you are referring to?
On a related note, I am actually not certain which of AES-128 and AES-256 is more secure. As far as I know there are certain theoretical attacks on the AES-256 key schedule, which could potentially make it weaker than AES-128.

2025-04-30 18:34:18 UTC

- reply

How does it deal with the increased memory usage from doing breadth-first?

2025-04-19 10:59:42 UTC

- reply

I am curious about the disclosure timeline. I can see that SSL.com have disabled the buggy validation method, so exploitation should not be possible now.
But was this bugzilla issue visible to the public before the CA had been notified about the issue?

2025-04-18 10:25:01 UTC

- reply

The only one of those I know how to read is iptables. And if what you are specifying is your complete firewall configuration, it would definitely not work.
There are a number of packets being dropped, which you would still need in order for things to work correctly:
Communication with localhost
Replies to your own outgoing connections
ICMP messages related to the allowed connections

2025-01-14 10:03:08 UTC

- reply

When I grew up we were required to be outdoors during the breaks. I think that was completely normal in Denmark at the time. For all I know it probably still is.
Exceptions were made when the weather was bad. An announcement would be made over the intercom if we were allowed to stay indoors due to bad weather.

2024-11-26 16:24:23 UTC

- reply

But how would they know about the allergies of customers currently present as well as those who may have a reservation later on the same day? And how would they know exactly how severe those allergies are?
They have a responsibility to both groups of people, and I don't know if the law actually states how to ensure they meet those responsibilities. Simply ignoring their responsibility to one of those groups is not the right answer, regardless of which of the two groups they favor.
People have died because of restaurants not taking food allergies serious enough. It's possible that the person mentioned in the story has been told about of those risks and simply acted out of excessive caution. It's also possible they were just making up excuses.
I am guessing the journalist didn't actually know what that restaurant should have done to address the concern of allergies in this particular case. And I see it as a missed opportunity to investigate and then educate the reader.

2024-11-24 22:36:41 UTC

- reply

Some of the incidents being described sounds like simple lack of understanding while some of the other ones are completely indefensible.
The concern about allergies is a valid concern and I don't know how they are supposed to deal with that. That's something I guess a lot of people don't know either. So it would have been better if the journalist had done a little bit of research of that question such that the article could have educated the readers about that.