[prev in list] [next in list] [prev in thread] [next in thread]
List: bind-users
Subject: Re: "Nintendo"('s NSes) are asking my IP for it's rdns
From: Kevin Darcy <kcd () chrysler ! com>
Date: 2012-07-25 22:13:48
Message-ID: 50106F9C.5050702 () chrysler ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I'm assuming this "greatunwashed" view
has recursion turned off, right?<br>
<br>
If so, then the following approaches come to mind:<br>
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<br>
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<br>
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.<br>
<br>
In other words, for approach (c), you might have:<br>
<br>
/* our clients, allow to recurse */<br>
view "internal_clients" {<br>
match-clients { x.x.x/24; }; /* or match-destinations,
depending on your setup */<br>
recursion yes;<br>
...<br>
/* implicit or explicit hints file, forwarders, whatever \
*/<br> ....<br>
}<br>
<br>
/* match only external RD=1 queries, deny everything except some
specific zone(s) */<br>
view "slightly_washed_Nintendoids" {<br>
match-recursive-only yes;<br>
recursion yes;<br>
allow-query { none; };<br>
<br>
zone "37.58.216.in-addr.arpa" {<br>
type stub;<br>
file "37.58.216.in-addr.arpa";<br>
allow-query { any; }; /* override \
view default */<br>
masters { y.y.y.y; }; /* ISP's \
nameservers */<br> };<br>
<br>
...<br>
/* might need some authoritative-zone definitions here, if \
you have misconfigured clients */<br>
...<br>
};<br>
<br>
/* match external RD=0 queries, answer from authoritative data
only */<br>
view "greatunwashed" {<br>
recursion no;<br>
/* allow-query-cache { any; }; /* if you prefer to return
upwards referrals rather than REFUSED for queries outside of
authoritative data */<br>
<br>
...<br>
/* authoritative-zone definitions here */<br>
...<br>
};<br>
<br>
\
\
\
\
\
\
\
\
\
\
\
- Kevin<br> <br>
On 7/24/2012 7:05 AM, Brian J. Murrell wrote:<br>
</div>
<blockquote cite="mid:julvh0$hsg$1@dough.gmane.org" type="cite">
<pre wrap="">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.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" \
href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> \
to unsubscribe from this list
bind-users mailing list
<a class="moz-txt-link-abbreviated" \
href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a> <a \
class="moz-txt-link-freetext" \
href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a></pre>
</blockquote>
<br>
<br>
</body>
</html>
_______________________________________________
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic