[dns-operations] eliminating stub resolvers
ml623 at georgetown.edu
Wed Oct 3 12:16:09 UTC 2012
I could not help but think about whether the idea behind "convergence"
, something I stumbled upon recently, could help in this DNS
resolver fundamental issue. The former is an attempt to solve the SSL
CA issue, by eliminating them altogether, and replacing them with a
mean for the client to confirm their perspective of the world
with multiple other observers... Thought this could be the same for
DNS.... I am getting 22.214.171.124 for mybank.com, What do you guys get?
On Wed, Oct 3, 2012 at 4:30 AM, Jim Reid <jim at rfc1035.com> wrote:
> On 3 Oct 2012, at 02:42, Vernon Schryver wrote:
>>>> Why not get rid of stub resolvers completely and simply use recursive
>> I think the code to parse the BIND9 configuration grammar and nothing
>> more would be excessive and grotesque. The code to support all of
>> that stuff would be obscene.
> The code for BIND9's config file goop is not so bad compared to other parts
> of its internals: it's about the same size as validator.c (which has no
> crypto code) for instance.
>> Of course, if the only available code for your situation is BIND, then
>> you could use BIND with a tiny configuration file.
> Yeah. It should even be possible to have a validating resolver using
> automatic rollover for the One True Trust Anchor without any config file at
> all. IIRC, that's pretty much what the almost ignored lwresd does. Though
> please don't assume I want to exhume lwresd. :-)
>> The package would be smaller than current Firefox binaries that send me
>> running and
>> screaming in horror.
> I'm sure someone, somewhere is working on a DNS server that is every bit as
> scary as that bloated train wreck.
> PS: I changed the Subject: header since we're no longer discussing attacks
> on Brazil's DNS.
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> dns-jobs mailing list
More information about the dns-operations