Secure DNS 156.154.112.36

Comodo Internet Security - CIS Firewall Help - CIS
#1

I use secure dns from Comodo (156.154.70/71.22). I noticed that there is an echo request sent out to 156.154.112.36 . Can anybody please explain.

Kind Regards,
Eric-Jan.

#2

Hoi Eric-Jan,

Can you please explain a bit more about what’s happening?
How did you notice this and can you reproduce this behavior?

#3

I think I figured it out. When I revert to my ISP’s DNS server and flush my dns cache (Ipconfig /FLUSHDNS), entering 156.154.112.36 in my browser comes up with the “BLOCKED” page from Comodo Secure DNS. To remind you: no Secure DNS in effect and still the “BLOCKED” page; very puzzling.

“BLOCKED” page:
(http://securedns.Comodo.com/main?InterceptSource=0&ClientLocation=xx&ParticipantID=xxxxxxxxl&FailureMode=9&SearchQuery=&FailedURI=http%3A%2F%2F156.154.112.36%2F&AddInType=2&Version=3.0.4&Referer=&Implementation=0&PlatformInfo=DNSA&msgID1=13&blockedDomain=).

So I suspect 156.154.112.36 is Secure DNS’s black hole, where anything not registered in Comodo’s DNS will vanish.

With Secure DNS from Comodo in place, the process that pings 156.154.112.36 is an svchost instance (Source: CIS log; would be nice if CIS log contained the PID, since there are many instances of svchost). I tracked it down to the svchost instance that also hosts the “DNS client” service (Source: Procmon by Sysinternals/M$ now).

So there seems a mechanism that when Secure DNS is in place the “DNS client” service is triggered to ping 156.154.112.36. Would be nice if someone can explain what the purpose of this supposed mechanism is.

Just a thought of me: CIS is aware of Secure DNS and assures that there is no reply from the black hole, since that could point to tampering. Question: Is CIS aware of Secure DNS in place, and does it take some supplementary actions.

I will try further analysis with Procmon.

Kind Regards,
Eric-Jan,
The Netherlands.

#4

Dat dacht ik al, welkom :wink:

Do you happen to run Wireshark also? I’d like to be sure that it’s type 8/0 echo request and what’s in the data packet.

And does this same behavior occur after a reboot when you change the DNS settings?

#5

Hallo Ronny. (waarom dacht jij dat al)

I did not use Wireshark. If I recollect there are problems in running Wireshark within Vista. But CIS’s log indicated that it was Type( 8 ) Code( 0 ). Since it is ICMP it carries no data as far as I know.

Behavior also persists after reboot with Secure DNS from Comodo in place.

Regards EJ.

#6

Welkom op de Comodo Forums. Eric-Jan gives it away.

#7

If anyone knows its you. Was afraid my horrible English gave it away.

#8

Name + Mod power ;D

I did not use Wireshark. If I recollect there are problems in running Wireshark within Vista. But CIS's log indicated that it was Type( 8 ) Code( 0 ). Since it is ICMP it carries no data as far as I know.

Behavior also persists after reboot with Secure DNS from Comodo in place.

Regards EJ.


I suspect some kind of “is the configured DNS server still reachable” icmp packet.
Maybe related to Path MTU discovery, Windows also likes to determine the network performance based on icmp packets…

Does it still ping if you remove the Secure DNS and reboot?
Does this ping also happen if you configure Google DNS on 8.8.8.8?

I don’t have issues with Wireshark on Win7 but I’m not sure about issues on Vista.

#9

156.154.112.36 (mistakenly forgot the leading 1 in my initial post) is not the IP for the secure DNS servers from Comodo these are 156.154.70/71.22. Reverting to non Secure DNS stops the ping.

#10

You can try Network Monitor from Microsoft that also displays the process that initiates the connection.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&pf=true

The IP belongs to the hosting provider that hosts Secure DNS.