Re: Peculiar DNS queries
Am 22.12.19 um 18:28 schrieb Paul Kosinski via bind-users: > Every so often, we get a run of peculiar queries to our (BIND / named) > DNS server. Note the apparently random mix of lower case and upper case > letters in the domain names. > > Does anybody have any idea why somebody would be doing this? (It's > legal, I guess, but quite non-standard.) > > Dec 22 12:05:43 iment0 named[10333]: client 134.0.217.68#20012 > (Www.IMent.coM): query: Www.IMent.coM IN -E (216.55.100.246) > > Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.54#53150 > (Www.iMent.Com): query: Www.iMent.Com IN -E (216.55.100.246) > > Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.53#27016 > (WWw.imENT.cOm): query: WWw.imENT.cOm IN A -E (216.55.100.245) > > Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.69#23417 > (WWw.IMeNt.cOM): query: WWw.IMeNt.cOM IN A -E (216.55.100.245) because it#s some idiotic bot, typical network noise [harry@srv-rhsoft:~]$ whois 216.55.100.246 NetRange: 216.55.96.0 - 216.55.111.255 CIDR: 216.55.96.0/20 NetName:SMSV-BLK-1 NetHandle: NET-216-55-96-0-1 Parent: NET216 (NET-216-0-0-0-0) NetType:Direct Allocation OriginAS: Organization: Smart Servers (SMSV) ___ 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: Peculiar DNS queries
This is a “spoofing resistance” technique. For more info, check “0x20 Bit Encoding”. Sent from my iPhone > On 22-Dec-2019, at 10:59 PM, bind-users@lists.isc.org wrote: > > Every so often, we get a run of peculiar queries to our (BIND / named) > DNS server. Note the apparently random mix of lower case and upper case > letters in the domain names. > > Does anybody have any idea why somebody would be doing this? (It's > legal, I guess, but quite non-standard.) > > Dec 22 12:05:43 iment0 named[10333]: client 134.0.217.68#20012 > (Www.IMent.coM): query: Www.IMent.coM IN -E (216.55.100.246) > > Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.54#53150 > (Www.iMent.Com): query: Www.iMent.Com IN -E (216.55.100.246) > > Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.53#27016 > (WWw.imENT.cOm): query: WWw.imENT.cOm IN A -E (216.55.100.245) > > Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.69#23417 > (WWw.IMeNt.cOM): query: WWw.IMeNt.cOM IN A -E (216.55.100.245) > > Thanks, > Paul Kosinski > ___ > 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 Disclaimer: This e-mail and its attachments may contain official Indian Government information. If you are not the intended recipient, please notify the sender immediately and delete this e-mail. Any dissemination or use of this information by a person other than the intended recipient is unauthorized. The responsibility lies with the recipient to check this email and any attachment for the presence of viruses. ___ 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: Peculiar DNS queries
Sent from my iPhone > On 22-Dec-2019, at 11:02 PM, h.rei...@thelounge.net wrote: > > > >> Am 22.12.19 um 18:28 schrieb Paul Kosinski via bind-users: >> Every so often, we get a run of peculiar queries to our (BIND / named) >> DNS server. Note the apparently random mix of lower case and upper case >> letters in the domain names. >> >> Does anybody have any idea why somebody would be doing this? (It's >> legal, I guess, but quite non-standard.) >> >> Dec 22 12:05:43 iment0 named[10333]: client 134.0.217.68#20012 >> (Www.IMent.coM): query: Www.IMent.coM IN -E (216.55.100.246) >> >> Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.54#53150 >> (Www.iMent.Com): query: Www.iMent.Com IN -E (216.55.100.246) >> >> Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.53#27016 >> (WWw.imENT.cOm): query: WWw.imENT.cOm IN A -E (216.55.100.245) >> >> Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.69#23417 >> (WWw.IMeNt.cOM): query: WWw.IMeNt.cOM IN A -E (216.55.100.245) > > because it#s some idiotic bot, typical network noise > No. Not because of Bot. It’s a technique to provide additional “spoof detection” capabilities to the DNS service. > [harry@srv-rhsoft:~]$ whois 216.55.100.246 > NetRange: 216.55.96.0 - 216.55.111.255 > CIDR: 216.55.96.0/20 > NetName:SMSV-BLK-1 > NetHandle: NET-216-55-96-0-1 > Parent: NET216 (NET-216-0-0-0-0) > NetType:Direct Allocation > OriginAS: > Organization: Smart Servers (SMSV) > ___ > 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 Disclaimer: This e-mail and its attachments may contain official Indian Government information. If you are not the intended recipient, please notify the sender immediately and delete this e-mail. Any dissemination or use of this information by a person other than the intended recipient is unauthorized. The responsibility lies with the recipient to check this email and any attachment for the presence of viruses. ___ 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: Peculiar DNS queries
On Sunday, December 22th 2019, 18:28:48 CET schrieb Paul Kosinski via bind- users: > Every so often, we get a run of peculiar queries to our (BIND / named) > DNS server. Note the apparently random mix of lower case and upper case > letters in the domain names. > > Does anybody have any idea why somebody would be doing this? (It's > legal, I guess, but quite non-standard.) > > Dec 22 12:05:43 iment0 named[10333]: client 134.0.217.68#20012 > (Www.IMent.coM): query: Www.IMent.coM IN -E (216.55.100.246) [...] On Sunday, December 22th 2019, 18:41:27 CET schrieb Gaurav Kansal via bind- users: > This is a “spoofing resistance” technique. > For more info, check “0x20 Bit Encoding”. Hello Paul, for more information about this see https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 and https://indico.dns-oarc.net/event/20/contributions/265/attachments/254/471/ ISC-case-sensitivity.pdf I at first wondered about this, too. ;-) But it's a technology to add addition entropy to the DNS communication (to prevent cache poisoning based on spoofed answers), especially for the case the authoritative Server doesn't support DNS Cookies. Kind regards, Lars -- Lars Kollstedt Telefon: +49 6151 16-71027 E-Mail: l...@man-da.de man-da.de GmbH Dolivostraße 11 64293 Darmstadt Sitz der Gesellschaft: Darmstadt Amtsgericht Darmstadt, HRB 9484 Geschäftsführer: Andreas Ebert ___ 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: Peculiar DNS queries
Regarding entropy, that is correct. Regarding case, in any case (pardon
the pun) case is not guaranteed. Especially regarding dynamic updates,
your case will not be preserved (and maybe I fat-fingered and left caps
lock on once upon a time without realizing it) in the authoritative zone.
The mixed (within a label) case queries seem to be an artifact of entropy
preservation, but in cache e.g. isc.org matches ISC.ORG or isc.ORG, or
ISC.org... hopefully you get the idea.
I ran into a transient problem last summer with case sensitivity in SuSE
Leap, hasn't come back but my best guess is something to do with NSCD.
There is a tension between the protocol ("any octet") vs what you can
register ("valid hostnames") vs what's sent to the public DNS ("case
insensitive").
--
Fred Morris
___
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: Peculiar DNS queries
Hi Fred, On Montag, 23. Dezember 2019 01:08:54 CET Fred Morris wrote: > but in cache e.g. isc.org matches ISC.ORG or isc.ORG, or > ISC.org... hopefully you get the idea. Thats expected behavior. And has IMHO something to do with https://tools.ietf.org/html/rfc4343 and the elder DNS RFCs not with dnsext-dns0x20 but the implementations of the case insensitivity in the public DNS were much older. The dnsext-dns0x20 uses the previously present behavior of many implementations to echo back the character case of the request in the reply but matching case insensitive. If it gets anything else and no DNS Cookie back the resolver will wait a short while for a better matching answer, and then give the non matching back. That's at least my reading of this. The matching in the cache is still done case insensitive, and the character case is re randomized on each resolver and DNS Client supporting this. As far as i've seen some client libraries are leaking the camel case back, which might cause problems. But that's a problem between the library and the application using it and can be fixed in both. dnsext-dns0x20 addresses recent spoofing problems on well connected resolvers since the source port randomization doesn't provide enough entropy for them and the attacks were already seen in the wild. If your client application is really asking in lowercase it still will get lowercase back. So you can ask for WwW.iSC.oRg and you will get an answer for WwW.iSC.oRg back with the same result as for www.isc.org or WWW.ISC.ORG. But if a library gets a query for www.isc.org from the application it's used by and is randomizing this e.g. to WwW.iSC.oRg it should hopefully return a result for www.isc.org again. Other behavior might break things. ;-) Kind regards Lars -- Lars Kollstedt Telefon: +49 6151 16-71027 E-Mail: l...@man-da.de man-da.de GmbH Dolivostraße 11 64293 Darmstadt Sitz der Gesellschaft: Darmstadt Amtsgericht Darmstadt, HRB 9484 Geschäftsführer: Andreas Ebert ___ 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: Peculiar DNS queries
Lars Kollstedt wrote: > > for more information about this see > > https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 > > and > > https://indico.dns-oarc.net/event/20/contributions/265/attachments/254/471/ISC-case-sensitivity.pdf Yes. And one prominent resolver that implements this is unbound: see `use-caps-for-id` at https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/ Tony. -- f.anthony.n.finchhttp://dotat.at/ Fair Isle: Northwest 6 to gale 8, backing southwest 5 to 7. Rough or very rough. Showers at first. Good. ___ 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: Peculiar DNS queries
Fred Morris wrote: > Regarding case, in any case (pardon the pun) case is not guaranteed. > Especially regarding dynamic updates, your case will not be preserved > (and maybe I fat-fingered and left caps lock on once upon a time without > realizing it) in the authoritative zone. Well, it's a bit more complicated than that, I'm afraid! The case that you use in zone files and UPDATEs should be preserved on disk and (I think?) through zone transfers, but not necessarily in answers to queries. The link that Lars Kollstedt posted (repeated below) explains that BIND is now by default stricter at preserving case than it used to be, in answers to queries as well as other authoritative data operations. https://indico.dns-oarc.net/event/20/contributions/265/attachments/254/471/ISC-case-sensitivity.pdf There is a `no-case-compress` ACL that you can use to revert to the old behaviour. https://ftp.isc.org/isc/bind9/9.15.7/doc/arm/Bv9ARM.ch05.html It's very difficult to make the DNS properly case-preserving, because a parent zone and a child zone can disagree with each other about the case of the parent zone. It's not as easy as it used to be to observe this in the wild because lower case is nearly universal, but (for example) if you have a time machine you can observe that the root zone was all upper case before it was signed in 2010. Tony. -- f.anthony.n.finchhttp://dotat.at/ North Rockall, Malin: Northwesterly 4 or 5, backing southerly 5 to 7 later. Rough. Fair. Good. ___ 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: Peculiar DNS queries
Hi Tony, on Monday, 30. Dezember 2019, 20:10:57 CET Tony Finch wrote: > It's very difficult to make the DNS properly case-preserving, because a > parent zone and a child zone can disagree with each other about the case > of the parent zone. dnsext-dns0x20-00 doesn't have anything to do with zones. If it's completely implemented each query has a different camel case. All caching an all comparisons are still done lowercase according to RFC4343. e.g. with fully implemented dnsext-dns0x20-00 Client application on client1 comes wish to resolve the IPv4 Adress of www.iment.com. client1 asks resolver1 for Www.IMent.coM IN A The Autoritative NS RRs of com are already cached, to shorten this a bit. ;-) resolver1 asks Autoritative of the com-Zone for ImenT.Com or wWw.ImenT.Com resolver1 gets ImenT.com IN NS ns-b.ImenT.Com and ns-a.ImenT.Com back. resolver1 writes both RRs in lowercase to it's cache. resolver1 asks ns-b.iment.com for wwW.imEnT.cOM IN A It gets wwW.imEnT.cOM IN A 216.55.100.245 back It writes it in lowercase to its cache (www.iment.com) client1 gets Www.IMent.coM IN A 216.55.100.245 back from resolver1 In the client application this is handled as answer for www.iment.com. There are probably some authoriatatives that don't implement RFC4343 correctly. In this case you will get the case from the zone back and resolver1 will wait for a better answer if the spoofing protection isn't provided via other mechanisms (DNS cookies or DNSSEC). And there are some more or less common authoritatives that implement RFC4343 by answering always in lowercase until dnsext-dns0x20-00 was implemented. If a resolver dosn't implement dnsext-dns0x20-00, implementing dnsext- dns0x20-00 in the client application doesn't have any security effect, since many of the client applications will ask in lowercase. And even if they wouldn't the security effect by is gone if the attacker can do queries and choose the case the resolver queries. Some resolvers not implementing dnsext- dns0x20-00 will also converted queries to lowercase when forwarded to the authoritative. If the answer on a dnsext-dns0x20-00 query is done in lowercase and spoofing protection is not provided via other mechanisms there will be also a delay. We're talking about Resolving here. Not about AXFR (between autoritiatives) and not about DNS UPDATE specified by RFC2136 (to dynamically update information on authoritatives). dnsext-dns0x20-00 can't be used for securing DNS UPDATE, since the sensitive information goes in the opposite direction there. Kind regards Lars -- Lars Kollstedt Telefon: +49 6151 16-71027 E-Mail: l...@man-da.de man-da.de GmbH Dolivostraße 11 64293 Darmstadt Sitz der Gesellschaft: Darmstadt Amtsgericht Darmstadt, HRB 9484 Geschäftsführer: Andreas Ebert ___ 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: Peculiar DNS queries
Hi, some additions. on Monday, 30. December 2019, 23:48:41 CET I wrote: > resolver1 asks Autoritative of the com-Zone for ImenT.Com or wWw.ImenT.Com There are two ways for a resolver to behave. The slower way which is leaking less information to the highest levels of the authoritatives is to ask for NS records on each dot in the name, and only to ask the most specific authoritative for the real query. The many dots in ip6.arpa are massively slowing this down, but also DNSSEC will require lots of queries in this case. If this way to ask is used and a FQHN contains a deep hierarchy which is done to be able to delegate but not all dots are real delegations at the time of the query, it will be slowed down by this strategy. The other way is to always forward the orignal query. So the query to e.g. to g.gtld-servers.net (one of the com authoritatives) can be ImenT.Com IN NS or wWw.ImenT.Com IN A Both will be answered with a NS RR for ImenT.Com. Which strategy is used strongly depends on the used resolver software and configuration. They can be also mixed in different ways, e.g. asking for NS RRs in the first levels. [...] > client1 gets Www.IMent.coM IN A 216.55.100.245 back from resolver1 If client2 asks for www.IMEnT.CoM within the TTL of the A RR it will get an answer for www.IMEnT.CoM, but resolver1 will not ask the autoritatives for that again. Thats (without the camelcase) how DNS caching already works for decades, and that's what can be attacked when there isn't enough entropy in the query. If the Resolver is connected with 10Gb/s or more the randomization of the source port is definitely not enough. The clue of dnsext-dns0x20-00 is that it can be used against most of the most common implementations of authoritative dns without needing them to be adopted for that. And it only produces some log lines the people operating them are wondering about there. ;-) Only the Resolver that is kind of well connected needs to run a software version that implements dnsext-dns0x20-00 to be more secure by that. Until the end of the 90s DNS-Queries were done with source and destination port 53. Then the source port randomization was implemented. That's now not enough any more, and attacks were already seen in the wild. This is adressed by DNS cookies and dnsext-dns0x20-00, they are both (like the sourceport randomization) not protecting against real MitM attacks, but against spoofed UDP answers in large amounts. DNS cookies must be implemented on both ends, and there were authoritatives that were needing exceptions, because they didn't answer queries with DNS cookies. Hope this makes clear what the dnsext-dns0x20-00 is for. If you need a real MitM proof DNS, all stakeholders relevant for you will have to do DNSSEC. But NSEC and NSEC3 (the proof of nonexistence) is probably a bit like choosing between pest and cholera. NSEC can't be spoofed in any way but allows to walk the zone. NSEC3 will be possibly/probably weak for being replayed in a real MitM scenario, since the answer can be only checked for plausibility, since the signatures are done over non revertable hashes without disclosing the data the hashes are generated from. On Mondagy, 30. December 2019, 19:54:13 CET Tony Finch wrote: > Yes. And one prominent resolver that implements this is unbound Not only unbound does. ;-) On Montag, 30. December 2019, 20:10:57 CET Tony Finch wrote: > Well, it's a bit more complicated than that, I'm afraid! The case that you > use in zone files and UPDATEs should be preserved on disk and (I think?) > through zone transfers, but not necessarily in answers to queries. I at first misread the context of this. :-( Fred is of course talking about DNS Update, and a least BIND is cleanly implementing the case insensitivity for for DNS answers for many years. But in the AXFR Data of BIND (9.10.3) and probably also on disk the character case of an upper case character in the zone file is really preserved. Might be that also happens with DNS Update. I'm not really sure that is useful. ;-) But the NSCD stuff he also mentioned sometimes also uses other non DNS mechanisms like mDNS, NIS+ or /etc/hosts as far as I remember. NIS+ and at least some versions and parts of /etc/hosts tooling are really case sensitive. Kind regards, Lars -- Lars Kollstedt Telefon: +49 6151 16-71027 E-Mail: l...@man-da.de man-da.de GmbH Dolivostraße 11 64293 Darmstadt Sitz der Gesellschaft: Darmstadt Amtsgericht Darmstadt, HRB 9484 Geschäftsführer: Andreas Ebert ___ 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
