full-disclosure - FW: Question for DNS pros

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <411068B3.7040601@mchsi.com>
From: fd at mchsi.com (Mark)
Subject: FW: Question for DNS pros

John Hall wrote:

> 
> Responses in-line...
> 
> Frank Knobbe wrote:
> 
>> Hello John,
>>
>> glad to see you guys are keeping up with all the current stuff going on
>> in lists ;)
>>
>> I had sent a dump earlier. It is attached again below. The TCP SYN
>> packets do indeed start with IPID 1 and move up to 3. 

Yup, the TCP SYN packets I see do the same with the IPID.  (Embarrassed 
I missed that the first time I looked at them.) ;)

>>However, these all
>> come from the same IP address. Also, there doesn't appear to be anything
>> in regards to "round-trip". I mean, your devices send the SYN's but
>> nothing is coming back. Are you expecting DNS querying device to have an
>> open DNS port on TCP and are expecting a SYN-ACK?  
>>
> No, but most DNS servers *will* respond with a RST which is just as
> valuable for reachability and RTT measurements.  We accept either
> response.

I disagree, if it is a DNS *server* I would think it wouldn't respond 
with a RST.  It would respond with a SERV FAIL because it's not 
authoritative for that domain.

> 
>> That I can understand. But what the heck is the purpose of performing
>> two DNS queries against the host that is querying a 3DNS balanced
>> server? Seems a bit invasive to me for measuring trip time... :)
>>  

Agreed Frank, why would they bother asking in the first place?  How do 
you even know you are asking a DNS server?  It could just be a 
mis-configured client.  It would seem to me that would only provide you 
with the quickest way to query what may or may not be a DNS server that 
may or may not be authoritative for a domain.

>>
> In general, most sites use local forwarding DNS servers that do the
> recursive lookups for all the clients at that site, so our probes
> measure the RTT from each datacenter to that forwarding DNS server
> and maintain that data so we can make intelligent decisions the next
> time a client from that site (via that local forwarder) makes a request.
> 
>> In any case. I'm glad to see that there is a normal explanation for
>> this, and this does not appear to be an attack mounted by China.

Although I think we may have resolved the issue of what is causing those 
strange packets...   I would like to see a whitepaper or something 
describing how this technique improves the performance of, well; anything.

The above paragraph is off topic.  E-Mail me off list if you want to 
discuss that topic further.

Regards,
Mark