3 ms·

I don't like anycast because I think it requires BGP and backbone access or similar expensive stuff. DNS should have had regions in the main protocol so that pe

by bullen 5y ago

I don't like anycast because I think it requires BGP and backbone access or similar expensive stuff. DNS should have had regions in the main protocol so that people in EU don't use a DNS server in Asia f.ex. But it's too late for that now. I might use geolocation on my DNS replies, and unfortunately here is the 2nd flaw of DNS, the replies should follow the sent order, because as the protocol works now you either get round-robin redundancy or direct your users to the hopefully correct continent, you can't have both! As for my brute force workaround: I use IPs for connecting as often as I can, and the hostname is just for virtual hosting to work. So all my applications have euro., asia. and iowa. prefixes and when outside of a browser I can "hardcode" the IPs so that extra second of lookup never hits my users. Ofcourse that requires fixed IPs and open port 53 which is something every home fiber owner should ask for to distribute the internet again!

toast0 5y ago
Most recursive resolvers try to figure out which authoritative server for a domain responds fastest and use that one. If you've got enough DNS requests and enough DNS servers, it kind of works out ok without anycast. Although, I've been told that 4 authoritatives is the optimal number, which is limiting (you can do more of course, but a random internet use recalls but can't find a writeup suggesting more wasn't great in some semi-failure cases, and you can cargocult top X domains which seem to do 4 for the most part) Advanced protocols may be able to use SRV records to distribute further traffic, but web browsers can't, so kind of stuck for them.
- m3047 5y ago
  > Advanced protocols may be able to use SRV records to distribute further traffic, but web browsers can't Not for lack of trying from the DNS community, more like web browsers won't. However if you haven't already you should take note of the HTTPS and SVCB DNS record types: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/00/?include_text=1 https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...
m3047 5y ago
Personally I don't see a use case other than advertising or surveillance for a web page doing 20 DNS lookups (and that includes CNAME chains). Having said that... > extra second of lookup Hrm. Sounds like you want it to work like today's internet, with today's internet services. You're using radios, what's your traffic shaping look like UDP vs TCP? I know from experience that media devices spam the crap out of wifi (weird stuff too, like multicast MAC addresses). A common scenario is a TCP channel for control, and an accompanying UDP spew for the actual content. DNS resolution according to the standards which were promulgated in the 1980s uses UDP, unless a (UDP) reply indicates that the request should be retried with TCP: there is no use of TCP, as in there is no "and if all else fails, retry with TCP". For media, this provides a first mover advantage: whomever resolves their service and starts streaming first attenuates DNS resolution for the latecomers. I actually wrote about this on HN and wrote a demo TCP-only forwarder (which also conveniently does DoT) https://github.com/m3047/tcp_only_forwarder https://github.com/m3047/tcp_only_forwarder but nobody was very interested. Point being, if DNS resolution is failing or slow and you can't / won't do traffic shaping you might want to force DNS over TCP / TLS.
m3047 5y ago
There is MDNS for example. Also in terms of alternatives to BGP, you're still going to need to figure out routes. And / or, you going to have to detect loops. Different "anycast" nodes could use something like this to detect each other's presence. You could use the (IP) TTL to limit how many hops a packet will traverse looking for a particular server (no similar concept at the MAC level AFAIK). I hope you have fun!

by bullen 5y ago

toast0 5y ago

Most recursive resolvers try to figure out which authoritative server for a domain responds fastest and use that one. If you've got enough DNS requests and enough DNS servers, it kind of works out ok without anycast. Although, I've been told that 4 authoritatives is the optimal number, which is limiting (you can do more of course, but a random internet use recalls but can't find a writeup suggesting more wasn't great in some semi-failure cases, and you can cargocult top X domains which seem to do 4 for the most part) Advanced protocols may be able to use SRV records to distribute further traffic, but web browsers can't, so kind of stuck for them.

m3047 5y ago
> Advanced protocols may be able to use SRV records to distribute further traffic, but web browsers can't Not for lack of trying from the DNS community, more like web browsers won't. However if you haven't already you should take note of the HTTPS and SVCB DNS record types: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/00/?include_text=1 https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...

m3047 5y ago

Personally I don't see a use case other than advertising or surveillance for a web page doing 20 DNS lookups (and that includes CNAME chains). Having said that... > extra second of lookup Hrm. Sounds like you want it to work like today's internet, with today's internet services. You're using radios, what's your traffic shaping look like UDP vs TCP? I know from experience that media devices spam the crap out of wifi (weird stuff too, like multicast MAC addresses). A common scenario is a TCP channel for control, and an accompanying UDP spew for the actual content. DNS resolution according to the standards which were promulgated in the 1980s uses UDP, unless a (UDP) reply indicates that the request should be retried with TCP: there is no use of TCP, as in there is no "and if all else fails, retry with TCP". For media, this provides a first mover advantage: whomever resolves their service and starts streaming first attenuates DNS resolution for the latecomers. I actually wrote about this on HN and wrote a demo TCP-only forwarder (which also conveniently does DoT) https://github.com/m3047/tcp_only_forwarder https://github.com/m3047/tcp_only_forwarder but nobody was very interested. Point being, if DNS resolution is failing or slow and you can't / won't do traffic shaping you might want to force DNS over TCP / TLS.

m3047 5y ago

There is MDNS for example. Also in terms of alternatives to BGP, you're still going to need to figure out routes. And / or, you going to have to detect loops. Different "anycast" nodes could use something like this to detect each other's presence. You could use the (IP) TTL to limit how many hops a packet will traverse looking for a particular server (no similar concept at the MAC level AFAIK). I hope you have fun!