[nSLUG] resolving bellaliant.net while on fibreop

D G Teed donald.teed at gmail.com
Wed Aug 19 23:15:27 ADT 2015


On Wed, Aug 19, 2015 at 7:29 PM, Robert McKay <robert at mckay.com> wrote:
> On 2015-08-19 19:31, D G Teed wrote:
>>
>> Perhaps I'm flagged for running nmap for open telnet ports against network
>> IP
>> ranges similar to my IP.
>
>
> Have you tried querying the other bellaliant.net nameservers;
> dns-nb00.aliant.net (198.164.30.2) or dns-nb01.aliant.net (198.164.4.2) ?

Both behave the same for me w.r.t. lookup using the DNS on the router (works)
and DNS client on Windows or Linux, using the local bind (fails).

> Do those also not work behind NAT?
> Any difference querying using TCP instead of UDP?

host -T bellaliant.ca 192.168.0.3
;; connection timed out; no servers could be reached


dig +tcp +bufsize=4096 @192.168.0.3 sobeys.ca A

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +tcp +bufsize=4096 @192.168.0.3
sobeys.ca A
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Both of above work if @192.168.0.1 the Asus router is used.

> If queries work from the router itself I think it's unlikely to be aliant
> blocking you.. sure it could be, but they'd have to be using some very
> strange criteria (ie, ttl or maybe high NAT source ports?).. I think it's
> far more likely to be something on your end tbh.
>
> The traceroute you showed not getting to the destination is probably a
> red-herring.. the nameserver just doesn't reply to the traceroute probes so
> what you are seeing there is normal.
>
> Try it with tcptraceroute instead.. tcp should acknowledge (syn/ack) and the
> traceroute will complete.. wereas with udp it just sends a probe to the dns
> server and gets ignored.

Tried with and without port 53...

# tcptraceroute 198.164.4.2
traceroute to 198.164.4.2 (198.164.4.2), 30 hops max, 60 byte packets
 1  clark.localdomain.domain (192.168.0.1)  0.530 ms  0.659 ms  0.766 ms
 2  loop0.6cw.ba17.hlfx.ns.aliant.net (142.176.50.10)  13.124 ms *  13.202 ms
 3  irb-84.cr02.hlfx.ns.aliant.net (142.176.53.49)  10.479 ms
ae2-83.cr02.hlfx.ns.aliant.net (142.176.53.33)  10.661 ms
irb-84.cr02.hlfx.ns.aliant.net (142.176.53.49)  10.585 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
... (to 30 hops)

# tcptraceroute -p 53 198.164.4.2
traceroute to 198.164.4.2 (198.164.4.2), 30 hops max, 60 byte packets
 1  router.asus.com (192.168.0.1)  0.318 ms  0.287 ms  0.256 ms
 2  loop0.6cw.ba17.hlfx.ns.aliant.net (142.176.50.10)  8.929 ms  8.011 ms *
 3  irb-84.cr02.hlfx.ns.aliant.net (142.176.53.49)  9.088 ms *  11.135 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
... (to 30 hops)

If I do the same trace to z3.eastlink.ca, the eastlink.ca DNS, it
manages to get there in 12 hops.

> Are you able to resolve other domains that are hosted on those nameservers..
> such as for example;
>
> vectoraerospace.tv
> sobeys.ca

I didn't know those used bellaliant.net NS servers.  That is an interesting
find, because they also fail in every way just like bellaliant.net lookups
and they suceed when I let the router look them up.

> It could be that bellaliant.net is a special case because it's part of your
> hostname.. dnsmasq might be intercepting it and somehow breaking things?

OK, I've found the problem.  Don't know why it is an issue, but things are fixed
after a change on the router.  Your question caused me to search for
the settings
related to DNS on the router.  A setting on the WAN tab was called:
"Connect to DNS Server automatically" and it had Yes selected.
When this was unselected, two slots appeared for entering the DNS
server IPs.  192.168.0.3 - my bind - was entered here and this was the only
change applied.  Now sobeys.ca and bellaliant.net can be resolved.
192.168.0.1 was removed from resolv.conf and host lookups without
specifying the DNS server are working for the trouble cases.

Thanks for the troubleshooting questions, Robert  - it got me looking
at the right aspect
and this is now resolved (no pun intended).


More information about the nSLUG mailing list