Re: Strange DNS problem
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 call it from here. name...: DATATOWER AB register number: 0708753-2 address: PB 144 address: 67101 address: KOKKOLA country: Finland phone..: +358 20 7789 564 holder email...: https://datatower.fi is just a login form with a bad CERT (for mail.datatower.fi). Mark > On 11 Jun 2019, at 4:36 am, Jukka Pakkanen wrote: > > 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 Message- > From: Stephane Bortzmeyer > Sent: 10. kesäkuuta 2019 20:01 > To: Jukka Pakkanen > Cc: c...@cam.ac.uk; bind-us...@isc.org > Subject: Re: Strange DNS problem > > 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 mismatch > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND ignores queries from specific privileged source ports
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, chargen, time and daygen don’t get a reply. The last 2 sets have been used in reflection attacks in the past. Would those reflection attacks work today with BIND's current filtering (save for filtering source port)? I don't understand how an incoming packet from chargen, time, or daygen could be interpreted as valid DNS queriy. I guess a specially crafted packet from echo /might/ conceptually be able to be interpreted as a DNS query. I would be shocked if anything from kpasswd could be interpreted as a DNS query. I can see how any of these might elicit format error reply from BIND. But I feel like filtering a format error reply based on the handful of ports would allow legitimate queries from said ports. Traffic loops don’t spontaneously come into existence. ACK I was more thinking more along the lines of: 1) Attacker spoofs the source of something that will elicit a format error. 2) BIND receives the packet and sends a format error to echo. 3) Echo receives the format error and echo it back BIND. 4) GOTO 2 There are also very few UDP services. As for the replies named process. There has to be a outstanding request from the source port to the destination port. QR must be 1 for it to be processed. The qid must also be outstanding for that source and destination port tuple. The packet must also be well formed. The question section must also match the query for none error responses. I don't see how BIND would even get into a situation where it might have something to send without all of that being true. I would also think that anything that wasn't a legitimate DNS request would have never made it to the point that there was a reply to potentially be sent out. I'm guessing there is history that I'm completely ignorant of. I hope that a lot of things have changed since then that I'm ignorant of. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND ignores queries from specific privileged source ports
> 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 reflector. The small services ports listed generate >> reply traffic. >> Additionally kpasswd and a DNS server can generate a self sustaining traffic >> loop if it is not suppressed. > > I'm guessing that the reply / kpasswd traffic is not a valid DNS query. > > As such, I would think that it's possible to detect this and respond > accordingly. If the incoming packet is not a valid DNS query and it's from > one of the aforementioned ports, ignore it / drop the outbound error message. > > If the incoming packet is a valid DNS query, then go ahead and reply. > >> There are ~63500 ephemeral ports > > Sadly, many things don't use that wide of an Ephemeral Port range by default. > > Per IANA, the 65536 possible port are divided into three ranges: > >0 to 1023 for System > 1024 to 49151 for User Ports > 49152 to 65535 for Dynamic and / or Private Ports a.k.a. Ephemeral Ports > > So, strictly adhering to IANA recommendations, there are only 16,384 > Ephemeral Ports (14 bits). > > This means that DNS administrators either use their OS default, adhere to > IANA's recommendation, or use something of their own choosing. > > I guess "their own choosing" could be 1024-65535. That amounts to 64512 > possible ports / ~15.98 bits. Conversely, 65536 ports amounts to 16 bits. > > See my other replies for my questions about why BIND can't be more selective > in the replies it processes. 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, chargen, time and daygen don’t get a reply. The last 2 sets have been used in reflection attacks in the past. Traffic loops don’t spontaneously come into existence. There are also very few UDP services. As for the replies named process. There has to be a outstanding request from the source port to the destination port. QR must be 1 for it to be processed. The qid must also be outstanding for that source and destination port tuple. The packet must also be well formed. The question section must also match the query for none error responses. Mark > -- > Grant. . . . > unix || die > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND ignores queries from specific privileged source ports
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 kpasswd and a DNS server can generate a self sustaining traffic loop if it is not suppressed. I'm guessing that the reply / kpasswd traffic is not a valid DNS query. As such, I would think that it's possible to detect this and respond accordingly. If the incoming packet is not a valid DNS query and it's from one of the aforementioned ports, ignore it / drop the outbound error message. If the incoming packet is a valid DNS query, then go ahead and reply. There are ~63500 ephemeral ports Sadly, many things don't use that wide of an Ephemeral Port range by default. Per IANA, the 65536 possible port are divided into three ranges: 0 to 1023 for System 1024 to 49151 for User Ports 49152 to 65535 for Dynamic and / or Private Ports a.k.a. Ephemeral Ports So, strictly adhering to IANA recommendations, there are only 16,384 Ephemeral Ports (14 bits). This means that DNS administrators either use their OS default, adhere to IANA's recommendation, or use something of their own choosing. I guess "their own choosing" could be 1024-65535. That amounts to 64512 possible ports / ~15.98 bits. Conversely, 65536 ports amounts to 16 bits. See my other replies for my questions about why BIND can't be more selective in the replies it processes. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND ignores queries from specific privileged source ports
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 sustaining traffic loop if it is not suppressed. As for the NAT box that chooses those ports. If you can’t keep the original port it should choose a ephemeral port at random. Choosing a well known port is problematic for lots of reasons. There are ~63500 ephemeral ports. Adding the well known ports into the mix of source ports doesn’t significantly improve anything. If you look at IETF documents for CGNs they say to not use the lower 1024 ports. -- Mark Andrews > On 11 Jun 2019, at 05:44, Warren Kumari wrote: > > 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 logic behind avoiding potentially problematic ports. >> >> But I don't understand the actual attack scenario. Is the attack >> against the BIND server? > > The root problem is cache poisoning -- see "The Hitchhiker’s Guide to > DNS Cache Poisoning" Section 3.2 Blind response forgery using birthday > attack ( https://www.cs.cornell.edu/~shmat/shmat_securecomm10.pdf ) > for a reasonable writeup. > It's unclear how much protection using the additional port space > actually helps in practice, but... > > There are many other mitigations, and the "right" answer is "just use DNSSEC". > > W > >> I.e. in an attempt to cause BIND to establish >> a never ending loop of packets between itself and the purported address? >> Or is this an attempt to cause BIND to attack a spoofed source with >> said loop? >> >> Nor do I understand why BIND couldn't differentiate between an actual >> query vs a reflected reply, daytime response, chargen, or time packet. >> >> Will someone please explain what I'm failing to understand? >> >> >> >> -- >> Grant. . . . >> unix || die >> >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND ignores queries from specific privileged source ports
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 logic behind avoiding potentially problematic ports. > > But I don't understand the actual attack scenario. Is the attack > against the BIND server? The root problem is cache poisoning -- see "The Hitchhiker’s Guide to DNS Cache Poisoning" Section 3.2 Blind response forgery using birthday attack ( https://www.cs.cornell.edu/~shmat/shmat_securecomm10.pdf ) for a reasonable writeup. It's unclear how much protection using the additional port space actually helps in practice, but... There are many other mitigations, and the "right" answer is "just use DNSSEC". W > I.e. in an attempt to cause BIND to establish > a never ending loop of packets between itself and the purported address? > Or is this an attempt to cause BIND to attack a spoofed source with > said loop? > > Nor do I understand why BIND couldn't differentiate between an actual > query vs a reflected reply, daytime response, chargen, or time packet. > > Will someone please explain what I'm failing to understand? > > > > -- > Grant. . . . > unix || die > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Strange DNS problem
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 Message- From: Stephane Bortzmeyer Sent: 10. kesäkuuta 2019 20:01 To: Jukka Pakkanen Cc: c...@cam.ac.uk; bind-us...@isc.org Subject: Re: Strange DNS problem 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 mismatch ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange DNS problem
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 mismatch ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Strange DNS problem
-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
>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 consistently returns server cookies that bear no relationship to the
client cookie sent in the query, and in fact I get *exactly* the same one as
you report:
>; <<>> DiG 9.14.2 <<>> @193.184.54.212 raimoasikainenoy.fi ns ; (1
>server found) ;; global options: +cmd ;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14591 ;; flags: qr
>aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; WARNING:
>recursion requested but not available
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 4096
>; COOKIE: a0ff0c014f65b471e0b8b271e7bab2718129c071 (bad)
every time! (Use +qr to show the client cookie sent by dig.)
I expect you could work around this by specifying
server 193.184.54.212 { send-cookie no; };
in your named.conf, but it seems to me that BIND 9.14 ought to be able to fall
back on using ns.kpk.fi [192.130.183.74] which doesn't have this server cookie
problem.
--
Chris Thompson
Email: c...@cam.ac.uk
Then, unfortunately our nameservers won't resolve ns.kpk.fi either. So even if
the fall back works, as I suppose it does, it does not help here.
; <<>> DiG 9.14.2 <<>> @ns1.qnet.fi ns.kpk.fi ; (1 server found) ;; global
options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64299 ;; flags: qr rd ra;
QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5fdcace005523ca0f1b0c9c95cfe96f17497773ef05635e1 (good) ;; QUESTION
SECTION:
;ns.kpk.fi. IN A
;; Query time: 0 msec
;; SERVER: 62.142.220.5#53(62.142.220.5) ;; WHEN: Mon Jun 10 20:44:17 FLE
Daylight Time 2019 ;; MSG SIZE rcvd: 66
And again when inquiring directly with the IP of ns.kpk.fi, we do get an answer:
; <<>> DiG 9.14.2 <<>> @192.130.183.74 ns.kpk.fi ; (1 server found) ;; global
options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50365 ;; flags: qr aa rd;
QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion
requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ef9a3009864a202e5dfe5cfe9648adfe8be2561def4d (good) ;; QUESTION
SECTION:
;ns.kpk.fi. IN A
;; ANSWER SECTION:
ns.kpk.fi. 600 IN A 192.130.183.74
;; Query time: 31 msec
;; SERVER: 192.130.183.74#53(192.130.183.74) ;; WHEN: Mon Jun 10 20:45:48 FLE
Daylight Time 2019 ;; MSG SIZE rcvd: 82
Jukka
Maybe because the "lue.keskipohjanmaa.com" NS server for this kpk.fi domain,
also seems to be having this cookie problem:
;; Warning: Client COOKIE mismatch
; <<>> DiG 9.14.2 <<>> @192.130.183.69 ns.kpk.fi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39629
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a0ffec004f65b471e0b8b271e7bab2718129c071 (bad)
;; QUESTION SECTION:
;ns.kpk.fi. IN A
;; ANSWER SECTION:
ns.kpk.fi. 600 IN A 192.130.183.74
;; AUTHORITY SECTION:
kpk.fi. 600 IN NS lue.keskipohjanmaa.com.
kpk.fi. 600 IN NS ns.datatower.fi.
;; ADDITIONAL SECTION:
ns.datatower.fi.3600IN A 193.184.54.212
lue.keskipohjanmaa.com. 3600IN A 192.130.183.69
;; Query time: 31 msec
;; SERVER: 192.130.183.69#53(192.130.183.69)
;; WHEN: Mon Jun 10 20:59:44 FLE Daylight Time 2019
;; MSG SIZE rcvd: 177
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Strange DNS problem
-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
>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 consistently returns server cookies that bear no relationship to the
client cookie sent in the query, and in fact I get *exactly* the same one as
you report:
>; <<>> DiG 9.14.2 <<>> @193.184.54.212 raimoasikainenoy.fi ns ; (1
>server found) ;; global options: +cmd ;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14591 ;; flags: qr
>aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; WARNING:
>recursion requested but not available
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 4096
>; COOKIE: a0ff0c014f65b471e0b8b271e7bab2718129c071 (bad)
every time! (Use +qr to show the client cookie sent by dig.)
I expect you could work around this by specifying
server 193.184.54.212 { send-cookie no; };
in your named.conf, but it seems to me that BIND 9.14 ought to be able to fall
back on using ns.kpk.fi [192.130.183.74] which doesn't have this server cookie
problem.
--
Chris Thompson
Email: c...@cam.ac.uk
Then, unfortunately our nameservers won't resolve ns.kpk.fi either. So even if
the fall back works, as I suppose it does, it does not help here.
; <<>> DiG 9.14.2 <<>> @ns1.qnet.fi ns.kpk.fi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64299
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5fdcace005523ca0f1b0c9c95cfe96f17497773ef05635e1 (good)
;; QUESTION SECTION:
;ns.kpk.fi. IN A
;; Query time: 0 msec
;; SERVER: 62.142.220.5#53(62.142.220.5)
;; WHEN: Mon Jun 10 20:44:17 FLE Daylight Time 2019
;; MSG SIZE rcvd: 66
And again when inquiring directly with the IP of ns.kpk.fi, we do get an answer:
; <<>> DiG 9.14.2 <<>> @192.130.183.74 ns.kpk.fi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50365
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ef9a3009864a202e5dfe5cfe9648adfe8be2561def4d (good)
;; QUESTION SECTION:
;ns.kpk.fi. IN A
;; ANSWER SECTION:
ns.kpk.fi. 600 IN A 192.130.183.74
;; Query time: 31 msec
;; SERVER: 192.130.183.74#53(192.130.183.74)
;; WHEN: Mon Jun 10 20:45:48 FLE Daylight Time 2019
;; MSG SIZE rcvd: 82
Jukka
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND ignores queries from specific privileged source ports
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 actual attack scenario. Is the attack against the BIND server? I.e. in an attempt to cause BIND to establish a never ending loop of packets between itself and the purported address? Or is this an attempt to cause BIND to attack a spoofed source with said loop? Nor do I understand why BIND couldn't differentiate between an actual query vs a reflected reply, daytime response, chargen, or time packet. Will someone please explain what I'm failing to understand? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND ignores queries from specific privileged source ports
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 security reasons. The motivation behind it is to add additional bits of entropy to make it harder to predict and spoof a reply. Steve Gibson has a good page with a lot of the details. At least explaining the mentality behind it. I don't have the skills to judge it. Link - DNS Nameserver Spoofability Test - https://www.grc.com/dns/dns.htm -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND ignores queries from specific privileged source ports
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 source port of protocols that are > abuse prone: Why would the original source port be close to any of these low port numbers? Source ports should normally be ephemeral ports. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange DNS problem
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 consistently returns server cookies that bear no relationship to the
client cookie sent in the query, and in fact I get *exactly* the same one as
you report:
; <<>> DiG 9.14.2 <<>> @193.184.54.212 raimoasikainenoy.fi ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14591
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a0ff0c014f65b471e0b8b271e7bab2718129c071 (bad)
every time! (Use +qr to show the client cookie sent by dig.)
I expect you could work around this by specifying
server 193.184.54.212 { send-cookie no; };
in your named.conf, but it seems to me that BIND 9.14 ought to be able to
fall back on using ns.kpk.fi [192.130.183.74] which doesn't have this server
cookie problem.
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange DNS problem
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 confirms: http://dnsviz.net/d/raimoasikainenoy.fi/dnssec/ Your tests show that it fails only when you use cookies, which is consistent with the above: > ; <<>> DiG 9.14.2 <<>> @ns1.qnet.fi raimoasikainenoy.fi ns ... > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: 55ba199a6d905273458bc2065cfe655462f150936d882603 (good) > ; <<>> DiG 9.14.2 <<>> @8.8.8.8 raimoasikainenoy.fi ns ... > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 (Bad Google, no cookies) So, they have broken authoritative name servers. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Strange DNS problem
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 to DNS queries from them. First thought it is a routing problem somewhere, but inquiring those servers with IP works, so can not be. An example, the client domain is raimoasikainenoy.fi. ; <<>> DiG 9.14.2 <<>> @ns1.qnet.fi raimoasikainenoy.fi ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15578 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 55ba199a6d905273458bc2065cfe655462f150936d882603 (good) ;; QUESTION SECTION: ;raimoasikainenoy.fi. IN NS ;; Query time: 4999 msec ;; SERVER: 62.142.220.5#53(62.142.220.5) ;; WHEN: Mon Jun 10 17:12:36 FLE Daylight Time 2019 ;; MSG SIZE rcvd: 76 >From our own providers nameservers it works however, also tested ok from a >couple other operators: ; <<>> DiG 9.14.2 <<>> @8.8.8.8 raimoasikainenoy.fi ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47848 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;raimoasikainenoy.fi. IN NS ;; ANSWER SECTION: raimoasikainenoy.fi. 3599IN NS ns.kpk.fi. raimoasikainenoy.fi. 3599IN NS ns.datatower.fi. ;; Query time: 78 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon Jun 10 17:14:11 FLE Daylight Time 2019 ;; MSG SIZE rcvd: 96 Then testing from our network again, inquiring from ns.kpk.fi or ns.datatower.fi not working, our server cannot resolve those names. But when inquiring with IP 193.184.54.212 (ns.datatower.fi): ;; Warning: Client COOKIE mismatch ; <<>> DiG 9.14.2 <<>> @193.184.54.212 raimoasikainenoy.fi ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14591 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: a0ff0c014f65b471e0b8b271e7bab2718129c071 (bad) ;; QUESTION SECTION: ;raimoasikainenoy.fi. IN NS ;; ANSWER SECTION: raimoasikainenoy.fi. 3600IN NS ns.datatower.fi. raimoasikainenoy.fi. 3600IN NS ns.kpk.fi. ;; ADDITIONAL SECTION: ns.kpk.fi. 600 IN A 192.130.183.74 ns.datatower.fi. 3600IN A 193.184.54.212 ;; Query time: 15 msec ;; SERVER: 193.184.54.212#53(193.184.54.212) ;; WHEN: Mon Jun 10 17:17:50 FLE Daylight Time 2019 ;; MSG SIZE rcvd: 156 So what can it be?? To every other operator/network our inquiries work fine, have been working 25 years :) But only to this "operator" not. Our servers cannot resolve the name of their servers, even it can do it when inquiring their servers directly by servers IP addresses. Their NS records in the fi-root look little suspicious, like some of the servers lacked glue records, but not sure about that. Jukka Pakkanen Q-Net Oy ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND ignores queries from specific privileged source ports
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 prone:
https://www.cisco.com/c/en/us/td/docs/security/asa/asa910/configuration/firewall/asa-910-firewall-config/nat-basics.html#ID-2090-0438
I don't see a configuration option within BIND to change that behavior,
just a BIND compile time option (which I probably won't change since
software and upgrades are managed via yum/apt). I will look for another
avenue to resolve this issue.
--Blake
Mark Andrews wrote on 6/7/2019 9:44 PM:
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.
static int
ns_client_dropport(in_port_t port) {
switch (port) {
case 7: /* echo */
case 13: /* daytime */
case 19: /* chargen */
case 37: /* time */
return (DROPPORT_REQUEST);
case 464: /* kpasswd */
return (DROPPORT_RESPONSE);
}
return (DROPPORT_NO);
}
On 8 Jun 2019, at 7:56 am, Blake Hudson wrote:
Can someone explain why BIND (I'm using bind-9.9.4-73.el7_6.x86_64 but have
also tried 9.10.3-P4-Ubuntu) seems to ignore DNS queries initiated from
specific privileged source ports but not others?
Example:
[root@ns ~]# dig +short -b 127.0.0.1 @localhost google.com
172.217.6.110
[root@ns ~]# dig +short -b 127.0.0.1#1 @localhost google.com
172.217.6.110
[root@ns ~]# dig +short -b 127.0.0.1#50 @localhost google.com
172.217.6.110
[root@ns ~]# dig +short -b 127.0.0.1#19 @localhost google.com
;; connection timed out; no servers could be reached
[root@ns ~]# dig +short -b 127.0.0.1#14 @localhost google.com
172.217.6.110
[root@ns ~]# dig +short -b 127.0.0.1#13 @localhost google.com
;; connection timed out; no servers could be reached
While it would be ideal for clients to use source port randomization and
initiate queries from random ephemeral ports, I don't control all the clients
or the NAT routers in between the client and the server. Queries using a source
port of 13 and 19 are dropped while queries from port 1, 50, and 14 are
answered. This has been confirmed via a network capture as well. I checked the
ARM, but didn't see what knob(s) I could tweak to control this behavior. Anyone
know?
Thanks,
--Blake
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
