[dns-operations] dns-operations Digest, Vol 141, Issue 12

Baalakrishnan Nadar mbkrishnan at gmail.com
Mon Oct 9 19:13:57 UTC 2017


Dear All,

We see huge delay from k.gtld-servers.net and few other gtld root servers
to respond.

~]$ dig +trace google.com


;; global options: +cmd

.                       72028   IN      NS      b.root-servers.net.

.                       72028   IN      NS      h.root-servers.net.

.                       72028   IN      NS      e.root-servers.net.

.                       72028   IN      NS      l.root-servers.net.

.                       72028   IN      NS      f.root-servers.net.

.                       72028   IN      NS      c.root-servers.net.

.                       72028   IN      NS      i.root-servers.net.

.                       72028   IN      NS      j.root-servers.net.

.                       72028   IN      NS      d.root-servers.net.

.                       72028   IN      NS      k.root-servers.net.

.                       72028   IN      NS      a.root-servers.net.

.                       72028   IN      NS      m.root-servers.net.

.                       72028   IN      NS      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.

com.                    172800  IN      NS      b.gtld-servers.net.

com.                    172800  IN      NS      c.gtld-servers.net.

com.                    172800  IN      NS      d.gtld-servers.net.

com.                    172800  IN      NS      e.gtld-servers.net.

com.                    172800  IN      NS      f.gtld-servers.net.

com.                    172800  IN      NS      g.gtld-servers.net.

com.                    172800  IN      NS      h.gtld-servers.net.

com.                    172800  IN      NS      i.gtld-servers.net.

com.                    172800  IN      NS      j.gtld-servers.net.

com.                    172800  IN      NS      k.gtld-servers.net.

com.                    172800  IN      NS      l.gtld-servers.net.

com.                    172800  IN      NS      m.gtld-servers.net.

;; Received 488 bytes from 192.58.128.30#53(192.58.128.30) in 33 ms



google.com.             172800  IN      NS      ns2.google.com.

google.com.             172800  IN      NS      ns1.google.com.

google.com.             172800  IN      NS      ns3.google.com.

google.com.             172800  IN      NS      ns4.google.com.

;; *Received 164 bytes from 192.52.178.30#53(192.52.178.30) in 5964 ms*



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



;; global options: +cmd

.                       71802   IN      NS      e.root-servers.net.

.                       71802   IN      NS      d.root-servers.net.

.                       71802   IN      NS      l.root-servers.net.

.                       71802   IN      NS      c.root-servers.net.

.                       71802   IN      NS      j.root-servers.net.

.                       71802   IN      NS      h.root-servers.net.

.                       71802   IN      NS      m.root-servers.net.

.                       71802   IN      NS      i.root-servers.net.

.                       71802   IN      NS      a.root-servers.net.

.                       71802   IN      NS      k.root-servers.net.

.                       71802   IN      NS      g.root-servers.net.

.                       71802   IN      NS      f.root-servers.net.

.                       71802   IN      NS      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.

net.                    172800  IN      NS      f.gtld-servers.net.

net.                    172800  IN      NS      l.gtld-servers.net.

net.                    172800  IN      NS      a.gtld-servers.net.

net.                    172800  IN      NS      m.gtld-servers.net.

net.                    172800  IN      NS      j.gtld-servers.net.

net.                    172800  IN      NS      b.gtld-servers.net.

net.                    172800  IN      NS      h.gtld-servers.net.

net.                    172800  IN      NS      k.gtld-servers.net.

net.                    172800  IN      NS      g.gtld-servers.net.

net.                    172800  IN      NS      d.gtld-servers.net.

net.                    172800  IN      NS      e.gtld-servers.net.

net.                    172800  IN      NS      i.gtld-servers.net.

;; Received 486 bytes from 192.5.5.241#53(192.5.5.241) in 36 ms



verizon.net.            172800  IN      NS      ns2.verizon.net.

verizon.net.            172800  IN      NS      ns4.verizon.net.

verizon.net.            172800  IN      NS      ns1.verizon.net.

verizon.net.            172800  IN      NS      ns3.verizon.net.

*;; Received 165 bytes from 192.43.172.30#53(192.43.172.30) in 9440 ms*



verizon.net.            604800  IN      A       192.16.31.26

verizon.net.            86400   IN      NS      ns4.verizon.net.

verizon.net.            86400   IN      NS      ns1.verizon.net.

verizon.net.            86400   IN      NS      ns2.verizon.net.

verizon.net.            86400   IN      NS      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>
wrote:

> Send dns-operations mailing list submissions to
>         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
>
> You can reach the person managing the list at
>         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>
> To: 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>
> 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
> ...
>    Name Server: NYCDNS01.US.SOCGEN.COM
>    Name Server: NYCDNS02.US.SOCGEN.COM
>    Name Server: TIGDNS01.SOCGEN.COM
>    Name Server: TIGDNS02.SOCGEN.COM
>
> The registry knows them, of course:
>
> %  dig @a.gtld-servers.net NYCDNS01.US.SOCGEN.COM
> ...
> ;; ADDITIONAL SECTION:
> NYCDNS01.US.SOCGEN.COM. 172800 IN A 162.246.240.1
> nycdns02.US.SOCGEN.COM. 172800 IN A 162.246.241.1
> tigdns01.SOCGEN.COM.    172800 IN A 193.178.155.113
> 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
>
> domain:      ssi.gouv.fr
> nsl-id:      NSL139448-FRNIC
>
> ns-list:     NSL139448-FRNIC
> nserver:     dns1.ssi.gouv.fr [213.56.166.96]
> nserver:     dns2.ssi.gouv.fr [86.65.182.91]
> nserver:     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>
> To: Stephane Bortzmeyer <bortzmeyer at nic.fr>
> Cc: 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>
> 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
>
> $ whois TIGDNS01.SOCGEN.COM
>    Server Name: TIGDNS01.SOCGEN.COM
>    IP Address: 193.178.155.113
>    Registrar: CSC Corporate Domains, Inc.
>    Registrar WHOIS Server: 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>
> To: Stephane Bortzmeyer <bortzmeyer at nic.fr>
> Cc: 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>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Stephane Bortzmeyer <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 'nameserver 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`. 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>  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>
> To: bert hubert <bert.hubert at powerdns.com>
> Cc: 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>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Oct 09, 2017 at 05:15:54PM +0200,
>  bert hubert <bert.hubert at powerdns.com> wrote
>  a message of 18 lines which said:
>
> > $ whois TIGDNS01.SOCGEN.COM
> >    Server Name: TIGDNS01.SOCGEN.COM
> >    IP Address: 193.178.155.113
>
> We apparently use different whois clients:
>
> % whois TIGDNS01.SOCGEN.COM
>
> No match for domain "TIGDNS01.SOCGEN.COM".
>
> % whois -h whois.verisign-grs.com TIGDNS01.SOCGEN.COM
>    Server Name: 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>
> To: Stephane Bortzmeyer <bortzmeyer at nic.fr>
> Cc: DNS Operations <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>
> Content-Type: text/plain; charset=utf-8
>
>
> > On 9 Oct 2017, at 16:22, Stephane Bortzmeyer <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>
> To: Jim Reid <jim at rfc1035.com>
> Cc: Stephane Bortzmeyer <bortzmeyer at nic.fr>, DNS Operations
>         <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>
> Content-Type: text/plain; charset=utf-8
>
> On Mon, Oct 09, 2017 at 04:34:37PM +0100,
>  Jim Reid <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>
> To: 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>
> 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>
> To: Stephane Bortzmeyer <bortzmeyer at nic.fr>
> Cc: DNS Operations <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>
> Content-Type: text/plain; charset=utf-8
>
>
> > On 9 Oct 2017, at 16:41, Stephane Bortzmeyer <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>
> To: 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>
> 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
> 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/20171010/eb440a93/attachment.html>


More information about the dns-operations mailing list