[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: domains, registrars, and whois contact info. defaulting to hidden? Yes, because ...



I wrote:

> I'd be glad to show BerkeleyLUG members the public contents of the whois
> records for linuxmafia.com or unixmercenary.net (my domains) -- except
> my registrar is screwing that up, at the moment.  ;->

As Michael Paoli speculated applied broadly to 'whois', it turned out that 
the cause of the above mishegoss was indeed GDPR.

My registrar, these days, is IWantMyName.com, a really likeable and very
competant & customer-respecting small company in Wellington, New
Zealand.  Complicating things just a bit (and making the GDPR
complication inevitable), IWantMyName is tiny enough that it operates as
a _reseller_ of services through a much larger German company, 1API Gmbh
of Homburg.

So, basically, within this past year, apparently everyone got 'whois
privacy' by default whether they wanted it or not, and I had to go
through a couple of rounds with IWantMyName support before they were
able to flip all the right toggles so that all my domain contact
information would be public again (verdammt!).

For those playing along at home, if you have a copy of the 'whois'
client program (typically /usr/bin/whois or /usr/bin/jwhois on Linux),
then you ask 'whois [domainname]'.  These days, that query often gives
you pretty uninformative results but implies that you can & should ask a
specific whois server the same question to get the _real_ results.
E.g.:

$ whois linuxmafia.com 

Domain Name: LINUXMAFIA.COM
   Registry Domain ID: 5397999_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.1api.net
   Registrar URL: http://www.1api.net
[...]
$

The line 'Registrar WHOIS Server: whois.1api.net' says, in effect, try 
again _there_. So:

$ whois -h whois.1api.net linuxmafia.com

[...]
Registrant Name: Rick Moen
Registrant Organization: UNIX Mercenary Consulting
Registrant Street: 1105 Altschul Ave
Registrant City: Menlo Park
Registrant State/Province: CA
Registrant Postal Code: 94025-6601
Registrant Country: US
Registrant Phone: +1.6502837902
Registrant Email: rick@deirdre.net
Admin Name: Rick Moen
Admin Street: 1105 Altschul Ave
Admin City: Menlo Park
Admin State/Province: CA
Admin Postal Code: 94025-6601
Admin Country: US
Admin Phone: +1.6502837902
Admin Email: rick@deirdre.net
Tech Name: Deirdre Saoirse Moen
Tech Street: 1105 Altschul Ave
Tech City: Menlo Park
Tech State/Province: CA
Tech Postal Code: 94025-6601
Tech Country: US
Tech Phone: +1.6503877830
Tech Email: deirdre@deirdre.net
[...]


Registrant, Admin Contact, and Tech Contact are traditionally defined
functional roles:

Registrant is the legal owner.  In the event of dispute over who 
controls the domain, the Registrant will win.  Admin Contact is in
theory the person dealing with the registrar on administratives question
about domain management.  Technical Contact is in theory the person
who'll deal with any domain technical issues.

All three of these persons typically receive all renewal and other
administrative notices associated with the domain name.

The most important thing, therefore:  Making sure at least one of these
contacts, preferably all three, are _reliably reachable_.  Because
sometimes it's really important, e.g., your domain is about to expire
and you need to renew it now.  And, towards that end, you want to
carefully weed out single points of failure (SPoFs).

Therfore, you'll notice a couple of things:  (1) I make sure the
contents are spread between me and my wife Deirdre.  Having a third
person involved would be even better.  (2) The path to reach us doesn't
involve the domain in question (linuxmafia.com), or any of the computing
infrastructure to support that domain.  I made sure 'Dude, your domain
is broken' mails will reach us even if, say, the domain is broken.

There _is_ one obvious SPoF among the contacts:  My wife'd domain,
deirdre.net.  If it's broken, then my domain contacts are unreachable.
But it's a much less serious SPoF than relying on linuxmafia.com or
the hosting or DNS or AC power or computer serving linuxmafia.com, to
get me 'Dude, there's a problem with linuxmafia.com' mails.


I keep finding domain owners stumbling across new and complicated ways
of screwing this up, e.g,, when Heather Stern decided to gratuitously
route all domain-contact mail for svlug.org through /etc/aliases entries
on her personal starshine.org machine, and then later broke aliases and 
forgot that would prevent SVLUG from getting renewal notices.  BALUG
at one point against my advice using /etc/aliases entries in a similar
way, not for domain contacts but for Mailman listadmin purposes, which
had the effect of making it difficult to track down the problem when the
other member of the listadmin team (the one who wasn't Rick Moen)
decided to quietly walk away from the job and ceased to be deliverable.

KISS should be the operative principle, when it absolutely positively
needs to work.  So, direct delivery to an actively monitored mailbox
should be preferred.


-- 
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsubscribe@googlegroups.com.
To post to this group, send email to berkeleylug@googlegroups.com.
Visit this group at https://groups.google.com/group/berkeleylug.
For more options, visit https://groups.google.com/d/optout.