[Pdns-users] Forward-zones being skipped via cache?

[Ben C.]

Hello All, I've been struggling this for days..

The point is to be able to 'replace' hostnames based on their
nameservers.  We have many uses for this - ad blocking and many large
porn networks use the same nameservers (like ns1.dirtyxxx.com, just as
a made-up example)

I've been loops and loops - originally having the BIND point of view
with things that the recursor and authoritative nameserver are one
*thing* and eventually narrowed it down to this.  For this example I'm
trying to block parked domains based on their nameservers.  In
honesty, it's not even the point of "if it's the best way" to do X, --
I know this is possible with a DNS recursor, I just really think it
should be possible with powerdns.

My theory of thought (or, what I was told rather) is that this would
be possible with powerdns by using forward-zones=

so I have forward-zones-file= looking something like this:

ns1.fastpark.net=127.0.0.2
ns2.fastpark.net=127.0.0.2
ns1.sedoparking.com=127.0.0.2
ns2.sedoparking.com=127.0.0.2

Now, I run an authoritative nameserver on 127.0.0.2 that runs the bind
backend, (I want to change this later to something more intelligent,
but this should work for now as far as I understand:)

launch=bind
.. etc .. named.conf has something like:

zone "." IN {
 type master;
 file "/etc/powerdns/bind/all.zone";
};

with all zone, now looking like this: (apologies for formatting)

---

@ IN SOA ns.example.com. hostmaster.example.com. (
2012033001
14400
7200
3600
1800 )
@ IN NS ns.example.com.

ns1.fastpark.net IN A 127.0.0.2
ns2.fastpark.net IN A 127.0.0.2
ns1.sedoparking.com IN A 127.0.0.2
ns2.sedoparking.com IN A 127.0.0.2

*.COM                            IN A 1.2.3.4
<note: if it has any valid concern, I have all TLDs listed here, but
snipped them.  afaik there is a bug pertaining to catchalls
 so I cannot simply use a * wildcard>

---

where 1.2.3.4=a server that's setup to respond with "blocked" on as
many protocols that can be done sanely

If you're still following me, this in theory would look like this:

-> Lookup x.com that has ns ns1.y.com ns2.y.com
-> I want to replace ns1.y.com & ns2.y.com with my own
-> Request comes in through recursor, see's it in forward-zones and
passes it to 127.0.0.2 (which is the authoritative)
(this seems to be the step that fails now for some domains, I'll explain more)
-> Request is forwarded to 127.0.0.2.  It asks about the A record for
ns1.y.com / ns2.y.com
-> Authoritative tells the recursor .e.x ns1.y.com|A is 127.0.0.2
-> It now asks 127.0.0.2 (which it thinks is ns1.y.com), the
authoritative, what is x.com|A
-> Authoritive would respond 1.2.3.4 from the catch-all

... It seem's all fine and dandy for SOME requests, but not all.  I'm
not 100% sure why, but it seems in the case of .com's -
or .. I'm not sure if it is explicitly something due to the nature of
the gTLD servers or how this specific nameserver is setup..
But, it seems for SOME domains, at the point it asks the gTLD servers
for e.x. "x.com|NS", the gTLD's are responding with
the A records as well, see here: (note, I am still blanking out
anybody but sedo here:
Note I'm using parked-domain.tld as a placeholder for any domain with
ns1/ns2.sedoparking.com

;; QUESTION SECTION:
;www.parked-domain.tld.		IN	A

;; AUTHORITY SECTION:
www.parked-domain.tld.	172800	IN	NS	ns1.sedoparking.com.
www.parked-domain.tld.	172800	IN	NS	ns2.sedoparking.com.

;; ADDITIONAL SECTION:
ns1.sedoparking.com.	172800	IN	A	209.239.114.58
ns1.sedoparking.com.	172800	IN	A	74.208.13.27
ns1.sedoparking.com.	172800	IN	A	82.165.128.95


This can be seen in the trace here affecting my "forward-zones":
(I hope the heavy snipping didn't take anything away-I removed some
redundant information,
timestamps, etc here)

pdns_recursor: [1] www.parked-domain.tld.: Resolved 'com.' NS
f.gtld-servers.net. to: 192.35.51.30
pdns_recursor: [1] www.parked-domain.tld.: Trying IP 192.35.51.30:53,
asking 'www.parked-domain.tld.|A'
pdns_recursor: [1] www.parked-domain.tld.: Got 10 answers from
f.gtld-servers.net. (192.35.51.30), rcode=0, in 78ms
pdns_recursor: [1] www.parked-domain.tld.: accept answer
'www.parked-domain.tld.|NS|ns1.sedoparking.com.' from 'com.'
nameservers? YES!
pdns_recursor: [1] www.parked-domain.tld.: accept answer
'www.parked-domain.tld.|NS|ns2.sedoparking.com.' from 'com.'
nameservers? YES!
pdns_recursor: [1] www.parked-domain.tld.: accept answer
'ns1.sedoparking.com.|A|209.239.114.58' from 'com.' nameservers? YES!
<snipped 7 more A records>
pdns_recursor: [1] www.parked-domain.tld.: determining status after
receiving this packet
pdns_recursor: [1] www.parked-domain.tld.: got NS record
'www.parked-domain.tld.' -> 'ns1.sedoparking.com.'
pdns_recursor: [1] www.parked-domain.tld.: got NS record
'www.parked-domain.tld.' -> 'ns2.sedoparking.com.'
pdns_recursor: [1] www.parked-domain.tld.: status=did not resolve, got
2 NS, looping to them
pdns_recursor: [1] www.parked-domain.tld.: Nameservers:
ns1.sedoparking.com.(0ms), ns2.sedoparking.com.(0ms)
pdns_recursor: [1] www.parked-domain.tld.: Trying to resolve NS
'ns1.sedoparking.com.' (1/2)
pdns_recursor: [1]   ns1.sedoparking.com.: Looking for CNAME cache hit
of 'ns1.sedoparking.com.|CNAME'
pdns_recursor: [1]   ns1.sedoparking.com.: No CNAME cache hit of
'ns1.sedoparking.com.|CNAME' found
* And the following line is the cause of my issue, I believe:
pdns_recursor: [1]   ns1.sedoparking.com.: Found cache hit for A:
209.239.114.58[ttl=86400] 74.208.13.27[ttl=86400]
82.165.128.95[ttl=86400] 91.195.240.162[ttl=86400]
pdns_recursor: [1] www.parked-domain.tld.: Resolved
'www.parked-domain.tld.' NS ns1.sedoparking.com. to: 209.239.114.58,
74.208.13.27, 91.195.240.162, 82.165.128.95
pdns_recursor: [1] www.parked-domain.tld.: Trying IP
209.239.114.58:53, asking 'www.parked-domain.tld.|A'
pdns_recursor: [1] www.parked-domain.tld.: Got 1 answers from
ns1.sedoparking.com. (209.239.114.58), rcode=0, in 31ms

So it seems to me that when gtld returns the A records, pdns is
caching that result, and before it gets a chance to consult
forward-zones very shortly after,
it see's it already in it's cache and uses it instead, thereby making
it fairly useless in my circumstance.  Is there anyway around this?

I tried disabling & enabling the packet cache but my guess is this is
a different kind of cache than the packet cache.

I also want to note, that it seems that some .info domains I tried are
excempt from this - give saferiphone.info a try:

dig @c0.info.afilias-nst.info saferiphone.info

It does not return "A" records in this case (only NS) and my system
seems to work flawlessly in these circumstance.

Any ideas?  Suggestions?  Work-around?  Confirmation I'm not a loon?
This is really bugging me because I developed
the whole thing using the .info domain as an example and was so
excited to get it working, only to realize that only
my example was working!

Thanks, Ben