Local rpz ban list format

Reading the spec for rpz zone files it is not clear to me what and if I need to specify any sort of specific headers and values.
​I have a static rpz file called rpz.block.hosts.zone where I keep manual entries of my own banned hosts.

​Some examples I found was like this below. Since this is my own static list do I need to add the $TTL and other onfo in the header?

$TTL 2h
@ IN SOA localhost. root.localhost. (1 6h 1h 1w 2h)
IN NS localhost.
;
;
example.com CNAME .

in BIND, a zone must have an SOA and an NS or loading will fail, and so
the RPZ specification calls for these elements. while it's unknown to me
whether Unbound has the same requirement, i suggest you keep your RPZ's
in a portable form, and thus, that you include these elements.

$TTL is unnecessary. the TTL of records in an RPZ is not relevant, and
the SOA.MINIMUM will be the default TTL unless you specify $TTL.

Thankx Alex. I have studied this document, however it does not cover all the “header” requirements for a local file.
​The document as I read it gives an example of the file with only one header line as in
​"$ORIGIN [zone name]". I don’t think this is a standard spec.

​What Paul has suggested works in unbound. But what I am not sure about why I need to specify any sort of TTL values
​for a local rpz file I manage to ban permanently some bad hosts. I want indefinite TTL for banned hosts. Maybe I am not understanding it completely but with Pauls suggested header values it works and blocks my hosts.

What Paul has suggested works in unbound. But what I am not sure
about why I need to specify any sort of TTL values

one of the most controversial parts of the RPZ design was the use of DNS
zone files to convey recursive server policy. this kind of overloading is
often a sign of ignorance or bad taste. for example, using "CNAME ." as a
way to signal that the owner name should trigger an artificial NXDOMAIN
response (without regard for the authoritative truth of that matter) is,
no matter how you look at it, pretty ugly.

we (the RPZ designers; vernon schryver and myself) had no use for TTL,
and so it doesn't matter to us what value you use. since the zone is
not going to be "served," the value makes no difference to Unbound (or
BIND, or Knot, or PowerDNS, all of which now support RPZ). so, letting
the TTL be the minimum (last of the five numbers in the SOA record) is
absolutely harmless and arguably the most correct.

for a local rpz file I manage to ban permanently some bad hosts. I want
indefinite TTL for banned hosts. Maybe I am not understanding it completely
but with Pauls suggested header values it works and blocks my hosts.

TTL has no role in RPZ. but it must be present because RPZ uses DNS zones
to convey DNS recursion policy. so, use any value you please, because
nothing will see it except you when editing your "zone file".

we overloaded the DNS "zone" mechanism to carry recursive DNS policy because
it was a format that the servers already understood, and a relied on a set
of firewall rules that DNS operators already understood.

Thank you Paul for taking the time and explaining in more details. I have learned few things tfrom you today.
​Much appreciated.

The TTL of records in an RPZ might affect caching on a client, or an
intermediate forwarder, for 'positive' responses.

MIN(SOA TTL, SOA MINIMUM) might affect caching on a client/forwarder if
an RPZ trigger causes a negative response that includes an SOA.

Kind regards,

Sorry to respond twice to the same email - I only realised this later.