Florian Weimer | 4 May 09:05 2016
Picon

Increasing the number of search path entries in a stub resolver

Our stub resolver currently has a hard limit for 6 search domains that 
can be specified in /etc/resolv.conf.  We are considering lifting that 
limit.  Apparently, this is desirable for deployments which migrate from 
NIS host name lookups to DNS because NIS supports a larger number of 
default domain names (or something equivalent to that).

 From a larger ecosystem perspective, do you think that longer search 
paths would increase resolver load in an unacceptable way?  For example, 
host name lookups with a 10-element search path could easily require 20 
queries.

Thanks,
Florian
Mark Jeftovic | 3 May 17:42 2016
Gravatar

The Use of TTL for IPv4 and IPv6 RRs...

RFC4472 talks about this situation:

example.com.        300    IN    MX     foo.example.com.
      foo.example.com.    300    IN    A      192.0.2.1
      foo.example.com.    100    IN    AAAA   2001:db8::1

and what can happen.

My first reaction was "so keep the TTLs the same then", but that doesn't
guarantee that the A and AAAA RRs will get queried and cached by the
resolver at the same time time, does it?

So even if you do that, you can still run into the situations described
in 4.4.1 and 4.4.2

Right?

- mark

--

-- 
Mark Jeftovic, Founder & CEO, easyDNS Technologies Inc.
Company Website: http://easydns.com
Read my blog: http://markable.com
+1-416-535-8672 ext 225
Wessels, Duane | 2 May 23:58 2016
Picon

CFP: DNS Track at NANOG 67

Greetings,

NANOG 67 takes place June 11-13 in Chicago.  I'm looking for folks willing to give brief presentations
during a proposed DNS Track.  Possible topics include:

- Operational experiences
- New & interesting software features
- Protocol advancements
- Research results
- Performance & compliance testing
- Insights into DNS-related attacks

I'm expecting to have about 90 minutes to fill with presentations of about 15 minutes or less.  If you're
interested in presenting please respond to me directly.

Duane W.

Greetings,

NANOG 67 takes place June 11-13 in Chicago.  I'm looking for folks willing to give brief presentations
during a proposed DNS Track.  Possible topics include:

- Operational experiences
- New & interesting software features
- Protocol advancements
- Research results
- Performance & compliance testing
- Insights into DNS-related attacks
(Continue reading)

Paul Vixie | 30 Apr 19:32 2016

Re: HTTP SRV, was Adding CNAME for the root domain issue


Tony Finch wrote:
> ...
> _imap._tcp.example.com. SRV target.example.net.
>
> The client requires two round trips, first to query for example.com,
> second to query for target.example.net. It can't eliminate the second
> round trip because it doesn't know the target name until after the first
> round trip, and it can't rely on the additional data being complete.

as with mx, the additional data both need not be complete, and mostly is.

need not be, because if there are any [AAAA | A] RRsets matching the SRV 
target name in the additional section, and using them results in 
success, then there is no worry as to whether there are other [AAAA | A] 
RRsets that were not included.

mostly is, because the SRV target is often in the same zone, so barring 
truncation, the [AAAA | A] RRsets will already be in cache since they 
will have been sent with the cache miss response.

pragmatically speaking, if an SRV client sees only one RRset (AAAA 
alone, or A alone) it can query for the one it didn't receive. negative 
caching does the rest. CDN's (low AAAA/A TTL, or ECS) fold in nicely in 
this model, since the missing RRsets are either popular, or they aren't.

--

-- 
P Vixie
Warren Kumari | 29 Apr 22:17 2016
Picon
Gravatar

Big Data: A nine hour miniseries radio play about stealing the KSK?

... or something?!
A nine hour radio play miniseries about seven thieves, seven keys, and the heist to steal the internet.

From the page: 
"As soon as I heard the true story of the seven keys to the internet, I knew that it would make an amazing series of heists. Did you know that IN REAL LIFE, in order to make sure no one person or country has too much control over the internet, there are seven people from seven parts of the world with keys to control it? As I researched deeper, I learned that it's actually much more complicated than that, but that just made the story more interesting. I'm using what I learned as an excuse to tell a series of crime stories, taking place all over the world... ranging from hijacking top secret military satellites, to stealing a dude's pants. It's a story about how hacking affects our world... but without a single actual hacker anywhere to be found."

Not affiliated in any way, I just stumbled across this.
Weird.
W
<div><div dir="ltr">
<div>... or something?!</div>
<div>
<span>From Kickstarter:&nbsp;</span><a href="https://www.kickstarter.com/projects/ryanestrada/big-data-0">https://www.kickstarter.com/projects/ryanestrada/big-data-0</a><span>&nbsp;</span><br>
</div>
<div><span>A nine hour radio play miniseries about seven thieves, seven keys, and the heist to steal the internet.</span></div>
<div><span><br></span></div>
<div><span>From the page:&nbsp;</span></div>
<div>
<span>"</span>As soon as I heard the true story of the seven keys to the internet, I knew that it would make an amazing series of heists. Did you know that IN REAL LIFE, in order to make sure no one person or country has too much control over the internet, there are seven people from seven parts of the world with keys to control it? As I researched deeper, I learned that it's actually much more complicated than that, but that just made the story more interesting. I'm using what I learned as an excuse to tell a series of crime stories, taking place all over the world... ranging from hijacking top secret military satellites, to stealing a dude's pants. It's a story about how hacking affects our world... but without a single actual hacker anywhere to be found."</div>
<div><br></div>
<div>Not affiliated in any way, I just stumbled across this.</div>
<div>Weird.</div>
<div>W</div>
</div></div>
Matthew Pounsett | 27 Apr 18:29 2016

Re: Adding CNAME for the root domain issue


Moving this from bind-users to dns-operations.


On 27 April 2016 at 09:00, Sam Wilson <Sam.Wilson-5WhEfG1TI8k@public.gmane.org> wrote:
In article <mailman.633.1461768150.73610.bind-users-/1rEenAg/5e+51mZqJFLXQ@public.gmane.org>,
 "Baird, Josh" <jbaird-K+8Q3E3ekwRBDgjK7y7TUQ@public.gmane.org> wrote:

> Any thoughts on a service like Cloudfare's 'CNAME Flattening' [1]?
>
> [1]
> https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/

<delurk>
Does anyone else find themselves mentally yelling "apex!" whenever they
read the word "root" in that document?
</delurk>

There are a huge number of problems with that document's use of terms, and the way it presents  its information.  Those problems only begin with using "root" in place of "apex".

The document also presents the whole CNAME at apex problem as if it's really fine to do, and only breaks down because a few people don't support it properly. 

"Technically, the root [APEX!] could be a CNAME but the RFCs state that once a record has a CNAME it can't have any other entries associated with it: that's a problem for a root [APEX!] record like example.com because it will often have an MX record (so email gets delivered), an NS record (to find out which nameserver handles the zone) and an SOA record."

Actually, no.  "Technically", it cannot be a CNAME, because the technical specification says it can't.   And the reason it says it can't is because having a CNAME and any other data is ambiguous.  This paragraph presents it as if the rule is just arbitrary, and has no real justification.

It goes on to explain one of the cases where CNAME at apex breaks down (the MS Exchange issue) but frames it as if it's sortof Microsoft's fault that doesn't work, if only they hadn't been following the specification so closely.

The other "corner cases" it hand-waves around include nice things like potential DoS of entire domains with CNAMEs at their apex.  For example, three queries to Google DNS will cause Google to start returning SERVFAIL for future queries of that domain, if the auth server actually responds with a CNAME at the apex of the zone. (I will leave which queries as an exercise for the reader).  The DoS only lasts for the TTL of the CNAME, but it can be reset at will by the attacker.

(To be clear, I don't consider that to be a bug or security flaw in Google Public DNS, but simply an example of the unintended consequences of trying to use an ambiguous, illegal configuration.)

What Cloudflare is doing with their CNAME flattening service is quite good, but that document is a terrible marketing representation of what is an excellent technical implementation if a kludge we all have to live with.


<div><div dir="ltr">
<div><br></div>
<div>Moving this from bind-users to dns-operations.</div>
<br><div class="gmail_extra">
<br><div class="gmail_quote">On 27 April 2016 at 09:00, Sam Wilson <span dir="ltr">&lt;<a href="mailto:Sam.Wilson@..." target="_blank">Sam.Wilson@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<span class="">In article &lt;<a href="mailto:mailman.633.1461768150.73610.bind-users@...">mailman.633.1461768150.73610.bind-users@...</a>&gt;,<br>
&nbsp;"Baird, Josh" &lt;<a href="mailto:jbaird@...">jbaird@...</a>&gt; wrote:<br><br>
&gt; Any thoughts on a service like Cloudfare's 'CNAME Flattening' [1]?<br>
&gt;<br>
&gt; [1]<br>
&gt; <a href="https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/" rel="noreferrer" target="_blank">https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/</a><br><br></span>&lt;delurk&gt;<br>
Does anyone else find themselves mentally yelling "apex!" whenever they<br>
read the word "root" in that document?<br>
&lt;/delurk&gt;<br><br>
</blockquote>
<div>There are a huge number of problems with that document's use of terms, and the way it presents &nbsp;its information.&nbsp; Those problems only begin with using "root" in place of "apex".</div>
<div><br></div>
<div>The document also presents the whole CNAME at apex problem as if it's really fine to do, and only breaks down because a few people don't support it properly.&nbsp;</div>
<div><br></div>
</div>
</div>
<blockquote><div class="gmail_extra"><div class="gmail_quote"><div><div>"Technically, the root [APEX!] could be a CNAME but the RFCs state that once a record has a CNAME it can't have any other entries associated with it: that's a problem for a root [APEX!] record like <a href="http://example.com">example.com</a> because it will often have an MX record (so email gets delivered), an NS record (to find out which nameserver handles the zone) and an SOA record."</div></div></div></div></blockquote>
<div class="gmail_extra">
<div class="gmail_quote"><div><br></div></div>Actually, no. &nbsp;"Technically", it cannot be a CNAME, because the technical specification says it can't. &nbsp; And the reason it says it can't is because having a CNAME and any other data is ambiguous.&nbsp; This paragraph presents it as if the rule is just arbitrary, and has no real justification.</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">It goes on to explain one of the cases where CNAME at apex breaks down (the MS Exchange issue) but frames it as if it's sortof Microsoft's fault that doesn't work, if only they hadn't been following the specification so closely.</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">The other "corner cases" it hand-waves around include nice things like potential DoS of entire domains with CNAMEs at their apex.&nbsp; For example, three queries to Google DNS will cause Google to start returning SERVFAIL for future queries of that domain, if the auth server actually responds with a CNAME at the apex of the zone. (I will leave which queries as an exercise for the reader).&nbsp; The DoS only lasts for the TTL of the CNAME, but it can be reset at will by the attacker.</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">(To be clear, I don't consider that to be a bug or security flaw in Google Public DNS, but simply an example of the unintended consequences of trying to use an ambiguous, illegal configuration.)</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">What Cloudflare is doing with their CNAME flattening service is quite good, but that document is a terrible marketing representation of what is an excellent technical implementation if a kludge we all have to live with.</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra"><br></div>
</div></div>
Julie Hedlund | 27 Apr 16:51 2016
Picon

Call for Participation -- ICANN DNSSEC Workshop at ICANN 56 in Helsinki, Finland

Call for Participation -- ICANN DNSSEC Workshop at ICANN 56 in Helsinki, Finland

The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop at the ICANN 56 meeting on 27 June 2016 in Helsinki, Finland.  The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments.  For reference, the most recent session was held at the ICANN meeting in Marrakech, Morocco on 09 March 2016. The presentations and transcripts are available at:  https://meetings.icann.org/en/marrakech55/schedule/wed-dnssec.

Examples of the types of topics we are seeking include:

1. DNSSEC Deployment Challenges

The program committee is seeking input from those that are interested in implementation of DNSSEC but have general or particular concerns with DNSSEC.  In particular, we are seeking input from individuals that would be willing to participate in a panel that would discuss questions of the nature:
— What are your most significant concerns with DNSSEC, e.g., implementation, operation or something else?
— What do you expect DNSSEC to do for you and what doesn't it do?
— What do you see as the most important trade-offs with respect to doing or not doing DNSSEC?

We are interested in presentations related to any aspect of DNSSEC such as zone signing, DNS response validation, applications use of DNSSEC, registry/registrar DNSSEC activities, etc.

2.  DNSSEC by Default

As more and more applications and systems are available with DNSSEC enabled by default, the vast majority of today’s applications support DNSSEC but are not DNSSEC enabled by default.    Are we ready to enable DNSSEC by default in all applications and services. We are interested in presentations by implementors on the reasoning that led to enable DNSSEC by default in their product or service.  We are also interested in understanding  those that elected not to enable DNSSEC by default and why, and what their plans are.

3. DNSSEC Encryption Algorithms

How do we make DNSSEC even more secure through the use of elliptic curve cryptography? What are the advantages of algorithms based on elliptic curves? And what steps need to happen to make this a reality? What challenges lie in the way?  Over the past few months there have been discussions within the DNSSEC community about how we start down the path toward adding support for new cryptographic algorithms such as Ed25519 and Ed448. At ICANN 55 in Marrakech we had a panel session that explored why elliptic curve cryptography was interesting and some high level views on what needs to happen.  At ICANN 56 we are interested in presentations that dive into greater detail about what needs to be done and how we start the process. More background information can be found in this document: https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/

In addition, we welcome suggestions for additional topics.

If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-helsinki-pYXoxzOOsG8@public.gmane.org by **Wednesday, 18 May 2016**

We hope that you can join us.

Thank you,
Julie Hedlund

On behalf of the DNSSEC Workshop Program Committee:

Mark Elkins, DNS/ZACR
Cath Goulding, Nominet UK
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, CNNIC
Luciano Minuchin, NIC.AR
Russ Mundy, Parsons
Ondřej Surý, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society
Attachment (smime.p7s): application/pkcs7-signature, 6262 bytes
<div>
<div>Call for Participation -- ICANN DNSSEC Workshop at ICANN 56 in Helsinki, Finland</div>
<div><br></div>
<div> The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop at the ICANN 56 meeting on 27 June 2016 in Helsinki, Finland.&nbsp;&nbsp;The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments.&nbsp;&nbsp;For reference, the most recent session was held at the ICANN meeting in Marrakech, Morocco on 09 March 2016. The presentations and transcripts are available at:&nbsp;&nbsp;<a href="https://meetings.icann.org/en/marrakech55/schedule/wed-dnssec">https://meetings.icann.org/en/marrakech55/schedule/wed-dnssec</a>. </div>
<div><br></div>
<div>Examples of the types of topics we are seeking include:</div>
<div> </div>
<div><br></div>
<div>1. DNSSEC Deployment Challenges</div>
<div><br></div>
<div>The program committee is seeking input from those that are interested in implementation of DNSSEC but have general or particular concerns with DNSSEC.&nbsp;&nbsp;In particular, we are seeking input from individuals that would be willing to participate in a panel that would discuss questions of the nature:</div>
<div>&mdash; What are your most significant concerns with DNSSEC, e.g., implementation, operation or something else?</div>
<div>&mdash; What do you expect DNSSEC to do for you and what doesn't it do?</div>
<div>&mdash; What do you see as the most important trade-offs with respect to doing or not doing DNSSEC?</div>
<div><br></div>
<div>We are interested in presentations related to any aspect of DNSSEC such as zone signing, DNS response validation, applications use of DNSSEC, registry/registrar DNSSEC activities, etc.</div>
<div><br></div>
<div> </div>
<div>2.&nbsp;&nbsp;DNSSEC by Default</div>
<div><br></div>
<div>As more and more applications and systems are available with DNSSEC enabled by default, the vast majority of today&rsquo;s applications support DNSSEC but are not DNSSEC enabled by default.&nbsp;&nbsp;&nbsp;&nbsp;Are we ready to enable DNSSEC by default in all applications and services. We are interested in presentations by implementors on the reasoning that led to enable DNSSEC by default in their product or service.&nbsp;&nbsp;We are also interested in understanding&nbsp;&nbsp;those that elected not to enable DNSSEC by default and why, and what their plans are.</div>
<div><br></div>
<div> 3. DNSSEC Encryption Algorithms</div>
<div><br></div>
<div>How do we make DNSSEC even more secure through the use of elliptic curve cryptography? What are the advantages of algorithms based on elliptic curves? And what steps need to happen to make this a reality? What challenges lie in the way?&nbsp;&nbsp;Over the past few months there have been discussions within the DNSSEC community about how we start down the path toward adding support for new cryptographic algorithms such as Ed25519 and Ed448. At ICANN 55 in Marrakech we had a panel session that explored why elliptic curve cryptography was interesting and some high level views on what needs to happen.&nbsp;&nbsp;At ICANN 56 we are interested in presentations that dive into greater detail about what needs to be done and how we start the process. More background information can be found in this document:&nbsp;<a href="https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/">https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/</a>
</div>
<div><br></div>
<div>In addition, we welcome suggestions for additional topics.</div>
<div><br></div>
<div>If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to <a href="mailto:dnssec-helsinki@...">dnssec-helsinki@...</a> by **Wednesday, 18 May 2016**≤/div>
<div><br></div>
<div>We hope that you can join us.</div>
<div><br></div>
<div>Thank you,</div>
<div>Julie Hedlund</div>
<div><br></div>
<div>On behalf of the DNSSEC Workshop Program Committee:</div>
<div><br></div>
<div>Mark Elkins, DNS/ZACR</div>
<div>Cath Goulding, Nominet UK</div>
<div>Jean Robert Hountomey, AfricaCERT</div>
<div>Jacques Latour, .CA</div>
<div>Xiaodong Lee, CNNIC</div>
<div>Luciano Minuchin, NIC.AR</div>
<div>Russ Mundy, Parsons</div>
<div>Ond&#345;ej Sur&yacute;, CZ.NIC</div>
<div>Yoshiro Yoneya, JPRS</div>
<div>Dan York, Internet Society</div>
</div>
Daniel Stirnimann | 22 Apr 19:10 2016
Picon
Gravatar

negative caching weirdness

Dear all,

RFC 2308 defines the negative caching TTL as the minimum of the MINIMUM
field of the SOA record and the TTL of the SOA itself.

I wanted to do a quick survey among all tlds and was surprised to see
that many showed a neg. caching TTL of zero!

Summary:
     1	    666 0
     2	    131 10800
     3	    110 7200
     4	     69 900
     5	     45 3600
     6	     42 300
     7	     35 60
     8	      9 5400
     9	      3 1800
    10	      1 600
    11	      1 1200

One such TLD is haus.

Surprisingly, if I ask the authoritative name server directly I get
86400 seconds:

dig  <at> demand.beta.aridns.net.au. haus. soa

; <<>> DiG 9.8.3-P1 <<>>  <at> demand.beta.aridns.net.au. haus. soa
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32576
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;haus.				IN	SOA

;; ANSWER SECTION:
haus.			86400	IN	SOA	demand.alpha.aridns.net.au.
hostmaster.rightside.co. 1461326169 1800 900 604800 86400

;; Query time: 23 msec
;; SERVER: 2001:dcd:2::7#53(2001:dcd:2::7)
;; WHEN: Fri Apr 22 14:00:47 2016
;; MSG SIZE  rcvd: 107

However, if I ask for an unknown domain I get zero!

dig  <at> demand.beta.aridns.net.au. alsdfjalsjdfasdf.haus. soa

; <<>> DiG 9.8.3-P1 <<>>  <at> demand.beta.aridns.net.au.
alsdfjalsjdfasdf.haus. soa
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43473
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;alsdfjalsjdfasdf.haus.		IN	SOA

;; AUTHORITY SECTION:
haus.			0	IN	SOA	demand.alpha.aridns.net.au. hostmaster.rightside.co.
1461326169 1800 900 604800 86400

;; Query time: 22 msec
;; SERVER: 2001:dcd:2::7#53(2001:dcd:2::7)
;; WHEN: Fri Apr 22 14:00:55 2016
;; MSG SIZE  rcvd: 124

Even stranger is, if I ask my local resolver (BIND 9.9.8) I get 10800:

dig wersadfjlasjdlfjasljdflajs.haus

; <<>> DiG 9.8.3-P1 <<>> wersadfjlasjdlfjasljdflajs.haus
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53730
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;wersadfjlasjdlfjasljdflajs.haus. IN	A

;; AUTHORITY SECTION:
haus.			10800	IN	SOA	demand.alpha.aridns.net.au.
hostmaster.rightside.co. 1461326409 1800 900 604800 86400

;; Query time: 26 msec
;; SERVER: 130.59.31.248#53(130.59.31.248)
;; WHEN: Fri Apr 22 14:02:25 2016
;; MSG SIZE  rcvd: 134

I'm completely confused. I never expected that 666 TLDs have such
strange behaviors or am I missing something?

Thank you,
Daniel
Stephane Bortzmeyer | 21 Apr 20:20 2016
Picon

QNAME minimisation in Wikipedia

Wikipedia explains the DNS resolution, assuming everyody uses RFC 7816
:-)

https://en.wikipedia.org/wiki/Root_name_server#Resolver_operation

"A resolver breaks the name up into its labels from right to left. The
first component (TLD) is queried using a root server to obtain the
responsible authoritative server."
Brett | 20 Apr 14:54 2016
Picon

Passing card data through the DNS

Ok again it's from the tabloid end of the Internet but I thought some
of you may be interested in this:

http://www.theregister.co.uk/2016/04/20/vxers_pass_stolen_card_data_over_dns/

--

-- 
Brett
Robert | 20 Apr 03:31 2016

strange policy on amazon DNS setting

Hi,

 From a host within China I got the NS records for amazon.cn,

amazon.cn.              499     IN      NS      ns4.p31.dynect.net.
amazon.cn.              499     IN      NS      ns1.p31.dynect.net.
amazon.cn.              499     IN      NS      u2.amazon.com.
amazon.cn.              499     IN      NS      ns1.dynect.cn.
amazon.cn.              499     IN      NS      ns2.dynect.net.cn.
amazon.cn.              499     IN      NS      ns2.dynect.cn.
amazon.cn.              499     IN      NS      u5.amazon.cn.
amazon.cn.              499     IN      NS      ns2.p31.dynect.net.
amazon.cn.              499     IN      NS      ns3.p31.dynect.net.
amazon.cn.              499     IN      NS      ns1.dynect.net.cn.

But from a host out of China (the US) I got the results,

kindle.cn.              900     IN      NS      u2.amazon.com.

(only one NS RR)

How and why does amazon's DNS setting behave as this? Thanks.

robert.

Gmane