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
