listen on 5353 too?
Chuck
Massachusetts) intercepts _all_ port 53 traffic, silently reroutes
_all_ of it into their own DNS system, and munges the response packets
so they appear to come from the DNS I tried to reach even though they
really came from Verizon's internal DNS servers. It appears to me the
only way to bypass this is to use a different port number, _but_ that
requires some DNS servers to be listening on that alternate port
number as well as the standard port number.
OpenDNS has provided a way out of this Catch-22 by listening on _both_
ports 53 and 5353. Can GoogleDNS do the same?
tia!
(The Verizon "alternate" DNS to opt out of redirection of failed DNS
lookups [IP x.x.x.14 vs. x.x.x.12] is a different issue, which turns
out to be not relevant to this one. Their non-redirected DNS lookups
are "better" [they at least honestly report a failure as a failure],
but they still do not allow me to access either GoogleDNS or "raw" DNS
servers.)
(Verizon is not "blocking" anything, and so seems to escape any
possible legal restraints. There are the same number of packets, and
the packets appear the same; they just didn't really go where they
seem to have gone.)
(`traceroute` tests on this Verizon ISP network are highly misleading
[i.e. pretty much useless], because the `traceroute` packets are of
course not associated with port 53 and so take a _different_route_
than the actual DNS requests.)
Paul S. R. Chisholm
Thanks for the report, Chuck. I'm surprised to hear that you're seeing
FIOS intercept Google Public DNS queries. I checked last night (FIOS
from central New Jersey), and was able to verify that my queries went
to Google Public DNS.
We've had internal discussions of listening on additional ports. It's
hypothetically possible to do on the Google side, but very hard for a
user (even a very technically sophisticated one) to send DNS queries
to an alternate port. All hardware and almost all software we're
familiar with doesn't allow you to specify a destination port.
Hope this helps. --PSRC
Chuck
> FIOS intercept Google Public DNS queries. ...
This shouldn't be a surprise. According to old discussions (at OpenDNS
and elsewhere), _some_ Verizon networks (both DSL and FiOS) have been
intercepting all port 53 traffic off and on for at least three years.
(To confuse things further, it's often been _mis_-analyzed as
"blocking".) Assuming that all Verizon FiOS in different areas of the
country is the same is very dangerous.
> ...I checked last night (FIOS
> from central New Jersey),
Exactly how did you check? Did you just look at the packets (with
something like Wireshark)? The interception rewrites the packets so
the responses _appear_ to come from the DNS sever you were trying to
reach. The exchanged packets will look completely valid and exactly as
expected!
The _main_ valid way to test this is to ask your intended DNS server
if it just processed a query from you. (A second way that sometimes
works is if the DNS server has a special name that "lies", returning a
different result than you'd get from any other DNS server - request
that particular name and see if the "lie" was returned or not.)
> ...All hardware and almost all software we're
change). My very old BIND 8 can do it. etc. etc.
> Hope this helps. --PSRC
Unfortunately not. The background information does _not_ provide any
guidance to me on how to solve my problem.
Paul S. R. Chisholm
>
> > ... I'm surprised to hear that you're seeing
> > FIOS intercept Google Public DNS queries. ...
>
> This shouldn't be a surprise. According to old discussions (at OpenDNS
> and elsewhere), _some_ Verizon networks (both DSL and FiOS) have been
> intercepting all port 53 traffic off and on for at least three years.
> (To confuse things further, it's often been _mis_-analyzed as
> "blocking".) Assuming that all Verizon FiOS in different areas of the
> country is the same is very dangerous.
There have been other messages in this forum from FIOS users who
didn't apear to have problems. Good to know that it varies from place
to place.
> > ...I checked last night (FIOS
> > from central New Jersey),
>
> Exactly how did you check? Did you just look at the packets (with
> something like Wireshark)? The interception rewrites the packets so
> the responses _appear_ to come from the DNS sever you were trying to
> reach. The exchanged packets will look completely valid and exactly as
> expected!
Right. (If they didn't, your system wouldn't accept them.)
> The _main_ valid way to test this is to ask your intended DNS server
> if it just processed a query from you. (A second way that sometimes
> works is if the DNS server has a special name that "lies", returning a
> different result than you'd get from any other DNS server - request
> that particular name and see if the "lie" was returned or not.)
You're referring to something like OpenDNS's welcome and which/txt
queries, right?
I'm a software engineer on the Google Public DNS project, so I used
some internal tools.
> > ...All hardware and almost all software we're
> > familiar with doesn't allow you to specify a destination port.
>
> Baloney. The Microsoft DNS service can do it (probably with a registry
> change). My very old BIND 8 can do it. etc. etc.
Good to hear. Dnsmasq was the only tool I was aware of that could do
this. Are there details documented somewhere about how to do this with
various versions of BIND, etc.? (I take it you've already tried doing
this with your home network and OpenDNS?)
> > Hope this helps. --PSRC
>
> Unfortunately not. The background information does _not_ provide any
> guidance to me on how to solve my problem.
Making sure I understand your problem: Verizon is (1) intercepting
udp/53 traffic and (2) returning results different than what you'd get
if Verizon simply passed along that traffic (and the resulting
responses).
Here's why I'm concentrating on your problem: While this sounds a
long-standing issue, already discussed elsewhere, this is the first
report we've received. (Check the archives.) It might be simple to
address, it might be complicated to address (everything related to
software and networks is more complex than it seems like it ought to
be), and it might be simple for Verizon to counter. So far as I know,
a relatively small number of users could, or would, take advantage of
this feature. We simply haven't really thought about this.
Since we haven't thought about listening on alternative ports, we
currently have no plans to implement that. But we're open to feedback,
from you and others, on how valuable you'd find this feature.
Hope this starts a useful conversation. --PSRC
Nicholas Weaver
On May 15, 6:46 pm, Chuck <calvi...@gmail.com> wrote:
> I have no way to access Google DNS. My ISP (Verizon FiOS in eastern
> Massachusetts) intercepts _all_ port 53 traffic, silently reroutes
> _all_ of it into their own DNS system, and munges the response packets
> so they appear to come from the DNS I tried to reach even though they
> really came from Verizon's internal DNS servers. It appears to me the
> only way to bypass this is to use a different port number, _but_ that
> requires some DNS servers to be listening on that alternate port
> number as well as the standard port number.
device, rather than your ISP.
Netalyzr ( http://netalyzr.icsi.berkeley.edu ) has always checked for
DNS proxies which redirect the DNS request through a different server,
and we also added a recent test for in-path NXDOMAIN wildcarding.
We have observed that there are some NATs that have mandatory proxies
however, which redirect all traffic through the configured DNS server
whether you like it or not.
If you run Netalyzr ( http://netalyzr.icsi.berkeley.edu ) and email me
the results URL I may be able to help further.
Chuck
> device, rather than your ISP.
a diagnostic program that finally got to the bottom of this situation
that's been nagging me for over a year.
It now appears that although "interception" of all port 53 packets was
indeed happening, the device that was doing it was not inside the
Verizon FiOS network but rather the brouter (NATbox) that Verizon
supplied to me which is now on my own premises. (So was it Verizon or
not? Well, how many angels can dance on the heat of a pin?-)
Some NATboxes actually intercept and rewrite _all_ port 53 packets
(not just packets addressed to them). The apparent reason for this
sometimes-useful behavior is to prevent users from circumventing SOHO
network restrictions by using an alternate DNS. Unfortunately this
behavior is configured in an unwieldly variety of (sometimes
incomplete) different ways, is almost completely undocumented, and is
usually not even reflected in the internal log produced by the
brouter.
Redirecting all port 53 packets to Verizon's internal DNS servers is
the _default_ behavior of the Actiontec brouters supplied to users by
Verizon. Fortunately (but apparently by accident?-) most HowTos for
using an alternate DNS server on Verizon FiOS disable this behavior as
a side effect. However configuration of an Actiontec in this area is
complex, confusing, and very poorly documented, so any slight
deviation fron the procedure to compensate for an unusual SOHO network
configuration is likely to inadvertently leave the behavior of
redirecting all port 53 packets enabled.
(According to Nicholas some versions of some brouters even selectively
intercept and modify DNS _responses_ based on the _contents_ of
packets; in particular they change a returned NXDOMAIN to point at a
server the brouter company controls.)
(In my situation, diagnosing this was even more difficult than usual
because I happen to own _two_ NATboxes that both intercept/redirect
port 53 packets, and they are normally both used and used in series.
On one of them it's difficult to disable the undocumented port 53
redirection behavior; on the other there's no way to ever disable the
behavior at all.)
Shawn Lemay
wrote:
with 2 clients... after doing a LOT of digging and research we
determined that both Verizon and Sprint are doing this more and more
on their 3G / 4G wireless networks. It appears they're trying to
block DNS and point it to their DNS server - I suspect it is so they
can point requests to their cached web servers (if available) thus
freeing up bandwidth. So yes - I do hope that you will PLEASE open
alternate ports up to allow us to bypass this. Thanks!