Dropping queries from some well-known ports

[Grant Taylor]

On 08/03/2018 12:00 PM, Petr Menšík wrote:
> Hi!

Hi,

> Our internal support reached to me with question, why are some queries 
> bound to low ports silently dropped.

Please clarify if you're saying "bound to" as in the code that 
originated the query came from said port or if you mean queries that are 
going to said port on the DNS server?

> I have found there is feature for that, that will silently drop queries 
> from selected ports.

That's new information to me.

> I admit queries from such low ports are wrong.

I feel like such queries (from) low ports may be "unexpected", but I 
don't know that it's "wrong" per say.

> But why are some ports allowed when some ports are not?

Based on the small list five ports, I'm guessing that these ports caused 
a problem and as such are blocked.

> Should not it be configured by firewall instead?

I'm guessing that named filters the problematic ports as a function of 
protecting it's own stability or otherwise desired behavior.

I would expect that firewalls are more for security of the system.

Different scopes of problem use different solutions.

> Just try this command: $ sudo dig @127.0.0.1 -b 127.0.0.1#32 localhost
> 
> If bind is running on local interface, it will drop the query. If any 
> other server is running there, it will respond.

Bind has chosen to operate in this manner.  Other daemons may or may not 
make the same choice.

> Does such feature make sense in year 2018? Can you remember what was 
> motivation to implement it? Is it wise to still enable it by default, 
> without at least configure option to disable it?

I suspect that bind chose to drop these specific source ports because 
they likely will result in more traffic back from the client.  As such, 
sort of causing a feedback loop.  Mind you, this is just a guess.

> 1. 
> https://gitlab.isc.org/isc-projects/bind9/commit/05d32f6b0f6590ca22136b753309f070ce769000



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180803/27bb5a6b/attachment-0001.bin>