Could be useful, if only birds were real.

The RFC for NAT -- RFC 1631 -- says:

> Unfortunately, NAT reduces the number of options for providing security [1]

Somehow, everyone forgot that, and it morphed into a cargo-culting practice, even propagating 1990s network limitations into the cloud.

[1] https://www.rfc-editor.org/rfc/rfc1631.html

IDK if the different drive is necessary, but yes partitioning on a deleted field would work.

Memory >>>>> Disk in importance.

50-70% as the worst case isn't even necessarily that bad.

(Again, a lot is O(log n) right?)

100%

I just commented the same.

It's pretty clear that the "possibly" refers to the presence of the CNAME RRs, not the ordering.

The context makes it less clear, but even if we pretend that part is crystal, a comment that stops there is missing the point of the article. All CNAMEs at the start isn't enough. The order of the CNAMEs can cause problems despite perfect RFC compliance.

To me, this reads exactly the opposite.

> RFC 1034, published in 1987, defines much of the behavior of the DNS protocol, and should give us an answer on whether the order of CNAME records matters. Section 4.3.1 contains the following text:

> If recursive service is requested and available, the recursive response to a query will be one of the following:

> - The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer.

> While "possibly preface" can be interpreted as a requirement for CNAME records to appear before everything else, it does not use normative key words, such as MUST and SHOULD that modern RFCs use to express requirements. This isn’t a flaw in RFC 1034, but simply a result of its age. RFC 2119, which standardized these key words, was published in 1997, 10 years after RFC 1034.

It's pretty clear that CNAME is at the beginning.

The "possibly" does not refer to the order but rather to the presence.

If they are present, they are are first.

Some people (myself included) read that as "would ideally come first, but it is not neccessary that it comes first". The language is not clear IMHO and could be worded better.

In my native language the literal translation of possibly has a distinct preferably meaning but I feel that in English it does not.

It might be a victim of polite/ironic/sarcastic influences to language that turns innocuous words into contronyms

The possibility is "preface by one or more CNAME RRs..."

I.e. the possibly logically applies to the entire phrase, not just a part of it.

- The answer - to the query - possibly - CNAME RRs - prefaced by - one or more - that specify aliases - encountered on the way to an answer

The whole world knows this except Cloudflare who actually did know it but are now trying to pretend that they didn’t.

The comments are not the bets.

In fact, they are often opposite.

Isn’t this (part of) the point of MCP.

Possibly, but the point is that MCP is a DOA idea. An agent, like Claude code or opencode, don’t need an MCP. it’s nonsensical to expect or need an MCP before someone can call you.

There is no `git` MCP either . Opencode is fully capable of running `git add .` or `aws ec2 terminate-instance …` or `curl -XPOST https://…`

Why do we need the MCP? The problem now is that someone can do a prompt injection to tell it to send all your ~/.was/credentials to a random endpoint. So let’s just have a dummy value there, and inject the actual value in a transparent outbound proxy that the agent doesn’t have access to.

> Opencode is fully capable of running

> Why do we need the MCP?

> The problem now

And there it is.

I understand that this is an alternative solution, and appreciate it.

The serious answer:

The value cannot be just the software. E.g. some workflow tool (Salesforce). These tools will continue to exist for awhile but any customer capable of moving off of it to a startup version, can probably make their own startup version, tailored to them.

Now, if you offer something besides the software — logistics, networks, financial instruments, regulatory compliance, physical goods, compute, etc — that has value besides the software.

But the five billionth workflow automation tool has fast diminishing value in 2026.

Somehow no one talks about the incredible plumbing.