[RPZ] Subject: Re: DNSRPZ TTL Feature

Hugo Maxwell Connery hmco at env.dtu.dk
Sun Apr 21 13:26:23 UTC 2013


RPZ seems to be about lying in *complete* ways for *specific* reasons.

e.g I wish to NXDOMAIN or CNAME domains X, Y and Z.

These are a *complete* replacement of the response from the authoritative
resolver.  Auth said PPPP and I choose to say QQQQ (not PPQP; some subtle change).

Getting into subtle things like fiddling with TTL values seems to be 
a path to intricate trouble.

RPZ is a filtering mechanism rather than a way to fiddle with little parts
of DNS.  One can happily do this oneself, but it seems to be decent 
into trouble.

I think RPZ is wonderful, and do not wish to see it absorb the trouble
the will occur if it starts to provide *partial* changes of DNS responses.
RPZ either makes a complete 'rewrite' of the auth response, or just
passes it through.

The point is the balance between risk protection and fidelity.  Choosing
RPZ allows highly configure filtering.  And, whatever one's response it
must be consistent with *somewhere*: that was their response, or my 
response, and not some subtle mixture of the two.  Consider a sequence
of forwarders in which each modifies some part of the response.  Exponential
complexity nightmare.

/Hugo
----------------------------------------------------------------------

Message: 1
Date: Sat, 20 Apr 2013 14:25:55 +0200
From: "Emanuele Balla (aka Skull)" <skull at bofhland.org>
Cc: dnsrpz-interest at lists.isc.org
Subject: Re: [RPZ] DNSRPZ TTL Feature
Message-ID: <51728953.5050605 at bofhland.org>
Content-Type: text/plain; charset=ISO-8859-1

On 4/20/13 1:04 PM, nudge wrote:

> Sorry, I never intended that. I was thinking of a situation where
> clients of a (closed) recursive server make the same query every minute
> for say an A record that very rarely changes but has a TTL of 60. I
> could pirate that with RPZ by providing the same A response but with a
> more reasonable TTL, if I considered that necessary.

Then hope DNSSEC never comes into play: increasing the TTL of an RRSIG
beyond the validity of the DNSKEY needed to verify it looks like an
amazing way of breaking your resolver...

There must be a reason why resolvers usually allow you to *decrease* the
TTL of the records going in the cache , but rarely allow you to increase
it...


(BTW, IMHO this has nothing to do with RPZ, in any case...)


------------------------------

Message: 2
Date: Sat, 20 Apr 2013 14:38:05 +0200
From: nudge <nudgemac at fastmail.fm>
To: "Emanuele Balla (aka Skull)" <skull at bofhland.org>
Cc: dnsrpz-interest at lists.isc.org
Subject: Re: [RPZ] DNSRPZ TTL Feature
Message-ID:
        <1366461485.5215.140661220370906.7280BB43 at webmail.messagingengine.com>
Content-Type: text/plain

On Sat, Apr 20, 2013, at 02:25 PM, Emanuele Balla (aka Skull) wrote:
> On 4/20/13 1:04 PM, nudge wrote:
>
> > Sorry, I never intended that. I was thinking of a situation where
> > clients of a (closed) recursive server make the same query every minute
> > for say an A record that very rarely changes but has a TTL of 60. I
> > could pirate that with RPZ by providing the same A response but with a
> > more reasonable TTL, if I considered that necessary.
>
> Then hope DNSSEC never comes into play: increasing the TTL of an RRSIG
> beyond the validity of the DNSKEY needed to verify it looks like an
> amazing way of breaking your resolver...

That's determined by how you've set the {yes|no|break-dnssec} option

> There must be a reason why resolvers usually allow you to *decrease* the
> TTL of the records going in the cache , but rarely allow you to increase
> it...

I guess that's true but am curious to know the details

> (BTW, IMHO this has nothing to do with RPZ, in any case...)

If I'm the only one who does, I won't be overly surprised just
disappointed

Thanks




More information about the DNSfirewalls mailing list