[RPZ] Answering my own RPZ question

Vernon Schryver vjs at rhyolite.com
Tue Jan 10 19:23:50 UTC 2012


> From: Bill Owens <owens at nysernet.org>

> > On 1/5/2012 7:20 PM, Paul Vixie wrote:
> > > ... we'll fix this some day, probably by adding a new EDNS option to
> > > allow a stub to signal its desire for policy information, and the
> > > recursive would return the truth, the dnssec metadata that validates
> > > the truth, and a signed indication of what the policy based answer
> > > would be. this will require SIG(0) signalling since servers do not
> > > otherwise have signing keys. and it's a long term project that will
> > > have to involve IETF. ...

> I read that article, and my first reaction to the excerpted
> paragraph was that it sounded a bit overcomplex. ...

> We'd run the risk of confusing queriers that aren't upgraded to
> understand the presence of filtering, ...

Upward compatibility among DNS resolvers (and elsewhere) is a given.

Practically no applications care why name resolution fails.  Almost
all applications can only announce that gethostby*() broke and perhaps
send clues to a log for later consideration.  Neither applications
nor users can or will distinguish policy interventions, bad guys or
cops playing games, routing problems, resolver daemon crashes, or
configuration errors from the many other cases of "The Internet is
down."

Practically all applications want and need only to have gethostby*()
work as securely and reliably for DNS names as lines in local hosts
files.  They want simple, secure chatting with a resolver that has
been configured with the right policies, hints, and so forth.

Most stub resolvers also won't care about RPZ details just as they
don't care about the complications of BIND views and ACLs today.  They
want only to know that one resolver failed and a very little of why
to inform future decisions on whether to use that resolver for the
next name.

Note that something that validates is either more than a stub or a bit
of latency pig.  It needs caches, root address and key hints, and so
forth and so on to avoid adding bunches of requests for parent key
records to every request for www.example.com.  Given the attention
Microsoft, Google, and Mozilla pay to reducing browser latency due to
DNS traffic, I doubt they'll be enthused about stubs that multiply
round trips to ISP resolvers.


Vernon Schryver    vjs at rhyolite.com



More information about the DNSfirewalls mailing list