Saying that, I quite like the idea of dynamically providing a response to both AAAA and PTR queries but question how safe it would be to cache these without a robust resource-managing implementation...
quite safe.. its not dns caching... in fact, we'd put the ttl on 1 second or something, but rather a ram caching on the authorative servers. now the stuff that hardly gets resolved, like, most of your ip space, doesn't cause a problem, even if it does have an entry in the database for PTR www.customer.com. (as http clients don't generally use reverse dns) dns caching downstream causes more problems than its good for since people no longer use slow links, you do want to be albe to change them real-time nowadays (not to mention dns poisoning issues). you would want to keep database results for lets say your smtp servers and your nameservers themselves in RAM cache for 10-60 seconds or so or your database will go nuts (and people could dos your database even ;) getting rid of bind has various other advantages, such as no longer needing tcp to transfer "zone files" (Retarded concept to say the least) so there are no more "tcp issues" related to anycasting your authorative dns servers, as you can simply have them talk to your central database over their bgp session ip, which isn't anycasted, no more port 53/tcp therefore! yay, good riddance! no more "zones", just individual records, anything thats not a "record" in the db gets automatically generated on the fly, and no more dns cache downstream (well we can't help it if resolvers try anyway but it wont bring them much ;). ofcourse, should the database, at any point, become unreachable, the authorative servers should use the ram cached entries -regardless- of their timestamp until they can reach the database again. the way bind handles things.. isn't really suitable for bigger ipv4 and it definately isn't suitable for ANY ipv6 network, and the whole thing with files being transferred.. well.. ahem... "primitive". bind was coded in a time when the internet ran on 64kbit links.. caching downstream back then was desired and things weren't so "large", and it really didn't matter much if things took hours. (why do we STILL have to wait for new domains... just drop the whole concept of -files- and -zones- domain registrations should work -instantly-! not after a "reload" of something that should not be used anymore anyway). with ipv6, it has =finally- become impossible to maintain that outdated model! yay! good riddance :P On Tue, 2 Nov 2010, David Freedman wrote:
Sven Olaf Kamphuis wrote:
would be interested in anybody other than IRC operators who feel they still require forward and reverse DNS to match,
SMTP, email-2 (don't ask ;), and preferably (though not required) anything that has to do with /bin/login on *nix systems (as it shows the reverse dns host name in who and w and last unless specified otherwise).
Well, at least with DNSSEC, you can assure the end user that the wildcarding was intentional (through validation), I dont see why those systems shouldn't be acceptant of intentionally obscured hosts in the future ?
Saying that, I quite like the idea of dynamically providing a response to both AAAA and PTR queries but question how safe it would be to cache these without a robust resource-managing implementation...
Dave.
--
David Freedman Group Network Engineering Claranet Group