[dns-operations] dns-operations Digest, Vol 141, Issue 12
Weinberg, Matt
mweinberg at verisign.com
Mon Oct 9 19:52:08 UTC 2017
There are no known issues or connectivity problems with k.gtld-servers.net. I cannot speak with specifics to your issue without traceroute and other information. If you have further concerns, please engage Verisign’s customer support team at info at verisign.com<mailto:info at verisign.com>.
Thanks,
Matt
From: dns-operations <dns-operations-bounces at dns-oarc.net> on behalf of Baalakrishnan Nadar <mbkrishnan at gmail.com>
Date: Monday, October 9, 2017 at 3:21 PM
To: "dns-operations at dns-oarc.net" <dns-operations at dns-oarc.net>
Subject: [EXTERNAL] Re: [dns-operations] dns-operations Digest, Vol 141, Issue 12
Dear All,
We see huge delay from k.gtld-servers.net<http://k.gtld-servers.net> and few other gtld root servers to respond.
~]$ dig +trace google.com<http://google.com>
;; global options: +cmd
. 72028 IN NS b.root-servers.net<http://b.root-servers.net>.
. 72028 IN NS h.root-servers.net<http://h.root-servers.net>.
. 72028 IN NS e.root-servers.net<http://e.root-servers.net>.
. 72028 IN NS l.root-servers.net<http://l.root-servers.net>.
. 72028 IN NS f.root-servers.net<http://f.root-servers.net>.
. 72028 IN NS c.root-servers.net<http://c.root-servers.net>.
. 72028 IN NS i.root-servers.net<http://i.root-servers.net>.
. 72028 IN NS j.root-servers.net<http://j.root-servers.net>.
. 72028 IN NS d.root-servers.net<http://d.root-servers.net>.
. 72028 IN NS k.root-servers.net<http://k.root-servers.net>.
. 72028 IN NS a.root-servers.net<http://a.root-servers.net>.
. 72028 IN NS m.root-servers.net<http://m.root-servers.net>.
. 72028 IN NS g.root-servers.net<http://g.root-servers.net>.
;; Received 228 bytes from 10.132.60.19#53(10.132.60.19) in 7 ms
com. 172800 IN NS a.gtld-servers.net<http://a.gtld-servers.net>.
com. 172800 IN NS b.gtld-servers.net<http://b.gtld-servers.net>.
com. 172800 IN NS c.gtld-servers.net<http://c.gtld-servers.net>.
com. 172800 IN NS d.gtld-servers.net<http://d.gtld-servers.net>.
com. 172800 IN NS e.gtld-servers.net<http://e.gtld-servers.net>.
com. 172800 IN NS f.gtld-servers.net<http://f.gtld-servers.net>.
com. 172800 IN NS g.gtld-servers.net<http://g.gtld-servers.net>.
com. 172800 IN NS h.gtld-servers.net<http://h.gtld-servers.net>.
com. 172800 IN NS i.gtld-servers.net<http://i.gtld-servers.net>.
com. 172800 IN NS j.gtld-servers.net<http://j.gtld-servers.net>.
com. 172800 IN NS k.gtld-servers.net<http://k.gtld-servers.net>.
com. 172800 IN NS l.gtld-servers.net<http://l.gtld-servers.net>.
com. 172800 IN NS m.gtld-servers.net<http://m.gtld-servers.net>.
;; Received 488 bytes from 192.58.128.30#53(192.58.128.30) in 33 ms
google.com<http://google.com>. 172800 IN NS ns2.google.com<http://ns2.google.com>.
google.com<http://google.com>. 172800 IN NS ns1.google.com<http://ns1.google.com>.
google.com<http://google.com>. 172800 IN NS ns3.google.com<http://ns3.google.com>.
google.com<http://google.com>. 172800 IN NS ns4.google.com<http://ns4.google.com>.
;; Received 164 bytes from 192.52.178.30#53(192.52.178.30) in 5964 ms
google.com<http://google.com>. 300 IN A 216.58.197.46
;; Received 44 bytes from 216.239.32.10#53(216.239.32.10) in 57 ms
~]$ dig +trace verizon.net<http://verizon.net>
;; global options: +cmd
. 71802 IN NS e.root-servers.net<http://e.root-servers.net>.
. 71802 IN NS d.root-servers.net<http://d.root-servers.net>.
. 71802 IN NS l.root-servers.net<http://l.root-servers.net>.
. 71802 IN NS c.root-servers.net<http://c.root-servers.net>.
. 71802 IN NS j.root-servers.net<http://j.root-servers.net>.
. 71802 IN NS h.root-servers.net<http://h.root-servers.net>.
. 71802 IN NS m.root-servers.net<http://m.root-servers.net>.
. 71802 IN NS i.root-servers.net<http://i.root-servers.net>.
. 71802 IN NS a.root-servers.net<http://a.root-servers.net>.
. 71802 IN NS k.root-servers.net<http://k.root-servers.net>.
. 71802 IN NS g.root-servers.net<http://g.root-servers.net>.
. 71802 IN NS f.root-servers.net<http://f.root-servers.net>.
. 71802 IN NS b.root-servers.net<http://b.root-servers.net>.
;; Received 228 bytes from 10.132.60.19#53(10.132.60.19) in 6 ms
net. 172800 IN NS c.gtld-servers.net<http://c.gtld-servers.net>.
net. 172800 IN NS f.gtld-servers.net<http://f.gtld-servers.net>.
net. 172800 IN NS l.gtld-servers.net<http://l.gtld-servers.net>.
net. 172800 IN NS a.gtld-servers.net<http://a.gtld-servers.net>.
net. 172800 IN NS m.gtld-servers.net<http://m.gtld-servers.net>.
net. 172800 IN NS j.gtld-servers.net<http://j.gtld-servers.net>.
net. 172800 IN NS b.gtld-servers.net<http://b.gtld-servers.net>.
net. 172800 IN NS h.gtld-servers.net<http://h.gtld-servers.net>.
net. 172800 IN NS k.gtld-servers.net<http://k.gtld-servers.net>.
net. 172800 IN NS g.gtld-servers.net<http://g.gtld-servers.net>.
net. 172800 IN NS d.gtld-servers.net<http://d.gtld-servers.net>.
net. 172800 IN NS e.gtld-servers.net<http://e.gtld-servers.net>.
net. 172800 IN NS i.gtld-servers.net<http://i.gtld-servers.net>.
;; Received 486 bytes from 192.5.5.241#53(192.5.5.241) in 36 ms
verizon.net<http://verizon.net>. 172800 IN NS ns2.verizon.net<http://ns2.verizon.net>.
verizon.net<http://verizon.net>. 172800 IN NS ns4.verizon.net<http://ns4.verizon.net>.
verizon.net<http://verizon.net>. 172800 IN NS ns1.verizon.net<http://ns1.verizon.net>.
verizon.net<http://verizon.net>. 172800 IN NS ns3.verizon.net<http://ns3.verizon.net>.
;; Received 165 bytes from 192.43.172.30#53(192.43.172.30) in 9440 ms
verizon.net<http://verizon.net>. 604800 IN A 192.16.31.26
verizon.net<http://verizon.net>. 86400 IN NS ns4.verizon.net<http://ns4.verizon.net>.
verizon.net<http://verizon.net>. 86400 IN NS ns1.verizon.net<http://ns1.verizon.net>.
verizon.net<http://verizon.net>. 86400 IN NS ns2.verizon.net<http://ns2.verizon.net>.
verizon.net<http://verizon.net>. 86400 IN NS ns3.verizon.net<http://ns3.verizon.net>.
;; Received 181 bytes from 151.203.0.86#53(151.203.0.86) in 201 ms
With Regards,
Balakrishnan
On Mon, Oct 9, 2017 at 10:43 PM, <dns-operations-request at dns-oarc.net<mailto:dns-operations-request at dns-oarc.net>> wrote:
Send dns-operations mailing list submissions to
dns-operations at lists.dns-oarc.net<mailto:dns-operations at lists.dns-oarc.net>
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
or, via email, send a message with subject or body 'help' to
dns-operations-request at lists.dns-oarc.net<mailto:dns-operations-request at lists.dns-oarc.net>
You can reach the person managing the list at
dns-operations-owner at lists.dns-oarc.net<mailto:dns-operations-owner at lists.dns-oarc.net>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dns-operations digest..."
Today's Topics:
1. Glue IP addresses in whois output in .com (and may be others)
(Stephane Bortzmeyer)
2. Re: Glue IP addresses in whois output in .com (and may be
others) (bert hubert)
3. Re: Glue IP addresses in whois output in .com (and may be
others) (Tony Finch)
4. Re: Glue IP addresses in whois output in .com (and may be
others) (Stephane Bortzmeyer)
5. Re: Glue IP addresses in whois output in .com (and may be
others) (Jim Reid)
6. Re: Glue IP addresses in whois output in .com (and may be
others) (Stephane Bortzmeyer)
7. Re: Glue IP addresses in whois output in .com (and may be
others) (Ray Bellis)
8. Re: Glue IP addresses in whois output in .com (and may be
others) (Jim Reid)
9. Call for Papers: NDSS Workshop on DNS Privacy 2018
(Sara Dickinson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 9 Oct 2017 16:34:53 +0200
From: Stephane Bortzmeyer <bortzmeyer at nic.fr<mailto:bortzmeyer at nic.fr>>
To: dns-operations at dns-oarc.net<mailto:dns-operations at dns-oarc.net>
Subject: [dns-operations] Glue IP addresses in whois output in .com
(and may be others)
Message-ID: <20171009143453.k7i4e4qrupgliu7p at nic.fr<mailto:20171009143453.k7i4e4qrupgliu7p at nic.fr>>
Content-Type: text/plain; charset=us-ascii
I have the strange feeling that I'm the last human on earth to
discover that .com whois no longer publishes the IP addresses of glue
records.
% whois socgen.com<http://socgen.com>
...
Name Server: NYCDNS01.US.SOCGEN.COM<http://NYCDNS01.US.SOCGEN.COM>
Name Server: NYCDNS02.US.SOCGEN.COM<http://NYCDNS02.US.SOCGEN.COM>
Name Server: TIGDNS01.SOCGEN.COM<http://TIGDNS01.SOCGEN.COM>
Name Server: TIGDNS02.SOCGEN.COM<http://TIGDNS02.SOCGEN.COM>
The registry knows them, of course:
% dig @a.gtld-servers.net<http://a.gtld-servers.net> NYCDNS01.US.SOCGEN.COM<http://NYCDNS01.US.SOCGEN.COM>
...
;; ADDITIONAL SECTION:
NYCDNS01.US.SOCGEN.COM<http://NYCDNS01.US.SOCGEN.COM>. 172800 IN A 162.246.240.1
nycdns02.US.SOCGEN.COM<http://nycdns02.US.SOCGEN.COM>. 172800 IN A 162.246.241.1
tigdns01.SOCGEN.COM<http://tigdns01.SOCGEN.COM>. 172800 IN A 193.178.155.113
tigdns02.SOCGEN.COM<http://tigdns02.SOCGEN.COM>. 172800 IN A 193.178.155.114
But does not publish in whois. I'm reasonably certain that, in the
past, it was published via whois. We still do it in .fr:
% whois ssi.gouv.fr<http://ssi.gouv.fr>
domain: ssi.gouv.fr<http://ssi.gouv.fr>
nsl-id: NSL139448-FRNIC
ns-list: NSL139448-FRNIC
nserver: dns1.ssi.gouv.fr<http://dns1.ssi.gouv.fr> [213.56.166.96<tel:%5B213.56.166.96>]
nserver: dns2.ssi.gouv.fr<http://dns2.ssi.gouv.fr> [86.65.182.91]
nserver: ns6.gandi.net<http://ns6.gandi.net>
When was it changed? Why? Did I dream the whole thing?
------------------------------
Message: 2
Date: Mon, 9 Oct 2017 17:15:54 +0200
From: bert hubert <bert.hubert at powerdns.com<mailto:bert.hubert at powerdns.com>>
To: Stephane Bortzmeyer <bortzmeyer at nic.fr<mailto:bortzmeyer at nic.fr>>
Cc: dns-operations at dns-oarc.net<mailto:dns-operations at dns-oarc.net>
Subject: Re: [dns-operations] Glue IP addresses in whois output in
.com (and may be others)
Message-ID: <20171009151554.GA30033 at server.ds9a.nl<mailto:20171009151554.GA30033 at server.ds9a.nl>>
Content-Type: text/plain; charset=us-ascii
On Mon, Oct 09, 2017 at 04:34:53PM +0200, Stephane Bortzmeyer wrote:
> I have the strange feeling that I'm the last human on earth to
> discover that .com whois no longer publishes the IP addresses of glue
> records.
>
> % whois socgen.com<http://socgen.com>
$ whois TIGDNS01.SOCGEN.COM<http://TIGDNS01.SOCGEN.COM>
Server Name: TIGDNS01.SOCGEN.COM<http://TIGDNS01.SOCGEN.COM>
IP Address: 193.178.155.113
Registrar: CSC Corporate Domains, Inc.
Registrar WHOIS Server: whois.corporatedomains.com<http://whois.corporatedomains.com>
Registrar URL: http://www.cscglobal.com/global/web/csc/digital-brand-services.html
>>> Last update of whois database: 2017-10-09T15:14:52Z <<<
Perhaps this is helpful?
Bert
------------------------------
Message: 3
Date: Mon, 9 Oct 2017 16:20:33 +0100
From: Tony Finch <dot at dotat.at<mailto:dot at dotat.at>>
To: Stephane Bortzmeyer <bortzmeyer at nic.fr<mailto:bortzmeyer at nic.fr>>
Cc: dns-operations at dns-oarc.net<mailto:dns-operations at dns-oarc.net>
Subject: Re: [dns-operations] Glue IP addresses in whois output in
.com (and may be others)
Message-ID: <alpine.DEB.2.11.1710091607300.22527 at grey.csi.cam.ac.uk<mailto:alpine.DEB.2.11.1710091607300.22527 at grey.csi.cam.ac.uk>>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Stephane Bortzmeyer <bortzmeyer at nic.fr<mailto:bortzmeyer at nic.fr>> wrote:
> I have the strange feeling that I'm the last human on earth to
> discover that .com whois no longer publishes the IP addresses of glue
> records.
Hmm, yes, something has definitely changed.
The whois database does still have the nameserver objects if you ask for
them directly, e.g.
$ whois -h whois.verisign-grs.com<http://whois.verisign-grs.com> 'nameserver tigdns02.socgen.com<http://tigdns02.socgen.com>'
It used to be the case that there was an amazing number of spammy host
object names that `whois` would return due to fuzzy matching, especially
if you asked for things like `microsoft.com<http://microsoft.com>`. The Verisign `whois help`
output still talks about fuzzy matching but it doesn't actually seem to do
it any more.
A while back I changed FreeBSD whois to prefix queries to Verisign with
`domain` to suppress the spam. Looks like I can rip that code out again :-)
https://svnweb.freebsd.org/base?view=revision&revision=294575
Tony.
--
f.anthony.n.finch <dot at dotat.at<mailto:dot at dotat.at>> http://dotat.at/ - I xn--zr8h punycode
Trafalgar: Easterly or northeasterly 4 or 5 at times in far southeast,
otherwise variable 3 or 4. Slight or moderate. Fair. Moderate or good.
------------------------------
Message: 4
Date: Mon, 9 Oct 2017 17:22:39 +0200
From: Stephane Bortzmeyer <bortzmeyer at nic.fr<mailto:bortzmeyer at nic.fr>>
To: bert hubert <bert.hubert at powerdns.com<mailto:bert.hubert at powerdns.com>>
Cc: dns-operations at dns-oarc.net<mailto:dns-operations at dns-oarc.net>
Subject: Re: [dns-operations] Glue IP addresses in whois output in
.com (and may be others)
Message-ID: <20171009152239.ziaq4jqemwzqh777 at nic.fr<mailto:20171009152239.ziaq4jqemwzqh777 at nic.fr>>
Content-Type: text/plain; charset=us-ascii
On Mon, Oct 09, 2017 at 05:15:54PM +0200,
bert hubert <bert.hubert at powerdns.com<mailto:bert.hubert at powerdns.com>> wrote
a message of 18 lines which said:
> $ whois TIGDNS01.SOCGEN.COM<http://TIGDNS01.SOCGEN.COM>
> Server Name: TIGDNS01.SOCGEN.COM<http://TIGDNS01.SOCGEN.COM>
> IP Address: 193.178.155.113
We apparently use different whois clients:
% whois TIGDNS01.SOCGEN.COM<http://TIGDNS01.SOCGEN.COM>
No match for domain "TIGDNS01.SOCGEN.COM<http://TIGDNS01.SOCGEN.COM>".
% whois -h whois.verisign-grs.com<http://whois.verisign-grs.com> TIGDNS01.SOCGEN.COM<http://TIGDNS01.SOCGEN.COM>
Server Name: TIGDNS01.SOCGEN.COM<http://TIGDNS01.SOCGEN.COM>
IP Address: 193.178.155.113
OK, so the problem was with my whois client, it seems, it no longer
queries the right place.
------------------------------
Message: 5
Date: Mon, 9 Oct 2017 16:34:37 +0100
From: Jim Reid <jim at rfc1035.com<mailto:jim at rfc1035.com>>
To: Stephane Bortzmeyer <bortzmeyer at nic.fr<mailto:bortzmeyer at nic.fr>>
Cc: DNS Operations <dns-operations at dns-oarc.net<mailto:dns-operations at dns-oarc.net>>
Subject: Re: [dns-operations] Glue IP addresses in whois output in
.com (and may be others)
Message-ID: <1A9764FE-1D39-449A-8476-24AFB975A00E at rfc1035.com<mailto:1A9764FE-1D39-449A-8476-24AFB975A00E at rfc1035.com>>
Content-Type: text/plain; charset=utf-8
> On 9 Oct 2017, at 16:22, Stephane Bortzmeyer <bortzmeyer at nic.fr<mailto:bortzmeyer at nic.fr>> wrote:
>
> OK, so the problem was with my whois client, it seems, it no longer
> queries the right place.
Why are you looking for glue records with a whois client? Isn?t that best done using a DNS tool like dig?
------------------------------
Message: 6
Date: Mon, 9 Oct 2017 17:41:35 +0200
From: Stephane Bortzmeyer <bortzmeyer at nic.fr<mailto:bortzmeyer at nic.fr>>
To: Jim Reid <jim at rfc1035.com<mailto:jim at rfc1035.com>>
Cc: Stephane Bortzmeyer <bortzmeyer at nic.fr<mailto:bortzmeyer at nic.fr>>, DNS Operations
<dns-operations at dns-oarc.net<mailto:dns-operations at dns-oarc.net>>
Subject: Re: [dns-operations] Glue IP addresses in whois output in
.com (and may be others)
Message-ID: <20171009154135.6qurhosjg3mvrvag at nic.fr<mailto:20171009154135.6qurhosjg3mvrvag at nic.fr>>
Content-Type: text/plain; charset=utf-8
On Mon, Oct 09, 2017 at 04:34:37PM +0100,
Jim Reid <jim at rfc1035.com<mailto:jim at rfc1035.com>> wrote
a message of 9 lines which said:
> Why are you looking for glue records with a whois client? Isn?t that
> best done using a DNS tool like dig?
Some domains are registered but not published in the DNS.
------------------------------
Message: 7
Date: Mon, 9 Oct 2017 16:58:44 +0100
From: Ray Bellis <ray at isc.org<mailto:ray at isc.org>>
To: dns-operations at dns-oarc.net<mailto:dns-operations at dns-oarc.net>
Subject: Re: [dns-operations] Glue IP addresses in whois output in
.com (and may be others)
Message-ID: <d206b23e-cb9d-78c9-4f9a-64a446337eb3 at isc.org<mailto:d206b23e-cb9d-78c9-4f9a-64a446337eb3 at isc.org>>
Content-Type: text/plain; charset=utf-8
On 09/10/2017 16:41, Stephane Bortzmeyer wrote:
> Some domains are registered but not published in the DNS.
If it's not published in the DNS it doesn't need glue records...
Ray
------------------------------
Message: 8
Date: Mon, 9 Oct 2017 17:05:11 +0100
From: Jim Reid <jim at rfc1035.com<mailto:jim at rfc1035.com>>
To: Stephane Bortzmeyer <bortzmeyer at nic.fr<mailto:bortzmeyer at nic.fr>>
Cc: DNS Operations <dns-operations at dns-oarc.net<mailto:dns-operations at dns-oarc.net>>
Subject: Re: [dns-operations] Glue IP addresses in whois output in
.com (and may be others)
Message-ID: <2A0C1EF5-9063-4374-8A92-EE54CF8ABFF7 at rfc1035.com<mailto:2A0C1EF5-9063-4374-8A92-EE54CF8ABFF7 at rfc1035.com>>
Content-Type: text/plain; charset=utf-8
> On 9 Oct 2017, at 16:41, Stephane Bortzmeyer <bortzmeyer at nic.fr<mailto:bortzmeyer at nic.fr>> wrote:
>
>> Why are you looking for glue records with a whois client? Isn?t that
>> best done using a DNS tool like dig?
>
> Some domains are registered but not published in the DNS.
I?m even more puzzled Stephane. If some domains are not published in the DNS, why would anyone care about their (non-existent) glue?
------------------------------
Message: 9
Date: Mon, 9 Oct 2017 18:13:34 +0100
From: Sara Dickinson <sara at sinodun.com<mailto:sara at sinodun.com>>
To: dns-operations at dns-oarc.net<mailto:dns-operations at dns-oarc.net>
Subject: [dns-operations] Call for Papers: NDSS Workshop on DNS
Privacy 2018
Message-ID: <3767A785-5510-48A2-99D5-108EF4446E79 at sinodun.com<mailto:3767A785-5510-48A2-99D5-108EF4446E79 at sinodun.com>>
Content-Type: text/plain; charset="utf-8"
Hi All,
Please consider submitting to the NDSS DNS Privacy Workshop 2018: Increasing Usability and Decreasing Traceability.
Call for papers: https://easychair.org/cfp/dprive2018 <https://easychair.org/cfp/dprive2018>
Workshop Website: https://dnsprivacy.org/wiki/display/DNSPWS/DNS+Privacy+Workshop <https://dnsprivacy.org/wiki/display/DNSPWS/DNS+Privacy+Workshop>
Location and Important Dates
-----------------------------------------
Workshop Location: San Diego, CA, USA
Workshop date: 18th Feb 2018 (co-located with NDSS 2018)
Abstract submissions: 1st Dec 2017 anywhere-on-earth
Paper submission: 8th Dec 2017 anywhere-on-earth
Notifications and invitations to present at the workshop: 13th Jan 2018
Submissions may be new papers, papers already published, Short Papers, or
Position Papers. Also, please contact the TPC chairs if you want to
suggest a panel.
Allison, Sara and Melinda.
---
*Workshop on DNS Privacy 2018*
Background
-----------------
DNS Privacy has been a growing concern of the IETF and others in the Internet engineering community for the last few years. Almost every activity on the Internet starts with a DNS query (and often several).
* Those queries can reveal not only what websites an individual visits but also metadata about other services such as the domains of email contacts or chat services. ?
* Whilst the data in the DNS is public, individual DNS transactions made by an end user should not be public.?
* Today, however DNS queries are sent in clear text (using UDP or TCP) which means passive eavesdroppers can observe all the DNS lookups performed.?
* The DNS is a globally distributed system that crosses international boundaries and often uses servers in many different countries in order to provide resilience.?
* It is well known that the NSA used the MORECOWBELL tool to perform mass surveillance of DNS traffic, and other surveillance techniques involving DNS almost certainly are in play today. ?
* Some ISPs embed user information (e.g. a user ID or MAC address) within DNS queries that go to the ISP?s resolver in order to provide services such as Parental Filtering. This allows for fingerprinting of individual users.?
* Some CDNs embed user information (e.g. client subnets) in queries from resolvers to authoritative servers (to geo-locate end users). This allows for correlation of queries to particular subnets.?
* Some ISPs log DNS queries at the resolver and share this information with third-parties in ways not known or obvious to end users.
The IETF's DPRIVE Working Group has taken initial protocol steps to address these concerns (with much of the early work focussing on the stub to resolver problem), publishing DNS Privacy Considerations (RFC 7626), Specification for DNS over Transport Layer Security (RFC 7858), and The EDNS(0) Padding Option (RFC 7830), and DNS Query Name Minimisation to Improve Privacy (RFC 7816). However because of the great diversity of the DNS ecosystem, and the pervasive role of DNS and domain names in Internet applications and security, much is not fully understood or resolved.
The goal of this workshop is to bring together privacy and Internet researchers with a diversity of backgrounds and views, to identify promising long-term mitigations of the broad space of DNS privacy risks.
Call for Submissions
-----------------------------
We welcome submissions in the form of research papers, short papers, or draft presentations, concerning all aspects of the threats, the protocols, and future design spaces, of DNS privacy or the privacy of adjacent protocols. Usability, traceability, measurement and analytical evaluations are particularly encouraged.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20171009/d05e806b/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
dns-operations mailing list
dns-operations at lists.dns-oarc.net<mailto:dns-operations at lists.dns-oarc.net>
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
------------------------------
End of dns-operations Digest, Vol 141, Issue 12
***********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20171009/bd91fde8/attachment.html>
More information about the dns-operations
mailing list