

Rfc3833:2004;hack:2008 - hostsfile

so we all know i hope that dns is one of the worst kludges we have to deal with.<p>gimme some good reasons why it should take more than 3 successful 512b queries to find the IP(s) for a host.<p>1st query to tld nameserver (to get hostname of authoritative nameserver)<p>2nd query to tld nameserver to get IP's of authoritative nameservers<p>3rd query to an authoritative nameserver to get IP of host<p>once we have IP(s), add them to HOSTS file<p>done<p>most reputable sites are not changing all their IP's very often<p>if (and only if) they do, then we can requery<p>how hard is that?<p>the reality is many of us don't always list our IP (A record) in our authoritative nameserver; it's somewhere else<p>and the number of queries sent to find IP's is shocking<p>do you list the telephone numbers for your tokyo offices in the telephone directories for new york?<p>50+ queries to a varied array of servers to find the IP's for <i>one</i> host is not unusual<p>cf. the 3 queries above<p>with 50 queries i can stock my HOSTS file with numerous IP's for different hosts i need to look up, instead of wasting them all to find the IP's of one single host<p>with storage being as inexpensive as it is today (unlike 20-30 yrs ago), keeping large lists of IP's (some of which can be loaded into RAM) is not unfathomable<p>we seem operate under an assumption that IP's of reputable sites are ephemeral, with lifespans in the order of seconds, minutes or hours.<p>for hosts that are accessed by many users, are their IP's really this dynamic?<p>do we fear a HOSTS file?  it's only a copy of what's on file with the registrar<p>do you store telephone numbers in your iphone?  or consult a telephone directory for the same numbers every day?<p>with up to 13 IP's for any host to choose from, do we need 'load balancing' appliances?<p>and if popular browsers and OS's are themselves caching IP's mostly outside of the user's control, then are these load balancing devices irrelevant?<p>but here's what i wanted to point out: have a look at RFC3833, written in 2004<p>and tell me that 'cache poisoning' by predicting query ID and src port was 'discovered' in 2008.<p>so we 'fixed' the predictability problem.<p>sure cryptography is fun<p>but we're still sending queries to the wrong nameservers.<p>i.e. ones that don't have the A record we need<p>is the solution to sign responses to queries?<p>why not just start sending queries to the correct nameservers.<p>you know, the ones <i>listed with the registrar</i>.  that entity we have no choice but to trust.<p>why not start putting A records where they belong: in those authoritative nameservers.<p>there is no technological fix for a bad registrar.<p>so ultimately, if we follow the path to the 'top', the whole scheme relies on people trusting people (as it did in 1970), not who has the most clever algorithm.<p>we have to trust the telecom companies for the directories they publish.  and so it is with internet registrars.<p>apparently it took 4 yrs to implement the dns 'flaw' described in rfc3833.  maybe the whole idea of dns is flawed. the registrars have all the info we need.  and we have the storage capacity, the power and bandwidth to handle large directories of numbers now.  all of us do.  maybe we do not need to distribute this job anymore.<p>the HOSTS file.  even packed with 1000's of IP's, it's relatively small.<p>why not use it for inclusion, not exclusion?<p>what are your compelling reasons?
======
jodrellblank
> most reputable sites are not changing all their IP's very often

Your suggestion is that only disreputable sites are changing their IPs
frequently, but there are a lot which return different addresses for load
balancing or geolocation or CDN reasons, or which genuinely might change (MX
records particularly) quickly, and some which are generated on the fly so
never-typed-before.example.org will resolve, because they've configured a
server to reply to any request but there is no inclusive list to cache.

> if (and only if) they do, then we can requery

And how will the client know? If the site is down it might be down for real or
the client might have no internet connection, instead of the IP being
outdated. If there's another site on the old IP then it will connect and
return valid headers. You'd have to rely on the user already knowing the
website they wanted to see and saying "that isn't right try again but properly
this time" and that assumes it is something user facing rather than a POP3
connection which suddenly "can't connect" or gives a login failure.

Plus you'd then need every popular TCP/IP using program ever to be rewritten
to have a "try again but this time with a full DNS requery" option.

> 50+ queries to a varied array of servers to find the IP's for one host is
> not unusual

So fix that, don't overhaul the whole system because some people can't
configure it properly. As you said it shouldn't need more than three or four
at most. Where are you seeing that so often that you say it is "not unusual"?

> so ultimately, if we follow the path to the 'top', the whole scheme relies
> on people trusting people

As does the whole SSL certificate pyramid scheme and the whole 'using an OS
that was written by other people' scheme and the whole 'eating food grown and
processed far away' scheme. That doesn't mean it's inherently awful.

> we have to trust the telecom companies for the directories they publish.

And we have to trust them to route packets to their destinations once we have
the resolved IP as well and not change the content on the way over, too.

> popular browsers and OS's are themselves caching IP's mostly outside of the
> user's control, then are these load balancing devices irrelevant?

No, they load balance for the site over many users, not between individual
requests from the same user. And if OSes and browsers are caching why bring
the hosts file into it?

> the HOSTS file. even packed with 1000's of IP's, it's relatively small. What
> are your compelling reasons?

You can run your own caching name server (on your computer or LAN) right now,
you don't need to overhaul DNS for the whole world in order to benefit. Plus,
local hosts file management generally would be a pain in the neck.

