You solve that by complaining to the operators of the servers that their
DNS servers mis-implement DNS COOKIE (RFC 7873) and could they request a fix
from their DNS vendor.
Not that they make things easy to contact them. No email in whois. Just
a PO box and a phone number and I don’t intend to
On 6/10/19 3:29 PM, Mark Andrews wrote:
The primary issue here is that there is still source address spoofing
happening so you have to consider what if this packet was spoofed. DNS
uses UDP and is used as a reflector. The small services ports listed
generate reply traffic.
Additionally
The primary issue here is that
there is still source address spoofing happening so you have to consider what
if this packet was spoofed. DNS uses UDP and is used as a reflector. The small
services ports listed generate reply traffic.
Additionally kpasswd and a DNS server can generate a self
On Mon, Jun 10, 2019 at 12:37 PM Grant Taylor via bind-users
wrote:
>
> On 6/7/19 8:44 PM, Mark Andrews wrote:
> > Named drops those ports as they can be used in reflection attacks.
> > Sane NAT developers avoid those ports for just that reason. The full
> > list is below.
>
> I understand the
> On 11 Jun 2019, at 8:01 am, Grant Taylor via bind-users
> wrote:
>
> On 6/10/19 3:29 PM, Mark Andrews wrote:
>> The primary issue here is that there is still source address spoofing
>> happening so you have to consider what if this packet was spoofed. DNS uses
>> UDP and is used as a
On 6/10/19 4:56 PM, Mark Andrews wrote:
Named is already selective about what it doesn’t reply to.
* Packets < 12 octets (DNS header size) don’t get a reply.
* QR=1 doesn’t get a reply.
* Source port 0 doesn’t get a reply (source port 0 is “discard me”).
* Kpasswd doesn’t get FORMERR.
* echo,
We have a strange problem related to DNS services, maybe someone here have a
clue what could be the problem.
We are running BIND 9.14.2 in several servers, ns1.qnet.fi, ns2.qnet.fi etc.
Everything else works fine, but with one small operator (actually a
mediahouse), we can not get any replies
On Mon, Jun 10, 2019 at 02:28:46PM +,
Jukka Pakkanen wrote
a message of 382 lines which said:
> An example, the client domain is raimoasikainenoy.fi.
dig clearly says it's a cookie issue:
% dig @193.184.54.212 NS raimoasikainenoy.fi
;; Warning: Client COOKIE mismatch
An DNSviz
On Jun 10 2019, Jukka Pakkanen wrote:
We have a strange problem related to DNS services, maybe someone here have
a clue what could be the problem.
[…]
An example, the client domain is raimoasikainenoy.fi.
Well, there is certainly something wrong with ns.datatower.fi [193.184.54.212],
as it
Thank you Mark. A popular NAT appliance manufacturer has some logic that
attempts to keep the translated source port close to the untranslated
source port which can sometimes result in the behavior I've described
where DNS queries use the well known source port of protocols that are
abuse
-Original Message-
From: Chris Thompson On Behalf Of Chris Thompson
Sent: 10. kesäkuuta 2019 17:30
To: Jukka Pakkanen
Cc: bind-us...@isc.org
Subject: Re: Strange DNS problem
On Jun 10 2019, Jukka Pakkanen wrote:
>We have a strange problem related to DNS services, maybe someone here
-Original Message-
From: Chris Thompson On Behalf Of Chris Thompson
Sent: 10. kesäkuuta 2019 17:30
To: Jukka Pakkanen
Cc: bind-us...@isc.org
Subject: Re: Strange DNS problem
On Jun 10 2019, Jukka Pakkanen wrote:
>We have a strange problem related to DNS services, maybe someone here
On 6/10/19 10:18 AM, Barry Margolin wrote:
Why would the original source port be close to any of these low port
numbers? Source ports should normally be ephemeral ports.
There has been some movement afoot in the last 10 years or so to use
more of the 65,535 ports as the source port for
In article ,
Blake Hudson wrote:
> Thank you Mark. A popular NAT appliance manufacturer has some logic that
> attempts to keep the translated source port close to the untranslated
> source port which can sometimes result in the behavior I've described
> where DNS queries use the well known
On 6/7/19 8:44 PM, Mark Andrews wrote:
Named drops those ports as they can be used in reflection attacks.
Sane NAT developers avoid those ports for just that reason. The full
list is below.
I understand the logic behind avoiding potentially problematic ports.
But I don't understand the
On Mon, Jun 10, 2019 at 05:43:02PM +,
Jukka Pakkanen wrote
a message of 58 lines which said:
> Then, unfortunately our nameservers won't resolve ns.kpk.fi either.
Same authoritative name server, same problem. See my email.
% dig @ns.datatower.fi. NS kpk.fi.
;; Warning: Client COOKIE
Yeah, another advertising company turned to an ISP...
Solved *our* problem now by including the suggested server clause for both of
their broken servers, to our servers. Of course does not solve the real
problem, the broken servers of theirs.
Thanks for help.
Jukka
-Original
17 matches
Mail list logo
