Rfc3833:2004;hack:2008
so we all know i hope that dns is one of the worst kludges we have to deal with.

gimme some good reasons why it should take more than 3 successful 512b queries to find the IP(s) for a host.

1st query to tld nameserver (to get hostname of authoritative nameserver)

2nd query to tld nameserver to get IP's of authoritative nameservers

3rd query to an authoritative nameserver to get IP of host

once we have IP(s), add them to HOSTS file

done

most reputable sites are not changing all their IP's very often

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

how hard is that?

the reality is many of us don't always list our IP (A record) in our authoritative nameserver; it's somewhere else

and the number of queries sent to find IP's is shocking

do you list the telephone numbers for your tokyo offices in the telephone directories for new york?

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

cf. the 3 queries above

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

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

we seem operate under an assumption that IP's of reputable sites are ephemeral, with lifespans in the order of seconds, minutes or hours.

for hosts that are accessed by many users, are their IP's really this dynamic?

do we fear a HOSTS file? it's only a copy of what's on file with the registrar

do you store telephone numbers in your iphone? or consult a telephone directory for the same numbers every day?

with up to 13 IP's for any host to choose from, do we need 'load balancing' appliances?

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?

but here's what i wanted to point out: have a look at RFC3833, written in 2004

and tell me that 'cache poisoning' by predicting query ID and src port was 'discovered' in 2008.

so we 'fixed' the predictability problem.

sure cryptography is fun

but we're still sending queries to the wrong nameservers.

i.e. ones that don't have the A record we need

is the solution to sign responses to queries?

why not just start sending queries to the correct nameservers.

you know, the ones listed with the registrar. that entity we have no choice but to trust.

why not start putting A records where they belong: in those authoritative nameservers.

there is no technological fix for a bad registrar.

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.

we have to trust the telecom companies for the directories they publish. and so it is with internet registrars.

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.

the HOSTS file. even packed with 1000's of IP's, it's relatively small.

why not use it for inclusion, not exclusion?

what are your compelling reasons?