Sadiq Saif | 27 Feb 06:02 2015

Mozilla Firefox and ANY queries

Hi all,

Checking local resolver logs and am seeing a large amount of ANY queries
originating from Firefox, is anybody else seeing such behavior?

Firefox version 36.0 on Windows 8.1
Local resolver is Unbound 1.4.22.

Feb 27 04:57:54 unbound[1405:1] info: 10.0.0.100
googlemail.l.google.com. ANY IN
Feb 27 04:57:54 unbound[1405:2] info: 10.0.0.100
googlemail.l.google.com. ANY IN
Feb 27 04:58:05 unbound[1405:0] info: 10.0.0.100 clients.l.google.com.
ANY IN
Feb 27 04:58:05 unbound[1405:2] info: 10.0.0.100
googlemail.l.google.com. ANY IN
Feb 27 04:58:15 unbound[1405:1] info: 10.0.0.100
googlemail.l.google.com. ANY IN

Amongst others.

--

-- 
Sadiq Saif
https://staticsafe.ca
Stephane Bortzmeyer | 25 Feb 16:31 2015
Picon

[dns-privacy] Start of WGLC for draft-ietf-dprive-problem-statement - please review.

This work on DNS privacy is now in IETF Working Group Last Call. May
be some people from the operations crowd may be interested to review
it?

If you have remarks to do, you can send them directly to me or use the
Github issue system. But, in most cases, it is better to use the IETF
system: send an email to dns-privacy@... If you are not used to
IETF processes, it is probably a good idea to read the Tao
<http://www.ietf.org/tao.html> first.

Picon
From: Warren Kumari <warren@...>
Subject: [dns-privacy] Start of WGLC for draft-ietf-dprive-problem-statement - please review.
Date: 2015-02-23 22:36:28 GMT
Dear DPRIVE WG,

The authors of draft-ietf-dprive-problem-statement have indicated that
they believe that the document is ready, and have asked for Working
Group Last Call.

The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-problem-statement/

This document was discussed at the DPRIVE meeting at IETF91 - some
(Continue reading)

BARRY GREENE | 17 Feb 01:55 2015

Anyone with DNS APN architect experience?

Hi Team,

I'm looking for some people who have do the architecture work on the 3GPP APN DNA elements. Please reply off-line.

Thanks,

Barry

Hi Team,

I'm looking for some people who have do the architecture work on the 3GPP APN DNA elements. Please reply off-line.

Thanks,

Barry

Mark E. Jeftovic | 14 Feb 18:15 2015

behaviour of nameserver glue recs and TTL in referrals


Is the ADDITIONAL section the functional equivalent of the ANSWER
section in TLD roots now that most of them give out referrals when
queried for glue? Or would it only be used if the resolver can't
otherwise find the glue?

Where does the TTL come from in the ADDITIONAL section and can it be
modified by the superdomain operator of the nameserver?

In other words:

Marks-MacBook-Pro:~ markjeftovic1$ dig +norec ns6.zoneedit.co.uk  <at> ns1.nic.uk

; <<>> DiG 9.8.5-P1 <<>> +norec ns6.zoneedit.co.uk  <at> ns1.nic.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35872
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; QUESTION SECTION:
;ns6.zoneedit.co.uk.		IN	A

;; AUTHORITY SECTION:
zoneedit.co.uk.		172800	IN	NS	ns6.zoneedit.co.uk.
zoneedit.co.uk.		172800	IN	NS	ns1.zoneedit.com.
zoneedit.co.uk.		172800	IN	NS	ns3.zoneedit.com.
zoneedit.co.uk.		172800	IN	NS	ns2.zoneedit.com.

;; ADDITIONAL SECTION:
ns6.zoneedit.co.uk.	172800	IN	A	166.88.18.59
(Continue reading)

Roland Dobbins | 11 Feb 06:15 2015
Picon

I'd be grateful if someone from Time-Warner Telecom could contact me 1:1.


Thanks much!

-----------------------------------
Roland Dobbins <rdobbins@...>
bert hubert | 10 Feb 12:02 2015
Picon

Root-servers returning TC=1 after 5 NXDOMAINS

Hi everybody,

Recently at a large deployment, we ran into f.root-servers.net returning
TC=1 to all our queries. We took this up with ISC who quickly informed us
that this is a setting they run with if you exceed more than 5 NXDOMAIN
responses/s. 

The installation in question services millions of subscribers, and sadly
gets a lot of silly queries which leak to the root. We're unsure how to 
stay below 5 NXDOMAINs/s permanently.

You can reproduce this behaviour like this:

$ for a in {1..10}; do dig www.no-such-tld-$a -4  <at> f.root-servers.net ; done > log
$ grep -E 'TCP|status:' l
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54154
(...)
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4798
;; Truncated, retrying in TCP mode.
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1549

We've since tried to curtail our queries to the root severly, but we still
get TC=1 responses a lot, which slows down our resolution.

We shared our concerns with ISC, but it might be good to have a broader
discussion on if it makes sense to set the bar so very low.

Your thoughts would be appreciated!

	Bert
(Continue reading)

Brett | 9 Feb 16:34 2015
Picon

Python or Ruby

I find myself thinking that perhaps I should attempt to learn a modern scripting language and seem to of settled on the choice of Ruby or Python (though I could probably still be swayed elsewhere if something else was a better fit) Given that the majority of my work has a DNS slant on it somewhere I wondered what you guys experiences/preferences were in this area. They of course have some kind of DNS library but I wondered how many of you had used them and whether your experiences had been good/bad in either direction.

Thanks

--
Brett
<div><div dir="ltr">I find myself thinking that perhaps I should attempt to learn a modern scripting language and seem to of settled on the choice of Ruby or Python (though I could probably still be swayed elsewhere if something else was a better fit) Given that the majority of my work has a DNS slant on it somewhere I wondered what you guys experiences/preferences were in this area. They of course have some kind of DNS library but I wondered how many of you had used them and whether your experiences had been good/bad in either direction.<div><br></div>
<div>Thanks<br clear="all"><div><br></div>-- <br><div class="gmail_signature">Brett</div>
</div>
</div></div>
Gihan Dias | 9 Feb 15:34 2015

self introduction

Hello,

I'm Gihan Dias, from the LK Domain Regsitry, Sri Lanka.

Gihan
Matt Calder | 3 Feb 22:09 2015
Picon

Understanding duplicate DNS requests

Apologies, I am very new to DNS administration. My issue is that I have HTTP resource hostnames which are distinct across webpage accesses but are being resolved multiple times, often from LDNS resolvers in different networks. I am trying to understand why this is happening.

I have a webpage that contains a resource with a unique hostname for each page load that used for some Javascript performance profiling. The hostname is made unique with a standard GUID. During the measurement, the browser should resolve the resource twice; once to induce DNS resolution and the second time to measure performance, assuming the DNS resolution is cached and doesn’t contribute to the end-to-end timing from our measurement.

In my authoritative DNS logs, I see that there are many duplicate requests coming in for the same unique hostname. The A record TTL is short, only a few minutes and duplicate requests usually happen within seconds of each other. Sometime there are just a few extra, sometimes 10-15. Ideally, I would see only a single request per GUID, but at the moment only 51% of GUIDs see a single request from a single LDNS server. There are a few different patterns I’ve narrowed down and now I’m trying to understand what the possible causes of these duplicate requests are. In some examples, I use specific ISP names but these patterns are pretty common.

Case 1.

LDNS servers resolving the same GUID hostname are in different networks. In one case, 3/4 of the duplicates DNS requests come from an AT&T LDNS, the others were from COX.

Case 2. 

In all duplicate requests, all LDNS IPs are distinct and belong to Comcast but in different Comcast ASNs. 

Case 3. 

Many duplicate requests, all LDNS IPs are the same. 

Case 4.

Duplicate request once an hour through the same LDNS. This continues for days. 


Hypothesis I’ve imagined so far.

  • DNS response packets are lost on their way back to the LDNS or to client so are re-requested
  • An LDNS may resolve on their own while also forwarding requests to load balanced counterparts or upstream/downstream resolvers to sync caches.  
  • Browser/OS DNS cache is full/broken/non-existant so the measurement URLs are re-queried even after the warmup URLs.
  • Case 4 just seems like a straight up misbehaving resolver.

If it helps, I am running BIND 9.9.6. 

Appreciate any help! Thanks.

<div><div dir="ltr">

<p class="">Apologies,&nbsp;I am very new to DNS administration. My issue is that&nbsp;I have HTTP resource hostnames which are distinct across webpage accesses but are being resolved multiple times, often from LDNS resolvers in different networks.&nbsp;I am trying to understand why this is happening.</p>
<p class="">I&nbsp;have a webpage that&nbsp;contains a resource&nbsp;with a unique hostname for each page load that used for some Javascript performance profiling. The hostname is made unique with a standard GUID. During the measurement, the browser should resolve the resource twice; once to induce DNS resolution and the second time to measure performance, assuming the DNS resolution is cached and doesn&rsquo;t contribute to the end-to-end timing from our measurement.</p>
<p class="">In my authoritative DNS logs,&nbsp;I&nbsp;see that there are many duplicate requests coming in for the same unique hostname. The A record TTL is short, only a few minutes and duplicate requests usually happen within seconds of each other. Sometime there are just a few extra, sometimes 10-15.&nbsp;Ideally,&nbsp;I would see only a single request per GUID, but at the moment only 51% of GUIDs see a single request from a single LDNS server. There are a few different patterns&nbsp;I&rsquo;ve narrowed down and now&nbsp;<span class="">I&rsquo;m trying to understand what the possible causes of these duplicate requests are. In some examples, I use specific ISP names but these patterns are pretty common.</span></p>
<p class="">Case 1.</p>
<p class="">LDNS servers resolving the same GUID hostname are in different networks. In one case, 3/4 of the duplicates DNS requests come from an AT&amp;T LDNS, the others were from COX.</p>
<p class="">Case 2.&nbsp;</p>
<p class="">In all duplicate requests, all LDNS IPs are distinct and belong to Comcast but in different Comcast ASNs.&nbsp;</p>
<p class="">Case 3.&nbsp;</p>
<p class="">Many duplicate requests, all LDNS IPs are the same.&nbsp;</p>
<p class="">Case 4.</p>
<p class="">Duplicate request once an hour through the same LDNS. This continues for days.&nbsp;</p>
<p class=""><br></p>
<p class="">Hypothesis I&rsquo;ve imagined so far.</p>
<ul class="">
<li class="">DNS response packets are lost on their way back to the LDNS or to client so are re-requested</li>
<li class="">An LDNS may resolve on their own while also forwarding requests to load balanced counterparts or upstream/downstream resolvers to sync caches. &nbsp;</li>
<li class="">Browser/OS DNS cache is full/broken/non-existant so the measurement URLs are re-queried even after the warmup URLs.</li>
<li class="">Case 4 just seems like a straight up misbehaving resolver.</li>
</ul>
<p class="">If it helps, I am running BIND 9.9.6.&nbsp;</p>
<p class="">Appreciate any help! Thanks.</p>
</div></div>
Marek Vavruša | 3 Feb 17:54 2015
Picon

Evaluating resolver performance

Hi,

does anyone have any experiences with benchmarking recursors?
From what I understand, the DNS Rex is pretty much dead and resperf is
the only thing widely used.
What I don't like is that it leaks messages to Internet instead of
faking DNS hierarchy on a local interface, thus making the results
unreliable. Is there anything else I'm missing?

Thanks again,
Marek
Stephane Bortzmeyer | 1 Feb 20:33 2015
Picon

The Sichuan pepper attack: turning a DNS censorship system into a dDoS vector

We all know that the chinese network intercepts DNS requests and
returns fake answers <http://cs.nyu.edu/~pcw216/work/nds/final.pdf>
<http://research.dyn.com/2010/03/fouling-the-global-nest/>
<https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005340.html>
<http://arstechnica.com/tech-policy/2010/03/china-censorship-leaks-outside-great-firewall-via-root-server/>.
Until recently, the addresses returned were non existing or even non
routable (class E addresses...) so there was little harm outside of
China even if, in a few cases, censorship leaked outside.

Now, it seems there is a change since many sites report being hit by
HTTP traffic coming from China and carrying Host: for censored sites
like www.facebook.com, turning every chinese citizen who wants to see
Facebook (sometimes indirectly, e.g. through a Like button) into an
involuntary accomplice of the dDoS attack.

Seen from the victim:

http://furbo.org/2015/01/22/fear-china/
https://benjamin.sonntag.fr/DDOS-on-La-Quadrature-du-Net-analysis
http://blog.sucuri.net/2015/01/ddos-from-china-facebook-wordpress-and-twitter-users-receiving-sucuri-error-pages.html

Seen from China:

https://en.greatfire.org/blog/2015/jan/gfw-upgrade-fail-visitors-blocked-sites-redirected-porn

PassiveDNS.cn (search by rdata) confirms that the IP address of the
small Web site appeared in the right-hand side of facebook.com,
youtube.com, and many others. A lot of HTTP traffic, 99 % coming from
China, was the result, with URL paths clearly intended for Facebook.


Gmane