NCSG-DISCUSS Archives

NCSG-Discuss

NCSG-DISCUSS@LISTSERV.SYR.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Dan Krimm <[log in to unmask]>
Reply To:
Dan Krimm <[log in to unmask]>
Date:
Sat, 9 Aug 2014 12:48:22 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (130 lines)
I'm sympathetic with this point of view.  Technical issues should be able
to be quickly resolved, and it should therefore be possible to identify a
technical contact quickly when something technical is going wrong.  I
emphasize the word "technical" here quite pointedly.

(For example, trademark issues are for the most part not technical -- they
mostly do not affect the technical function of the network.  And any
relevant impacts are the ultimate responsibility of non-technical domain
owners, not technical staff.)

Privacy issues arise mostly for "small" domain owners (like myself) that do
not have the "corporate veil" to protect personal identification
information with a "corporate front".  I don't know the statistics, but I
would not be surprised if the substantial majority of second-level domain
owners actually consists of small entities such as myself -- private
individuals, sole proprietors, small businesses.

And many of such small domain owners use domain-hosting services, and the
technical contacts at those hosting services presumably should be the first
point of contact for technical network issues.  (There could be technical
content issues associated with web servers, but those are by and large
distinct from network technical issues.)

One of the things I look forward to in the future of the Internet is an
even broader proliferation of domain ownership by Little Guys like me, but
in that event we need to protect us Little Guys as if we were individual
citizens, not treating us as if we were big corporations with more layers
and resources for dissociating individuals from corporate activity.

If my domain host did not have a service to add that layer of anonymity to
domain contacts, I would be uncomfortable using them as my host and would
look for one that did offer such service.  And if I couldn't find one, then
I'd be uncomfortable maintaining my own domain -- if I really felt the need
to continue operating my own domain, then I'd be forced to consider
spending resources to formally incorporate some entity to act as the domain
owner, and to establish separate contact information for that entity that
does not identify me as an individual.  This creates higher barriers to
entry for domain ownership (or else a tradeoff of the cost of lack of
personal privacy).

If one promotes the idea of widespread individual ownership of domains
(distribution of power, basically -- this is about pushing back against
centralization of authority), then systematic privacy protection for
citizen-level owners needs to be in place, and that protection need not be
pierced when technical domain operations are contracted to a third party.

(FYI, I am personally not technically qualified to parse and respond to the
example you present below.  Even though I own my domain, the domain host is
the only entity in position to respond to this, and that is part of what I
have contracted them to do.  Their technical operations are almost
completely opaque to me.  So *I* should not be listed as the domain
technical contact -- I would just slow down the resolution of such issues
if I were in the loop.)

Finding the proper balance here is precisely what this ongoing debate is
all about.

Best,
Dan


--
Any opinions expressed in this message are those of the author alone and do
not necessarily reflect any position of the author's employer.



At 2:49 PM -0400 8/9/14, Timothe Litt wrote:
>There is a recurring theme in discussions here that WHOIS data/accuracy
>is a matter of privacy; that somehow the technical need is imaginary, or
>obsolete because most registrants don't actually operate DNS servers.
>The fact is that someone operates the servers, and the technical contact
>needs to reflect that.
>
>Here is a recent (today) example of a (frustrated) senior engineer
>attempting to get malfunctioning DNS server operators to address issues
>that are causing considerable grief.
>
>> I just logged fault reports with the technical contact for every
>> tld that has a server that responds incorrectly to EDNS(1) queries
>> if they handle EDNS(0) queries. BADVERS should be the result if
>> they the support EDNS as EDNS(1) is not yet defined.
>>
>> 	dig +edns=1 zone @host
>>
>> I've had one contact acknowledge the report and say they have logged
>> a report upstream.  This doesn't mean that the others won't be acted
>> on.
>>
>> If we had consistent whois formats I would do the same for the Alexa top 1M.
>> For the tld's I only had to deal with one whois output.
>>
>> The next round will be for those that don't correctly handle unknown
>> EDNS options.  Unknown options should be ignored.
>
>Although I'm on record as believing that privacy needs to be protected
>(and I hate the SPAM that comes to addresses that are ONLY used in my
>WhoIS data), and that privacy proxies are fine; I'm also on record that
>whois contacts need to be responsive - whether directly or thru proxies.
>
>Note that in this example, only one **TLD** responded in a timely
>fashion; whois is in such sad shape that the engineer didn't even try to
>contact the next million domains... Which also gives you some idea of
>the scale of technical issues these daze.
>
>(EDNS queries are queries that include OPT records, which provide DNS
>extensions; at the moment, most notably allowing message sizes greater
>than 512 Bytes, extended flags and response codes.  These are essential
>for DNSSEC deployment.  There are active proposals for other uses.)
>
>I'm not discounting the need for accurate and timely administrative and
>registrant contact information - I just thought I'd share a current,
>live example.
>
>--
>Timothe Litt
>ACM Distinguished Engineer
>--------------------------
>This communication may not represent the ACM or my employer's views,
>if any, on the matters discussed.
>
>
>
>
>Content-Type: application/pkcs7-signature; name="smime.p7s"
>Content-Disposition: attachment; filename="smime.p7s"
>Content-Description: S/MIME Cryptographic Signature
>
>Attachment converted: Macintosh HD:smime 77.p7s (    /    ) (008177D4)

ATOM RSS1 RSS2