I'm assuming this "greatunwashed" view has recursion turned off, right?
If so, then the following approaches come to mind:
a) create a master zone for 5.37.58.216.in-addr.arpa in the
non-recursive view, putting the PTR record at the apex
b) become a "stealth" (unpublished) slave for 5.37.58.216.in-addr.arpa
(or its closest-enclosing zone) in the non-recursive view. Your ISP
would need to permit zone transfers to make this approach work
c) define a new view with "match-recursive-only" and lock it down so
that queries from external address ranges are only allowed for
5.37.58.216.in-addr.arpa (or its closest-enclosing zone), which you
would define as "type stub" or "type forward" in that view. Of course,
this method will only work if these Nintendo queries are actually RD=1
(have you verified this?). As a precaution, you might want to
double-check your query logs (or a packet capture) and see if any of the
queries currently being answered successfully from your
non-authoritative view are actually -- and superfluously -- RD=1. If
this is the case, you'll have to either fix the clients, or define the
relevant authoritative zones in *both* views in order to keep those
clients from breaking.
In other words, for approach (c), you might have:
/* our clients, allow to recurse */
view "internal_clients" {
match-clients { x.x.x/24; }; /* or match-destinations, depending on
your setup */
recursion yes;
...
/* implicit or explicit hints file, forwarders, whatever */
....
}
/* match only external RD=1 queries, deny everything except some
specific zone(s) */
view "slightly_washed_Nintendoids" {
match-recursive-only yes;
recursion yes;
allow-query { none; };
zone "37.58.216.in-addr.arpa" {
type stub;
file "37.58.216.in-addr.arpa";
allow-query { any; }; /* override view default */
masters { y.y.y.y; }; /* ISP's nameservers */
};
...
/* might need some authoritative-zone definitions here, if you have
misconfigured clients */
...
};
/* match external RD=0 queries, answer from authoritative data only */
view "greatunwashed" {
recursion no;
/* allow-query-cache { any; }; /* if you prefer to return upwards
referrals rather than REFUSED for queries outside of authoritative data */
...
/* authoritative-zone definitions here */
...
};
- Kevin
On 7/24/2012 7:05 AM, Brian J. Murrell wrote:
I've come across something interesting in my named logs:
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:16:38 named client 205.166.76.12#55728: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
where 216.58.37.216 is my IP address, assigned by my ISP and reverse
resolved by my ISP's name servers.
What is interesting is the fact that 205.166.76.12 are asking me
(216.58.37.216) for the PTR for my address.
Is this just broken NS software or are they (Nintendo, FWIW) doing
something interesting, like giving everyone an opportunity to provide
an rdns for their own IP address without everyone having to make
classless in-addr.arpa delegation arrangements with their ISP (which
mine refused to do)?
It's kind of a neat concept if it's not just an accident of broken NS
software.
Has anyone else seen anything like this before? Is there some
(proposed even) standard for doing this that I'm not aware of?
In any case, now to the BIND part. It seems reasonable for me to
answer that query, either with my own data or simply by allowing
that query to recurse.
I suppose I could create a zone for it and put some data in it for
that one record if I wanted to provide my own data. But what if I
just wanted to allow recursive queries on that name so that I simply
returned whatever the proper NSes for it reports? I guess I could add
a zone record for it with a forwarder(s) configured to the name's proper
NSes, yes? But that means me having to maintain those forward records
in tandem with my ISP playing musical NSes (which I don't expect but
why create a possible maintenance headache).
So how could I configure BIND to allow a query for 5.37.58.216.in-
addr.arpa to be recursive for everyone, but of course, continue to
disallow general open recursive querying for names not served here?
Cheers,
b.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users