Re: Silently drop queries for AAAA records

[Kevin Darcy]

On 12/7/2010 5:31 PM, David A. Evans wrote:


I'm in the mood to prove a point.   I have a very poorly 
written application that is generating a few hundred queries per 
second of completely bogus  records before attempting a lookup of 
the correct A records.  This is because the application was compiled 
with a IPv6 interface enabled on the severs so it assumes that v6 is 
available.  It is not.  The application owner does not see an issue as 
they get the handful NXDOMAIN responses back in ~2 ms for each valid 
response and don't see any performance hit.


I would like to silently drop the  record lookups instead 
of responding back with NXDOMAIN.
NXDOMAIN? Is the application looking up a different *name* for its  
queries than for its A queries? If a single name owned A records but no 
 records then the correct response from an -capable resolver to 
an  query of the name, would be the so-called "NODATA" response 
(NOERROR with 0 answers and an SOA RR in Authority Section for negative 
caching purposes, see RFC 2308 for details). NXDOMAIN, as another poster 
pointed out, could inhibit even A-record queries of the name, and would 
be the wrong response in that situation.


Thusly generating a performance hit as the application waits 2 seconds 
for the reply.


I have found the filter--on-v4  but it doesn't quiet do 
what I want.  From the description and my testing it appears to still 
reply with NXDOMAIN to these queries, it simply filters out the 
'valid'  records from IPV4 based replies. (which is a really cool 
solution to other issues, but not what I need.)
How nasty do you want to be? You could always add an  record for 
that name. Point it anywhere you want 


If you point it to something simply non-existent, this solution seems to 
me only slightly ruder than silently dropping the queries.




Besides spinning up a bind 4.x box which google tells me did 
this by default, is there any way of doing this?


I think it would be a really *bad* idea to spin up a BIND 4.x instance. 
Do you really want a big ugly security hole on your network? What about 
the person that inherits this setup from you? Would they be conversant 
in BIND 4.x setup and maintenance? I wouldn't wish BIND 4.x on anyone...


If you really want to go in the direction of dropping packets, I'd look 
at some sort of software-firewall intervention (iptables or whatever) to 
do the packet-dropping.


On the other hand, if the app really is looking up a different name for 
 than for A (see above), that opens up all sorts of options for you. 
You could set up that name as a zone by itself and simply return REFUSED 
for all of those queries (the response packet count, and potentially the 
application delay, would be the same, but the response packets would be 
smaller and your intent crystal clear). Or set up a forwarder and play 
some games that way.





- Kevin




*David A. Evans*
*Enterprise IP/DNS Management*
*Network Infrastructure Tools and Services*
*_evans_davi...@cat.com_* 
**
/Eschew Obfuscation/


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Silently drop queries for AAAA records

[Mark Andrews]

In message <4d06a75f.7080...@chrysler.com>, Kevin Darcy writes:
> On 12/7/2010 5:31 PM, David A. Evans wrote:
> >
> > I'm in the mood to prove a point.   I have a very poorly 
> > written application that is generating a few hundred queries per 
> > second of completely bogus  records before attempting a lookup of 
> > the correct A records.  This is because the application was compiled 
> > with a IPv6 interface enabled on the severs so it assumes that v6 is 
> > available.  It is not.  The application owner does not see an issue as 
> > they get the handful NXDOMAIN responses back in ~2 ms for each valid 
> > response and don't see any performance hit.
> >
> > I would like to silently drop the  record lookups instead 
> > of responding back with NXDOMAIN.
>
> NXDOMAIN? Is the application looking up a different *name* for its  
> queries than for its A queries? If a single name owned A records but no 
>  records then the correct response from an -capable resolver to 
> an  query of the name, would be the so-called "NODATA" response 
> (NOERROR with 0 answers and an SOA RR in Authority Section for negative 
> caching purposes, see RFC 2308 for details). NXDOMAIN, as another poster 
> pointed out, could inhibit even A-record queries of the name, and would 
> be the wrong response in that situation.

It's likely to be applying the search list to  queries and *not*
stopping on NODATA then applying the search list to A queries.  I've
argued that this is wrong behaviour and that searches should stop
on NODATA but some people are worried that this change in behaviour
will break something that is depending on the searches skipping
NODATA responses.

If you are worried about this then complain to the OS vendor to fix
the resolver library.

> > Thusly generating a performance hit as the application waits 2 seconds 
> > for the reply.
> >
> > I have found the filter--on-v4  but it doesn't quiet do 
> > what I want.  From the description and my testing it appears to still 
> > reply with NXDOMAIN to these queries, it simply filters out the 
> > 'valid'  records from IPV4 based replies. (which is a really cool 
> > solution to other issues, but not what I need.)
>
> How nasty do you want to be? You could always add an  record for 
> that name. Point it anywhere you want 
> 
> If you point it to something simply non-existent, this solution seems to 
> me only slightly ruder than silently dropping the queries.
> 
> > Besides spinning up a bind 4.x box which google tells me did 
> > this by default, is there any way of doing this?

BIND 4 did not block  queries.
 
> I think it would be a really *bad* idea to spin up a BIND 4.x instance. 
> Do you really want a big ugly security hole on your network? What about 
> the person that inherits this setup from you? Would they be conversant 
> in BIND 4.x setup and maintenance? I wouldn't wish BIND 4.x on anyone...
> 
> If you really want to go in the direction of dropping packets, I'd look 
> at some sort of software-firewall intervention (iptables or whatever) to 
> do the packet-dropping.
> 
> On the other hand, if the app really is looking up a different name for 
>  than for A (see above), that opens up all sorts of options for you. 
> You could set up that name as a zone by itself and simply return REFUSED 
> for all of those queries (the response packet count, and potentially the 
> application delay, would be the same, but the response packets would be 
> smaller and your intent crystal clear). Or set up a forwarder and play 
> some games that way.

Or stop worrying about this and realise that it will self correct
as more sites start using IPv6 and  records.  IPv4 really has
passed its "use by" date.

> - Kevin
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users