If the purpose of the exercise is to identify clients which are querying the
authoritative nameservers directly without going through an "approved" set of
recursive resolvers, then this can be accomplished without a "test page": just
extract from the query logs of the authoritative nameservers the client IPs
that do not belong to the set of "approved" resolvers.
But, I interpreted the question somewhat differently: what I got from it is
that they original poster was *expecting* clients to query their authoritative
nameservers directly and wanted to identify (using the "test page" mechanism)
clients which were going through intermediate (presumably *unapproved*)
forwarders. My answer to that would be: you can't really tell, reliably,
whether a recursive query came through a forwarder or not. Having said that,
one can mine the query logs and identify source IPs that generate an
abnormally-high quantity of queries. One could even follow that up with a check
of whether those IPs are listening on port 53. Another investigative technique
would be to look at the presence or absence of EDNS0 buffer-size in the queries
(stub resolvers usually *don't* set buffer size, but DNS software usually
*does*). These aren't *reliable* methods of finding "unapproved" forwarders,
but at least they can generate some leads.
Of course, assuming I'm interpreting the original post correctly, I'd question
why the original poster wants their clients to query the authoritative
nameservers directly, given the conventional wisdom of separating hosting and
resolving functions. I said "question", because this isn't necessarily a *bad*
thing: these might not be the *published* authoritative nameservers; they might
be "stealth slaves" in a highly-replicated architecture (such as I favor) that
maximizes query performance, nameservice resiliency, and enhanced resistance to
forgery-based attacks and/or cache poisoning. One of the pitfalls of using the
highly-replicated architecture, in a large enterprise, are the "creative" folks
who set up unapproved forwarders. Not only do these "rogue" forwarders negate
some of the availability and security benefits of the highly-replicated
architecture, but the lack of central configuration control also degrades the
effectiveness of advanced techniques like sortlisting, D
NSSEC validation, etc. It's a constant struggle.
- Kevin
-----Original Message-----
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Alan Clegg
Sent: Wednesday, July 29, 2015 10:30 AM
To: bind-users@lists.isc.org
Subject: Re: Block propagation for a specific record A
On 7/29/15 4:59 AM, Job wrote:
> Hello,
>
> for a test page purpuose, we would like to avoid propagation only for a
> specific record A, example:
> test.domain.com
>
> We need to test if users set up our DNS server in ethernet configuration, and
> they display correctly the test page.
> But, if test.domain.com propagate, we are not sure they use our DNS server!
>
> Is there a way?
Create the A record in a delegated zone that is only available to be queried by
your recursive servers.
AlanC
_______________________________________________
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
