the bigger problem is stubs don't want to evolve with the spec, which makes me sad as server author :(
-
-
The whole point of a standard protocol is that stubs don't have to evolve.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @vavrusam and
RFC 1035 has everything a stub needs. Advanced features are for inter-DNS use, not stub-to-DNS.
2 replies 0 retweets 0 likes -
Replying to @RichFelker @vavrusam and
If a static-linked ping from 1989 doesn't work with your dns, it's your dns that's broken, not the stub.
1 reply 0 retweets 0 likes -
this is wrong analogy. You're asking for improved UX and refuse to use improved version of the protocol
1 reply 0 retweets 0 likes -
The "improved" version has worse ux. 4x or worse latency.
1 reply 0 retweets 0 likes -
again no, edns has nothing to do with latency.
1 reply 0 retweets 0 likes -
Yes it does. 1. You have to query for support. 2. Fragmentation + packet loss = awful.
1 reply 0 retweets 0 likes -
1. no 2. no unless you want more than path MTU, if you stick with 1280/1452 you're good.
2 replies 0 retweets 0 likes -
1. Yes; a stub can't assume edns. There are countless isp nameservers of various brokenness.
1 reply 0 retweets 0 likes
2. I've seen links with MTU=576; this is likely why DNS chose 512 as limit.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.