Front page | perl.qpsmtpd |
Postings from June 2005
David Nicol wrote: > On 6/30/05, John Peacock <jpeacock@rowman.com> wrote: > >> Elliot F wrote: >> >>> Another method (and a very scalable one) would be to store user data in DNS. >>> >> Ooh, don't suggest that sort of thing on a DNS admin list unless you really like >> having a cheese grater rubbed on all your private parts. That is a gross >> violation of the design of DNS (but of course I can think of an elegant way to >> do it with a tinydns instance ;-). >> > > PowerDNS appears to be proud that it uses a database for a DNS server > backend. If > that doesn't invite publishing user data by DNS I'll be plunged into > syrup and called > a hotcake. I am not aware of a standard LDAP->DNS translation mechanism, but > I would not be surprised if several exist. > > How about one called "ldapdns"? But what it does is use the ldap format, not tap into a full-service ldap database or backend for all it's worth. The brag is it's faster than tinydns. If some moron wants to put the world's data into a txt record, that's an inside job, or if an ldap-based dns server uses its password to access other than dns records such as txt, a, mx, it's been hacked and the ldap acl's ought to confine it to dns records. Red herring then. If a properly configured ldap to dns link was used, the ldap database would not violate its proper acl policy. Also, the dns layer would not want to know anything but its standard records, which ought not to put a lot of user info into txt records or some such. And it ought not to do zone transfers to the world. That means that either a properly configured ldap server, OR, a properly configured dns server, would shield user data from dns clients. Why not have a stand-alone tinyldap server on localhost hold any kind of data you want? That would be equivalent to your own database or flatfile, no problemo. -BobThread Previous | Thread Next