Subject: [DNSOP] Masataka Ohta's 2004 draft...

From: David Conrad <[email-masked]>
Date: Tue, 22 Jul 2014 10:22:52 -0400

Since I mentioned it and some folks said "where is it?":

http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jul 2014 20:57:02 +0900

> http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03

In what context, did you mention it?

						Masataka Ohta

---

From: Hector Santos <[email-masked]>
Date: Wed, 23 Jul 2014 08:37:49 -0400

> In what context, did you mention it?

I'm interested to know.

Maybe a coincidence..... The NULL MX specifications defines a NULL MX 
record setup:

    Exchange  : "."  (root)
    Preference: 0

What has been crossing my mind regarding this NULL MX setup, was the 
possible privacy issue with NULL MX root domain "Traceability" aspect 
with legacy MTAs performing SMTP "Implicit MX" (No MX record, Fallback 
to A record) logic.   What will the A query IP resolved to when the 
exchange points to the root?

(Pete, Dave, this is my only question/concern, if real, about the NULL 
MX proposal)

-- 
HLS

---

From: David Conrad <[email-masked]>
Date: Wed, 23 Jul 2014 08:39:28 -0400

Masataka,

> In what context, did you mention it?

I asked if the authors had compared their draft (http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00) to yours.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 23 Jul 2014 09:11:54 -0400

Hector,

On Jul 23, 2014, at 8:37 AM, Hector Santos <[email-masked]> wrote:
> Maybe a coincidence..... The NULL MX specifications defines a NULL MX record setup:

I think this is unrelated.  The context was in discussions relating to alternative mechanisms for obtaining root name service.

Regards,
-drc

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Jul 2014 14:46:53 +0100

Hector Santos <[email-masked]> wrote:
>
> What has been crossing my mind regarding this NULL MX setup, was the possible
> privacy issue with NULL MX root domain "Traceability" aspect with legacy MTAs
> performing SMTP "Implicit MX" (No MX record, Fallback to A record) logic.
> What will the A query IP resolved to when the exchange points to the root?

Null MX records suppress fallback-to-A. The target "." does not have any A
records. http://www.ietf.org/mail-archive/web/dnsop/current/msg12153.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Westerly or southwesterly in far southeast, otherwise northerly, 4
or 5, increasing 6 or 7 later in southeast. Slight or moderate, occasionally
rough later. Mainly fair. Moderate or good.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jul 2014 23:22:55 +0900

> I asked if the authors had compared their draft (http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00) to yours.

Hmmmmm, the draft inappropriately assumes having a lot of
anycast addresses is better even though several ones are
enough.

But, the following statement in the draft:

> However, the costs of using TCP rather than
> UDP, in terms of system and network resources, are much higher and
> can have significant impact on systems such as name servers that may
> receive several thousands of queries per second during normal
> operations.

is more disturbing to me.

Does "several thousands of queries per second during normal
operations" with TCP matter?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jul 2014 23:36:18 +0900

> exchange points to the root?

If millions of anycast root servers without a centralized
administrator are distributed world wide, it makes it
difficult for NSA monitor queries to all the root servers,
because of massive number of them.

And, it's not just for NULL MX. Many queries go to the root
servers.

						Masataka Ohta

PS

OTOH, queries to 8.8.8.8 administrated by google are easy
victims of NSA.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 23 Jul 2014 16:57:22 +0200

>  operations" with TCP matter?

=> yes because it is at the limit current OSs can do on cheap stock
hardware...

Regards

[email-masked]

PS: I wrote OS because the first reached perf limit is in the kernel,
not in the DNS server. And if you argue Web servers support far more,
the TCP DNS issue is the server should close connections only after
a timeout...

---

From: Hector Santos <[email-masked]>
Date: Wed, 23 Jul 2014 11:48:29 -0400

> On Jul 23, 2014, at 9:46 AM, Tony Finch <[email-masked]> wrote:
> 

So by "suppress" you mean, for the vast wide field of "Null MX" ignorant MTAs,  a positive return of a MX record with a preference of zero, a blind A lookup of "." returns an 0 ip value and this causes an inherent cancellation, "suppression" of the outbound attempt?  

I can understand how a supportive MTA can leverage it, but I was thinking what the impact might be for the legacy MTA.

Not all DNS resolvers return the expansion depending on the API and the caching servers in play.

--
Hector Santos
http://www.santronics.com

---

From: Paul Vixie <[email-masked]>
Date: Wed, 23 Jul 2014 10:44:05 -0700

> I asked if the authors had compared their draft (http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00) to yours.

this author isn't in toronto so i'll answer here-- i had not and have
not compared -lee-dnsop-scalingroot- to -ohta-shared-root-.

vixie

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Jul 2014 13:17:32 +1000

In message <[email-masked]>, Hector Santos write
s:
> So by "suppress" you mean, for the vast wide field of "Null MX" ignorant MTAs
> ,  a positive return of a MX record with a preference of zero, a blind A look
> up of "." returns an 0 ip value and this causes an inherent cancellation, "su
> ppression" of the outbound attempt?  

To me "returns an 0 ip value" means 0.0.0.0 which is incorrect.

The lookup returns no ip addresses (unless some locally is overriding
the usual result) and without a IP address no connection attempts
will be made.  A negative caching nameserver will cache this for several
hours (up to 24) depending upon how it is configured.  For named 3 hours
is the defaul max-ncache-ttl.

; <<>> DiG 9.11.0pre-alpha <<>> a .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31874
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	A

;; AUTHORITY SECTION:
.			10800	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2014072301 1800 900 604800 86400

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 24 13:09:20 EST 2014
;; MSG SIZE  rcvd: 103

; <<>> DiG 9.11.0pre-alpha <<>> aaaa .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61938
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	AAAA

;; AUTHORITY SECTION:
.			10800	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2014072301 1800 900 604800 86400

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 24 13:09:31 EST 2014
;; MSG SIZE  rcvd: 103

> I can understand how a supportive MTA can leverage it, but I was thinking wha
> t the impact might be for the legacy MTA.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2014 16:24:25 +0900

Paul Vixie wrote:

Hi,

> not compared -lee-dnsop-scalingroot- to -ohta-shared-root-.

Security consideration section of my draft explains why
allowing all the ISPs run their own anycast root servers
does not make plain DNS less secure.

That is, their is no reason to use DNSSEC for anycast root.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2014 16:31:18 +0900

> => yes because it is at the limit current OSs can do on cheap stock

Are you saying real root servers are using cheap stock hardware?

> the TCP DNS issue is the server should close connections only after

Aren't you arguing that the server should close connections
only after a timeout because the server can not accept so
many new connections?

						Masataka Ohta

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jul 2014 15:19:31 +0200

>  Are you saying real root servers are using cheap stock hardware?

=> current real root servers no but if we'd like to run 100 or 100
times more we have first to lower requirements on the hardware.
And the argument applies to not root servers too.

>  only after a timeout because the server can not accept so

=> no, I am arguing the requirement on TCP DNS to close at the server
side only after a timeout makes most kernel improvements for HTTP servers
useless for TCP DNS.

Regards

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2014 14:56:34 +0900

Francis Dupont wrote:

> => current real root servers no but if

Read the draft, before repeatedly demonstrating your
stupidity in public.

It is about the current configuration. Moreover,

> we'd like to run 100 or 100

then, even though you haven't read the draft, it is obvious that
100 times more root servers means 100 times less load.

> And the argument applies to not root servers too.

The argument in the draft is on the root servers.

> side only after a timeout

It is because someone (Paul Vixie, perhaps) thought that
several thousands new connection per second was harmful.
Thus, today, the timeout can be 5, 1 or 0 seconds, if
longer timeout is a problem (it is not, see below).

> makes most kernel improvements for HTTP servers
> useless for TCP DNS.

Don't you know that, with HTTP/1.1, TCP connection is kept
open even after a single query?

I wonder how you can say "I wrote OS".

					Masataka Ohta