Shard IP Address

[Dorn]

I am having an issue connecting today due to DNS not being able to resolve the shard name. Is it possible to connect via uos using the ip address instead of shard.uoex.net? If so, what is the shard ip address?

Thanks

[Iltar]

Shard ip address(current): [incorrect server ip, removed].
You can also use Google's DNSs 8.8.8.8 and 8.8.4.4 as main or second DNS server if you default doesn't work.

[heyyo]

I'm getting the same problem. I was logged in, but tried to re-login on an alt and now can't get on at all.

[Dorn]

Shard ip address(current): [incorrect server ip, removed].
You can also use Google's DNSs 8.8.8.8 and 8.8.4.4 as main or second DNS server if you default doesn't work.

Iltar you are a genius! The shard ip address did not work when I tried but then I switched to Google DNS and that solved everything.

Thanks a bunch!

[+Colibri]

Shard IP is: 72.55.146.174

If using Razor or similar other program, you can enter this IP in the server address (where "shard.uoex.net" is written).
If connecting directly via the client, edit the Login.cfg file in your UO Directory, and replace "shard.uoex.net" with this IP, making it

Code: Select all

LoginServer=shard.uoex.net,60

Some people are reporting these issues since earlier today, it's likely due to an error in the DNS server and will likely "fix themselves" (did some reconfiguring already) over the course of the next 24 hours, for those that are having issues.

[robinw40]

Will installing and reinstalling fix not being able to login? So is it back working now?

[Wil]

For those interested in the technical minutiae, here was the problem:

dig +trace +nosearch www.uoex.net

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +trace +nosearch www.uoex.net
;; global options: +cmd
. 518400 IN NS f.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS d.root-servers.net.
;; Received 496 bytes from 192.168.99.12#53(192.168.99.12) in 11 ms

net. 172800 IN NS i.gtld-servers.net.
net. 172800 IN NS l.gtld-servers.net.
net. 172800 IN NS h.gtld-servers.net.
net. 172800 IN NS b.gtld-servers.net.
net. 172800 IN NS k.gtld-servers.net.
net. 172800 IN NS m.gtld-servers.net.
net. 172800 IN NS f.gtld-servers.net.
net. 172800 IN NS d.gtld-servers.net.
net. 172800 IN NS j.gtld-servers.net.
net. 172800 IN NS e.gtld-servers.net.
net. 172800 IN NS a.gtld-servers.net.
net. 172800 IN NS c.gtld-servers.net.
net. 172800 IN NS g.gtld-servers.net.
;; Received 499 bytes from 192.5.5.241#53(192.5.5.241) in 645 ms

uoex.net. 172800 IN NS ns1.fastsecurehost.com.
uoex.net. 172800 IN NS ns2.fastsecurehost.com.
uoex.net. 172800 IN NS ns3.fastsecurehost.com.
;; Received 150 bytes from 192.5.6.30#53(192.5.6.30) in 31 ms

www.uoex.net. 14400 IN CNAME uoex.net.
uoex.net. 3600 IN A 192.185.16.76
uoex.net. 86400 IN NS ns1.interval.si.
uoex.net. 86400 IN NS ns2.interval.si.


ns1.fastsecurehost.com returned the IP address for www.uoex.net but it declared that it was not an authoritative name server for uoex.net. Instead, it declared that ns1.interval.si was authoritative. However...

whois interval.si
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% This is ARNES whois database
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

domain: interval.si
registrar: Zabec.net
registrar-url: https://www.zabec.net
nameserver: ns1.fastsecurehost.com
nameserver: ns2.fastsecurehost.com
registrant: G60492
status: pending_quarantine
created: 2007-01-03
expire: 2016-01-03
source: ARNES

oops, interval.si expired so ns1.interval.si could not be resolved. As a result, the resolver can't ask ns1.interval.si where www.uoex.net is.


Now, what happens is: your local DNS server, called a "recursive resolver,' is only supposed to return records from an authoritative name server. Those other answers it gets along the way are called "glue" records. The recursive resolver is only allowed to use them for the purpose of finding the authoritative DNS server.

If the recursive resolver can't reach an authoritative DNS server (all delegations are lame) then it is supposed to return SERVFAIL. When the web browser gets a SERVFAIL it tells the user that it couldn't resolve the IP address of the web server.

This is discussed in RFC 2181 section 5.4.1:

"Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from [...] the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query."

Instead, most of you continued receiving the IP address. The DNS servers you used blindly sent you the glue records without verifying them.

So, for those of you who could not log on today: congratulations. Your DNS server works right.

-Wil

[robinw40]

So it's back to working now?

[heyyo]

After my post, even the shard website stopped working for me. Glad to see it up and running again!

[robinw40]

Thx to whomever fixed it

Que