Block propagation for a specific record A

Darcy Kevin (FCA) kevin.darcy at
Wed Jul 29 14:55:07 UTC 2015

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, DNSSEC validation, etc. It's a constant struggle.

											- Kevin

-----Original Message-----
From: bind-users-bounces at [mailto:bind-users-bounces at] On Behalf Of Alan Clegg
Sent: Wednesday, July 29, 2015 10:30 AM
To: bind-users at
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:
> We need to test if users set up our DNS server in ethernet configuration, and they display correctly the test page.
> But, if 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.


More information about the bind-users mailing list