Re: Shaw is pissing me off

[Dan Brosemer <odin@svartalfheim.net>]

On Fri, Jun 07, 2002 at 12:35:56PM -0400, Lynham, Tim wrote:
> I don't understand the implications of all the info in your email.  I talked
> to Shaw.  They have not changed the IP, so they say.  Are you saying they
> changed the IP?

No.

> They say the problem is with the DNS host (is that Soonet?)  Shaw said that

No, it's not.  Soonet doesn't enter into it (as you will see).

> Shaw's ops would not affect the A record; only the DNS host would affect the
> A record.  Shaw checked all the SSM business customers in the CN area on
> that date & time.  None off them have complaints nor do the Shaw records
> show any interruption.  Their records only show the interrruption of a few
> months ago at the CN site when they changed the IP address.

We're not business customers, remember?

Here:
root@sabe:p2[/etc/mail]# grep forward /var/named/named.boot
forwarders 192.168.1.1
root@sabe:p2[/etc/mail]# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> check_mail foo@onlink.net
check_mail         input: foo @ onlink . net
Basic_check_mail   input: foo @ onlink . net
tls_client         input: $| MAIL
TLS_connection     input:
TLS_connection   returns:
tls_client       returns:
CanonAddr          input: < foo @ onlink . net >
canonify           input: < foo @ onlink . net >
Canonify2          input: foo < @ onlink . net >
Canonify2        returns: foo < @ onlink . net . >
canonify         returns: foo < @ onlink . net . >
Parse0             input: foo < @ onlink . net . >
Parse0           returns: foo < @ onlink . net . >
CanonAddr        returns: foo < @ onlink . net . >
Basic_check_mail returns: < OKR >
check_mail       returns: < OKR >

If we tell our DNS server to forward requests out our VPN to my machine in
Waterloo (Shaw can't modify data in esp packets, and that's what we're
encapsulating in here) everything comes back unharmed.  We decide that
onlin.net is, in fact, a valid domain and we will accept mail from them.
However:

root@sabe:p2[/etc/mail]# !gre
grep forward /var/named/named.boot
forwarders 207.6.128.247
;forwarders 192.168.1.1
root@sabe:p2[/etc/mail]# !sendm
sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> check_mail foo@onlink.net
check_mail         input: foo @ onlink . net
Basic_check_mail   input: foo @ onlink . net
tls_client         input: $| MAIL
TLS_connection     input:
TLS_connection   returns:
tls_client       returns:
CanonAddr          input: < foo @ onlink . net >
canonify           input: < foo @ onlink . net >
Canonify2          input: foo < @ onlink . net >
onlink.net: Name server timeout
Canonify2        returns: foo < @ onlink . net >
canonify         returns: foo < @ onlink . net >
Parse0             input: foo < @ onlink . net >
Parse0           returns: foo < @ onlink . net >
CanonAddr        returns: foo < @ onlink . net >
onlink.net: Name server timeout
Basic_check_mail returns: $# error $@ 4 . 1 . 8 $: "451 Domain of sender
address " " does not resolve"
check_mail       returns: $# error $@ 4 . 1 . 8 $: "451 Domain of sender
address " " does not resolve"
== Ruleset check_mail (189) status 75

If we forward to an OpenNIC DNS server, we get timeouts... why?  This is the
same DNS server that the 192.168.1.1 machine forwards to (remembering that
192.168.1.1 is on a different network, in Waterloo).  Also:

root@sabe:p2[/etc/mail]# host -t any onlink.net
onlink.net              SOA     onlink1.onlink.net dnsadmin.onlink.net (
                        2002060702      ;serial (version)
                        10800   ;refresh period (3 hours)
                        3600    ;retry interval (1 hour)
                        648000  ;expire time (1 week, 12 hours)
                        3600    ;default ttl (1 hour)
                        )
onlink.net              NS      onlink1.onlink.net
onlink.net              NS      onlink2.onlink.net
onlink.net              MX      10 mail.onlink.net

We _can_ get records back for it when we're set up to use this server... so
what's not getting back to us???

Well, we have to go to tcpdump for that.

During the lookups using my host in waterloo, we get:
12:54:16.115135 192.168.16.2.53 > 192.168.1.1.53:  38573+ AAAA? onlink.net. (28)
12:54:16.196525 192.168.1.1.53 > 192.168.16.2.53:  38573 0/1/0 (81)
12:54:16.198022 192.168.16.2.53 > 192.168.1.1.53:  52555+ A? onlink.net. (28)
12:54:16.309761 192.168.1.1.53 > 192.168.16.2.53:  52555 0/1/0 (81)
12:54:16.310926 192.168.16.2.53 > 192.168.1.1.53:  56763+ MX? onlink.net. (28)
12:54:16.394177 192.168.1.1.53 > 192.168.16.2.53:  56763 1/2/3 MX mail.onlink.net. 10 (141)

As you can see, we ask for an AAAA record (ipv6 address record) and the
server returns 0 answers/1 name server/0 authority records (that's the
0/1/0)
So we ask for an A record and get the same response.
So we ask for an MX record and get 1 answer.  Great, we'll accept the mail.

Now, during the lookups directly to the DNS server we want to use (instead
of tunneling outside of Shaw's network in esp packets first), we get:
12:55:24.382046 192.168.16.2.53 > 207.6.128.247.53:  62772+ AAAA? onlink.net. (28)
12:55:24.442739 207.6.128.247.53 > 192.168.16.2.53:  62772 0/1/0 (81)
12:55:24.444298 192.168.16.2.53 > 207.6.128.247.53:  62385+ A? onlink.net. (28)
[Snipped 34 requests to the same server]
12:56:43.564354 192.168.16.2.53 > 207.6.128.247.53:  48133+ A? onlink.net. (28)

As you can see, we never get the query response back saying there are no A
records.  Why?  That response gets back to my server in waterloo (which
forwards them on to my server in SSM), but if I query the 207.6.128.247
server directly from SSM, it never sees the name server responses!

So while, no, they don't modify the content of the DNS, they do prevent
vital information from getting to us from name servers not on their network.
It should be noted I've tried this using:

24.207.26.101, and 144.162.120.230 for forwarders as well, and I've tried
going right to the ICANN servers:

cache   .   root.cache

In none of those cases does the 0/1/0 get back to us when we ask for an A
record.

Domains this has affected us with:
adsb.on.ca
ec.gc.ca
gosympatico.ca
inkindcanada.ca
olgc.on.ca
onlink.net
optinunlimited.com
saultc.on.ca

Don't let them tell you they're not doing anything, but what they're doing
is subtle.  They're blocking (very necessary) DNS query responses.  That, or
they're blocking the query in the first place without returning anything
(that would prevent the response from getting back because the other server
wouldn't know it has anything to respond to).

Thanks for your help.  I really expected you to ask me for this info before
you called them, though, if you were going to call them.

-Dan

-- 
"Burnished gallows set with red
 Caress the fevered, empty mind
 Of man who hangs bloodied and blind
 To reach for wisdom, not for bread."  -- Deoridhe Grimsdaughter