Appending domain to ping issues

  • Thread starter Thread starter Hank
  • Start date Start date
H

Hank

Hey guys,
Here is my deal....
::I have a domain controller also acting as dns.

::The primary internal domain is MyCompanyInternal.net, everyone is
logging on to that domain.

::I have tried to setup a ".dev" root domain for my internal
developers so that we can setup websites on http://tom.dev, or
http://appserver.dev

::I setup a zone for .Dev and added all my websites....things worked
great for months, everyone loved it.

::Monday I come into the office and all of my webservers can't be
resolved...so I start pinging... "ping tom.dev" gives me back
"Pinging tom.dev.MyCompanyInternal.net [64.94.110.11]..." and it times
out. That ip has absolutely nothing to do with my company or my
internal 192.168.x.x structure. So I do an nslookup, and it comes
back with the info that it is supposed to.

::I figure I will outsmart it and add a hosts file entry....it doesn't
work!!!

I'm a programmer guys, I don't have the foggiest idea as to how to
troubleshoot DNS if it breaks. Hoping one of you admin guys can give
me some pointers, 'cause this really sucks.

Thanks in advance,
-Hank Lynch
 
In
Hank said:
Hey guys,
Here is my deal....developers so that we can setup websites on http://tom.dev, or
http://appserver.dev
great for months, everyone loved it.
resolved...so I start pinging... "ping tom.dev" gives me back
"Pinging tom.dev.MyCompanyInternal.net [64.94.110.11]..." and it times
out. That ip has absolutely nothing to do with my company or my
internal 192.168.x.x structure. So I do an nslookup, and it comes
back with the info that it is supposed to.

I'm a programmer guys, I don't have the foggiest idea as to how to
troubleshoot DNS if it breaks. Hoping one of you admin guys can give
me some pointers, 'cause this really sucks.

Thanks in advance,
-Hank Lynch
Click to expand...

Does the .dev zone exist on all DNS servers listed in TCP/IP properties on
the machines accessing it?
You should also add .dev to the search order on the machines that need to
access this zone.
 
You have been bitten by the Verisign hyjack (hack). Verisign, in a *very
very (did I say very?) stupid move, has added wildcard records in the .com
and .net namespaces. That means that any domain name not registered will
resolve to the wildcard - which in this case is the 64.x address you see (do
a dig -x 64.x.x.x to prove that.)
However, if you have "tim" in the dev zone, why does not your dns server
reply? Could be your client version. w2k+ hosts will append the dot first
and try that. I think earlier versions of windows would append the primary
suffix first. This may be your issue. In any event, it is related to
Verisign and the suffix search order on the client. Do the ping with the
"." at the end and it should resolve. Everyone should write ICANN and
complain. This must be effecting many many things - including email.
http://reports.internic.net/cgi/registrars/problem-report.cgi
 
In
William Stacey said:
You have been bitten by the Verisign hyjack (hack). Verisign, in a
*very very (did I say very?) stupid move, has added wildcard records
in the .com and .net namespaces. That means that any domain name not
registered will resolve to the wildcard - which in this case is the
64.x address you see (do a dig -x 64.x.x.x to prove that.)
Click to expand...
<snip>

William, do you have more info on this hyjack issue?

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
The coffeehouse has some links for slashdot posts and the whitepaper from
Verisign on the update. I see it has happened already. This must be
messing up tons of stuff out there... I bet MS support is ringing off the
hook.
 
In
William Stacey said:
The coffeehouse has some links for slashdot posts and the whitepaper
from Verisign on the update. I see it has happened already. This
must be messing up tons of stuff out there... I bet MS support is
ringing off the hook.
Click to expand...

Wow, have to check it out. Didn't realize it's that bad. Definitely
something that we don't want, like Hurricane Isabel heading our way.
:-)

Ace
 
Good analogy Ace. I suspect this is effecting other stuff Verisign did not
even think about (obviously.)
 
I read much of both PDF files linked at the bottom of the slashdot article:
http://slashdot.org/articles/03/09/16/0034210.shtml?tid=126&tid=95&tid=98&tid=99

So that explains some of the recent posts about bad lookups.

And am really really surprised they would just abritraly do this at
Verisign. I guess they're setting themselves up to eploit this into a $$
making scheme? But I thought they were supposed to be the "trusted" or at
least the controlling body of com and net names bestowed by the government.
I thought one can't esploit it with a position like that, unless I have it
all wrong?

Ace

In
William Stacey said:
Good analogy Ace. I suspect this is effecting other stuff Verisign
did not even think about (obviously.)


"Ace Fekay [MVP]"
Click to expand...



--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
Its a scam if you ask me. A profit making org gets to control the whole
deal and be a registrar on top of that. If the registry will not be a gov
org, then it should at least be a non-profit or profit org that must manage
only the registry and don't let Registrar do this kind of thing to the
registry. Maybe the registry should go back to ICANN.
 
I agree, it should go back to ICANN. This is nuts!

Ace

In
William Stacey said:
Its a scam if you ask me. A profit making org gets to control the
whole
deal and be a registrar on top of that. If the registry will not be
a gov
org, then it should at least be a non-profit or profit org that must
manage only the registry and don't let Registrar do this kind of
thing to the registry. Maybe the registry should go back to ICANN.


"Ace Fekay [MVP]"

http://slashdot.org/articles/03/09/16/0034210.shtml?tid=126&tid=95&tid=98&tid=99
Click to expand...



--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
WS> Its a scam if you ask me. A profit making org gets to control
WS> the whole deal and be a registrar on top of that.

It's only fair to point out that this is the case for several CC
TLD registries, and has been for some time. (This doesn't
necessarily mean that this kind of setup is a good idea, though.)

However, the situation with Verisign is slightly _worse_ than you
describe. Verisign is _also_ responsible for two of ICANN's "."
content DNS servers. It has _three_ rôles.

The remedy for Verisign breaching trust is to revoke its authority.
This is done by the various "." content DNS server organizations such
as ICANN, ORSC, and PacificRoot delegating "com." and "net." elsewhere
(in response to user pressure). But since Verisign operates two of
the "." content DNS servers for one of the popular root server
organizations, there is a conflict of interest. Verisign is unlikely
to coöperate in the revocation of its own authority.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/verisign-internet-coup.html#Resistance>
 
William Stacey said:
Good analogy Ace. I suspect this is effecting other stuff Verisign did not
even think about (obviously.)
Click to expand...

Cool guys,
Thanks for the responses, but I'm still stumped. I have no idea what
I'm supposed to do on this. Like for instance, why wouldn't my HOSTS
file override the DNS? There are only 4 people realisticly affected
by the dev domain going away, so hosts files would be
reasonable....but they dont seem to work. It still bounces my out to
verisign.

I have a slew of internal processes and webservices that are down.
Who would I even call on something like this?

I HATE Verisign! This is so stupid!

-Hank
 
1) hosts file should be used. clear the cache on the machine with ipconfig
/flushdns and clear the cache on the dns server using ui or dnscmd
/clearcache and try again.
2) Lets focus on one client and the dns server for now. Show me the command
your using that is not returning right (i.e. ping, nslookup, dig). From the
client use nslookup or dig to make sure a directed query returns the answer
you seek.
3) Did you try it with the "." dot on the end?
 
Does the .dev zone exist on all DNS servers listed in
TCP/IP properties on
the machines accessing it?
You should also add .dev to the search order on the machines that need to
access this zone.
Click to expand...

Where is the search order thing done?
 
JdeBP> [...] Verisign is unlikely to coöperate in the revocation
JdeBP> of its own authority.
JdeBP>
JdeBP> <URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/verisign-internet-coup.html#Resistance>

WS> How does this work again? ICANN has a contract with Verisign
WS> to manage the registry right?

It's not the "com." and "net." registries that are what I was
referring to. _In addition_ to running the "com." and "net."
content DNS servers (and the registries from which their databases
are generated), Verisign _also_ manages the two ICANN "." content
DNS servers at 198.41.0.4 and 192.58.128.30.

The scenario plays out like this: If Verisign refuses to revert
to toeing the line, the next port of call is to have the root server
organizations delegate "com." and "net." to some _other_ company,
that will. However, in the case of one root server organization,
ICANN, Verisign is one of the companies that runs the organization's
own "." content DNS servers. Verisign could thus _also_ refuse to
toe the line if it came to ICANN re-delegating "com." and "net.".

WS> I would think they may have broken the contract with this
WS> move so ICANN could take it back and bid it out again to
WS> someone else?

That depends from the exact terms of the contract, if there is one.
Reading ICANN's articles of incorporation and bylaws makes me wonder
whether it even has the power to make such contracts (given that they
only mention oversight and advice, and not the actual provision of
"." content DNS server itself). I also strongly suspect that, if
such a contract exists, its terms _don't_ prohibit what Verisign
has done.

I further suspect that none of the other root server organisations
have a contract with Verisign, either, and are wondering what is
going to happen in the event that Verisign really does decide not
to revert to toeing the line and to be obstinate (or, worse,
decides to deploy one of the various new denial-of-service weapons
that people have just given to it over the past few days).
 
Hmm, this is getting ugly.
Welcome to the monopoly...

Here's a thread of interest about this mess:
http://yro.slashdot.org/article.pl?sid=03/09/17/1154242&mode=thread&tid=126&tid=185&tid=187&tid=95

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
--
=================================

Jonathan de Boyne Pollard said:
AF> Didn't realize it's that bad.

It has several quite undesirable consequences. One is particularly
important for people who like to provide answers in fora such as
these.
Click to expand...
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/verisign-internet-cou
p.html#Consequences>
 
AF> Hmm, this is getting ugly.

Not yet. Given the triple-rôle nature of Verisign (as "com."/"net."
registrar, "com."/"net." registry, and one of the operators of one
popular root server organization's "." content DNS servers), though,
it certainly has the potential to _become_ ugly if Verisign decides
to ignore everyone else and continue.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/verisign-internet-coup.html#Resistance>

AF> Welcome to the monopoly...

s/the/another/

It's only a monopoly by virtue of the Flash Crowd Effect. We've all
decided (unwittingly in many cases, perhaps) that Verisign is where
we will go to ask about "com." and "net." and their subdomains. If
we all decide differently, there's nothing that Verisign can do about
it. It's our authority over the DNS namespace, to delegate to
whomever we please.
 
In
Austin said:
Where is the search order thing done?
Click to expand...

On the DNS tab in TCP/IP properties select Append these DNS suffixes

One very important thing to remember any DNS server you have listed on the
machines that need access to your .dev zone will need to have the .dev zone
in it.
If all DNS servers do not have the .dev zone they will forward the request
and you will get errors.
 
Back
Top