Re: IPv6 rDNS

[Sven Olaf Kamphuis <sven () cb3rob net>]

> 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