[RPZ] Trojan.Spachanel - Using SPF records for malware signaling (problem for RPZ sinkholing?)

[Vernon Schryver]

> From: Alan Doherty <dnsrpz at alandoherty.net>

> ...
> its not a sinkhole issue, its a type of data transmission RPZ can
> never handle (new domains)

What if the new domains have NS RRs with old names listed with NSDNAME
records or new names with old IP addresses with NSIP records in RPZ zones?


> but RPZ i was told back in the day (but my memory may be flawed,
> has a potential fix (but no public zones as yet)
> to allow a zone to be configured that lists IPs of registrars/dns-servers
> that will not be conversed with /talked to, thus allowing all current
> and all future domains by that 'owner' to fail. without knowing the
> domains they registered today

Is that a reference to RPZ NSIP and NSDNAME?  One might search for
"nsdname" in the BIND 9 Administrator Reference Manual (ARM) perhaps
at http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.html

There were recent references to NSIP and NSDNAME in this mailing
list in the thread ending with
https://lists.isc.org/pipermail/dnsrpz-interest/2013-January/000179.html
including mention of public RPZ zones with NSDNAME and NSIP records.

The next versions of the RRL+RPZ patches discussed at
http://www.redbarn.org/dns/ratelimits
will default to `./configure --enable-rpz-nsip --enable-rpz-nsdname`


> but i could be wrong maybe RPZ features don't allow a automated (BIND
> bogus) listing of a name-server, and thus all the domains hosted theirin

I don't understand; what about NSIP and NSDNAME RPZ records?

Please also see
https://deepthought.isc.org/category/110/0/10/Software-Products/BIND9/Features/DNSRPZ/
https://deepthought.isc.org/article/AA-00862/0/Known-Inconsistency-in-DNSRPZs-NSD-and-NSIP-Rules.html


Vernon Schryver    vjs at rhyolite.com