Is it possible to tell NSD to just drop recursive queries, instead of replying with a “REFUSED” message?
Why do you want to receive double the queries?
Paul
What do you mean?
Some security scans say the following:
External Query:
Rejected (Recommended: Drop)
And list it as a yellow status.
-----Ursprungligt meddelande-----
Is it possible to tell NSD to just drop recursive queries, instead of replying with a “REFUSED” message?
Why do you want to receive double the queries?
What do you mean?
If a real DNS client is sending you a query, and it does not get a
response, it will likely try 2 more times. By not answering, you
will get double or tripple the traffic.
Some security scans say the following:
External Query:
Rejected (Recommended: Drop)And list it as a yellow status.
Some security software needs to hire some DNS people ![]()
Paul
My tought is that its harder to scan for DNS servers and (eventually) attack them, if they don't reply at all unless its absolute necessary (eg if it’s a authorative query for something the server is authorative for).
Have you heard about GRC, Gibson Research Corporation?
They say, that its better to ignore instead of replying.
-----Ursprungligt meddelande-----
Hi,
If you a run hidden service, ie. one that is not pointed to by other
public service such as DNS records specifying you as NS, you might be
right.
But when your service is initially public, then why should you make it
harder for people to use it? Abusers will come by anyway, they're not
fooled by the fact that you're dropping packets sometimes...
My 2 cents,
Tom
And make yourself more vulnerable to off-path spoofing attackers? That's
a really bad idea.
O.
What do you mean? What is "off-path spoofing attacks" and how would ignoring a query instead of replying to it, make you more vulnerable?
Why does Steve Gibson ( http://www.grc.com ) say its more spoofing-resistant to ignore external queries instead of refusing?
-----Ursprungligt meddelande-----
What do you mean? What is "off-path spoofing attacks" and how would ignoring
a query instead of replying to it, make you more vulnerable?
When a query is made from a caching resolver there is a race between the
legitimate answer and one that presents the same source ip, destination port
and dns query id that the caching resolver is expecting. This latter response
is an "off-path spoofing attack". For an attacker to be able to win the race
they have to guess the source port the cache used (which becomes the
destination port that the authoritative server responds on) and the 16 bit
query id before the legitimate server has a chance to respond. If the
legitimate server never responds because it's configured to blackhole queries
for the domain (even if the cache and/or authoritative server is misconfigured/
unwisely configure as in the original question as caching resolvers should not
be sending queries with recursion desired to authoritative servers in normal
circumstances) then the attacker gets more time (presumably up to sime timeout
hardcoded into the cache) to continue guessing the correct source port/query
id combination. In the case that the authoritative server is configured to send
a REFUSED response then the attacker has 1 round trip from the cache to the
authoritative server in which to guess this combination. I also suspect that
many caches will track the refused response from the authoritative server as a
lame delegation and avoid it, so that the attacker can't continue querying the
cache and attempting to poison the cache. They only need to win the race once
in order to override the legitimate answer, so when the server which is
supposed to be responsible for the domain doesn't respond they can keep
retrying for much longer.
Why does Steve Gibson ( http://www.grc.com ) say its more spoofing-resistant
to ignore external queries instead of refusing?
Because he's a snake-oil salesman who doesn't really know what he's talking
about. His advice might be useful in the case of a client system. Someone
scanning for potentially exploitable computers might choose to do a icmp-
request or probe a particular service with known vulnerabilities. Not replying
to them means that they will be unsure as to whether there is a computer
connected at that ip address at all. In the case of a server, you're providing
a publicly available service. You presumably want random people on the
internet to be able to make use of the service, so sending a response is
desirable.