Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: Odd DNS replies from 10 nets and RFC1323 impacting firewalls - SANS Internet Storm Center SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Odd DNS replies from 10 nets and RFC1323 impacting firewalls

 Reader Bob wrote in reporting seeing increasingly frequent incoming DNS replies on UDP 53, with valid DNS answers, but coming from source addresses in the 10.x.x.x/8 range. The responses appear to be from the Internet Roots to DNS servers that are querying the root.

Anyone else see this kind of behavior?

Over the past week another couple of readers have written in reporting issues accessing the ISC web page. The SANS NOC reports that RFC-1323 timestamps were getting scrubbed by our firewall to prevent information disclosure, but the checksum wasn't being updated.  The packet was subsequently dropped by the end device.

This appears to be impacting users using Bluecoat web proxies. We will have more to post on this topic throughout the day.

Handler Internet Storm Center


42 Posts
May 15th 2012
"It is interesting to note that Windows implemented these options in Windows 2000, but did not enable them by default until Windows 2008."

It seems a sensible treatment of the new feature, which was a relatively new standard in 2000, and as ISC apparently found, can unfortunately cause connectivity issues, due to old, broken firewalls. Let admins experiment for a few years, and report issues in new protocol features.

Made sense to wait until a later release before turning it on by default, at a time, when few organizations had networks of high enough speed to benefit from the feature.

But hey, in 2008... 15 years later.
No implementation really has a good excuse at this point to not have correctly implemented or at least inter operate with newer features required by the standard.


146 Posts
These replies are usually a duplicated response, the first coming from the legit authority name server's public address, and then immediately (as in next packet) followed by the same answer but this time, from a private ranged address.

Notably, they are all from a large dns hoster, oddly, the second and third octets of the public and the private addresses match up. Example, the public ip response comes from XX.17.144.XXX and the privately sourced address is (the last octet and first don't appear to be related).

A little too uncanny?

7 Posts
BTW, additional info, ISP claims to not be doing anything to DNS packets--could it be my firewall (Juniper SSG series) lousing things up?

7 Posts
Two questions:
(1) why in the world would anybody accept 10-net traffic from the Internet in the first place? But, as this assumes a well-managed firewall,
(2) why isn't 10-net traffic being filtered by the ISP at their boundaries?
John Hardin

62 Posts
We came across this problem several months back with our Bluecoat proxies and spoke to your NOC about it. We were forced to implement the fix mentioned in the Bluecoat KB. Do you know if SANS is planing on modifying their firewall to allow the timestamps? I ask because the setting on the Bluecoat is global...
BTW -- what is the security benefit to scrubbing the RFC-1323 timestamps? It seems to me that without it, a lot of TCP traffic could break.
John Hardin
1 Posts
The SANS firewall will no longer scrub timestamps. The security benefit (if any) is minimal. There is some benefit outbound as the timestamp may indicate the time of last reboot. But it is better just turned off at the source vs. having the firewall mess with the packets.

4467 Posts
ISC Handler
In RE: 10.x source DNS replies:
Definitely not accepting the packets. Rather, I was alerted to the presence via an intrusion/spoof alarm. As for ISPs not blocking private range sourced packets--in my experience, with a full service internet connection, I expect that the ISP is not doing any filtering--in almost all cases where I've had an ISP doing some 'for your better interest' filtering, something else is impacted eventually. Routes are typically destination based, and with a valid destination, an L3 router would usually pass them. We do use some policy based routing within some of our internal networks, where source address is inspected, but I'd imagine not many providers do? Given, though, with a private or unrouted source address, the return packets would never get back if an ack or otherwise was required--as a threat condition, I'd guess that unless the destination target was a connectionless transaction, that they'd never survive. This does pose an interesting possibility for DNS poisoning though, especially if a NATing firewall wasn't in use.

7 Posts

Sign Up for Free or Log In to start participating in the conversation!