Subject: back by popular demand - a DNS calculator

From: Joe Touch <[email-masked]>
Date: Thu, 14 Feb 2013 15:02:48 -0800

Hi, all,

By popular request, I've restored the DNS calculator function as an
operational service. See:

http://www.isi.edu/touch/tools/dns-calc.html

(this was designed for a Sigcomm OO session, but it's been used several
places as an example why the DNS should NOT be anything more than a
mapping service)

Joe

PS - if you do happen to use it as an example, please do drop me a note;
I'd be very glad to track that info. and/or include a pointer to any
classes that use it.

---

From: "Marco Davids (Prive)" <[email-masked]>
Date: Fri, 15 Feb 2013 00:07:04 +0100

> http://www.isi.edu/touch/tools/dns-calc.html

Great! But.... I was hoping it would do DNSSEC by now.

Like Bert's  tool has been doing for ages:

dig 2.3.*.2.+.rp.secret-wg.org TXT +dnssec

http://bert.secret-wg.org/Tools/index.html

;-)

-- 
Marco Davids

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 15 Feb 2013 07:08:26 +0000

> Great! But.... I was hoping it would do DNSSEC by now.

...how can one otherwise know that 2+3 is 4^H5

   Patrik

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Feb 2013 08:03:12 +0000

> places as an example why the DNS should NOT be anything more than a

I suppose people here have already tried traceroute 216.81.59.173

   Brian

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Feb 2013 09:19:53 +0100

On Thu, Feb 14, 2013 at 03:02:48PM -0800,
 Joe Touch <[email-masked]> wrote 
 a message of 16 lines which said:

> operational service. 

Why no delegation from postel.org? It is not really DNS if you have to
use an explicit name server.

% dig @128.9.160.161 ANY 3.4.add.calc.postel.org

; <<>> DiG 9.7.3 <<>> @128.9.160.161 ANY 3.4.add.calc.postel.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30695
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;3.4.add.calc.postel.org.	IN	ANY

;; AUTHORITY SECTION:
postel.org.		15	IN	SOA	dns.postel.org. touch.postel.org. 2013021402 60 30 1209600 15

;; Query time: 195 msec
;; SERVER: 128.9.160.161#53(128.9.160.161)
;; WHEN: Fri Feb 15 09:19:33 2013
;; MSG SIZE  rcvd: 98

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Feb 2013 09:05:09 -0800

> use an explicit name server.

I don't follow your logic.

FYI, postel.org entries are hosted on a "hidden master" DNS server 
inside the postel.org domain on a research host. The public masters for 
that domain are hosted elsewhere on production machines.

The response you got below is because the public masters hadn't caught 
up. I'm checking on why that hasn't happened, but in the meantime (as 
per the web page) you can go directly to the hidden master:

dig @dns.postel.org ANY 3.4.add.calc.postel.org

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Feb 2013 09:19:01 -0800

> http://bert.secret-wg.org/Tools/index.html

I'd be glad to know how long that's been up (mine was posted in 2001 for 
the Sigcomm OO session). AFAICT, that web page was put up in 2003, but 
I'd be glad to hear otherwise.

Some key differences, FWIW:

	- my variant returns the response as an IP address,
	rather than inside a TXT record (there's a point to
	that, as per the OO slides posted on the page above)

	- the Bert version uses DNS strings that aren't valid
	(*, +, ',', ++)

	- my variant has a static number of entries (40,003).
	That's intentional to avoid potential impact on
	DNS caches.

Joe

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 15 Feb 2013 23:06:15 +0100

> 	- the Bert version uses DNS strings that aren't valid

Are we going to open again the question whether the DNS protocol can handle any value in the octets, as compared to the hostname definition that says something more limited? ;-)

   Patrik

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Feb 2013 14:10:44 -0800

> Are we going to open again the question whether the DNS protocol can handle any value in the octets, as compared to the hostname definition that says something more limited? ;-)

Let's just say that there doesn't appear to be disagreement that the DNS 
can handle a-z/0-9/'-'.

Other values _may or may not_ be permitted or handled opaquely in the 
lookup, AFAICT. It remains a question AFAICT.

Joe

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 Feb 2013 07:14:05 +0900

>> - the Bert version uses DNS strings that aren't valid

this is not an accident

> Are we going to open again the question whether the DNS protocol can
> handle any value in the octets, as compared to the hostname definition
> that says something more limited? ;-)

no need.  the spec is pretty clear.

randy

---

From: Warren Kumari <[email-masked]>
Date: Fri, 15 Feb 2013 17:45:02 -0500

> Are we going to open again the question whether the DNS protocol can handle any value in the octets, as compared to the hostname definition that says something more limited? ;-)

Sure -- the DNS protocol *cannot* "handle any value in the octets" -- in fact, there are an *infinite* number of values it cannot handle *in the octets*. For example, it cannot handle 257. It also cannot handle 321, nor 19.3...

:-P
W

--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Feb 2013 18:17:27 -0500

--On Friday, February 15, 2013 14:10 -0800 Joe Touch
<[email-masked]> wrote:

> Let's just say that there doesn't appear to be disagreement
> that the DNS can handle a-z/0-9/'-'.
> 
> Other values _may or may not_ be permitted or handled opaquely
> in the lookup, AFAICT. It remains a question AFAICT.

Joe,

Except for IDNs (or labels starting with "xn--" more
specifically), for which there are special rules, it appears to
me that the spec is _extremely_ clear that a lookup operation
that fails to deal with those "other values" in labels
--including even properly-escaped embedded "." characters -- is
unambiguously non-conforming.

There should be no "AFACIT" about it, much less a question.

Whether or not it is a good idea to use such labels and in what
contexts is a different matter.

   john

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Feb 2013 16:48:17 -0800

> unambiguously non-conforming.

Seems clear to me:

RFC1035:

The labels must follow the rules for ARPANET host names.  They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less.

--

If any label were allowed, then why does IDN conversion go so far out of 
its way to exclude particular strings, e.g., those beginning/ending with 
'-' and encodes everything 0..7F into a-z/0-9?

(I was focused on looking up A records given FQDNs)

Joe

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 15 Feb 2013 19:56:40 -0500

Let's see, here is the list of RFCs that the RFC Editor believes
update RFC 1035:
RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 1995, RFC 1996,
RFC 2065, RFC 2136, RFC 2181, RFC 2137, RFC 2308, RFC 2535, RFC 2845,
RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936,
RFC 5966, RFC 6604,

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Fri, Feb 15, 2013 at 7:48 PM, Joe Touch <[email-masked]> wrote:
> If any label were allowed, then why does IDN conversion go so far out of its
> way to exclude particular strings, e.g., those beginning/ending with '-' and
> encodes everything 0..7F into a-z/0-9?
>

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 16 Feb 2013 10:24:04 +0900

> restrictions on the length.  Labels must be 63 characters or less.

That is syntax in section "2.3.1. Preferred name syntax" as syntax
preferred by applications that use host names.

   The following syntax will result in fewer problems with many
   applications that use domain names (e.g., mail, TELNET).

The basic rule of the RFC is:

   Although labels can contain any 8 bit values in octets that make up a
   label

A label may include '.' character as is, as there is no escape
mechanism, though applications expecting host names may fail to
recognize it.

						Masataka Ohta

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 16 Feb 2013 08:02:48 +0100

> Sure -- the DNS protocol *cannot* "handle any value in the octets" -- in fact, there are an *infinite* number of values it cannot handle *in the octets*. For example, it cannot handle 257. It also…

Ok, it is obvious Friday...somewhere...

Once when being on IESG way back when I was tasked to write the response to the letter we got with a suggestion on an alternative solution for the "running out of IPv4 addresses" problem.

The proposal was to not stop counting at 255 in each of the four numbers separated by periods, but continue to (at least) 999.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 16 Feb 2013 08:04:14 +0100

> (I was focused on looking up A records given FQDNs)

Thats a different thing than talking about what the DNS protocol can handle.

   Patrik

---

From: Dave Cridland <[email-masked]>
Date: Sat, 16 Feb 2013 07:33:21 +0000

On 16 Feb 2013 07:03, "Patrik Fältström" <[email-masked]> wrote:
> > Sure -- the DNS protocol *cannot* "handle any value in the octets" --
in fact, there are an *infinite* number of values it cannot handle *in the
octets*. For example, it cannot handle 257. It also cannot handle 321, nor
19.3...
> Once when being on IESG way back when I was tasked to write the response
to the letter we got with a suggestion on an alternative solution for the
"running out of IPv4 addresses" problem.
>
> The proposal was to not stop counting at 255 in each of the four numbers
separated by periods, but continue to (at least) 999.

Seems quite sensible to me. After all, we do this in TELNET option
negotiation.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 16 Feb 2013 08:46:27 -0500

Sent from my iPad

> The proposal was to not stop counting at 255 in each of the four numbers separated by periods, but continue to (at least) 999.

That's also a solved problem -- there is even a draft about it : http://tools.ietf.org/html/draft-terrell-math-quant-ternary-logic-of-binary-sys-01

You just use ternary logic instead of binary and all your problems are solved... or something...I get a little lost during the proof of Fermat's...

W

---

From: John C Klensin <[email-masked]>
Date: Mon, 18 Feb 2013 10:29:06 -0500

--On Friday, February 15, 2013 16:48 -0800 Joe Touch
<[email-masked]> wrote:

> If any label were allowed, then why does IDN conversion go so
> far out of its way to exclude particular strings, e.g., those
> beginning/ending with '-' and encodes everything 0..7F into
> a-z/0-9?
> 

Now you are asking a different question, although the answer for
A RRs generally is still the same.  My apologies to those who
don't need the mini-tutorial that follows -- many of those of us
who work primarily in applications would need similar tutorials
to understand the reasons for some of the decisions in the work
of those who primarily operate at lower layers of the stack.

I recommend rereading the relevant sections of RFCs 1123 and
2181 but, briefly, the DNS doesn't impose any limitations other
than what will fit in an octet.  However, many, perhaps most,
applications do impose their own rules and those rules usually
match what 1034/1035 call the "preferred syntax" -- a syntax
derived from popular applications at the time as those
specifications make clear.  As one example with which I'm
painfully familiar, SMTP treats a domain name containing
characters outside the ASCII range as syntax violations and a
conforming implementation will never look up such a domain as
part of mail address resolution or routing.  Consequently,
something like
    Non-ASCII-String MX 0 some.domain.example.
is perfectly valid as far as the DNS is concerned but nonsense
as far as actual utility is concerned -- SMTP implementations
are the only users of MX RRs and no conforming SMTP
implementation will ever access such a record.

IDNA is a clever trick (or, from other perspectives, an ugly
hack) that accomplishes two main things:

	-- It permits IDNs to be used with applications
	including, e.g., SMTP, without changing _their_ syntax
	rules because the labels stored in the DNS and
	transmitted on the wire still conform to those
	"preferred syntax" rules.
	
	-- It warns applications and forces the additional
	restrictions and processing that enable sensible
	treatment of non-ASCII strings.  As the most obvious
	example, the case-insensitive matching that the DNS
	specifies for ASCII strings is not defined by the DNS
	for non-ASCII ones (and, indeed, becomes more
	complicated and language or locale-sensitive for some
	characters).

I don't believe the importance of the second was fully
appreciated when we got started on IDNA.  To this day, people
who believe that IDNA can be replaced by simply placing Unicode
strings encoded in UTF-8 into the DNS tend to make proposals
that ignore those issues.

The additional exclusions of IDNA such as prohibition of most
symbols in the Unicode collection and restrictions on the
appearance of "--" in the third and fourth octets of labels
apply only to IDNA implementations and are intended to provide
an extended, but still relatively safe, version of the
historical "preferred syntax" and/or to protect the syntax for
signaling special coding in the (unlikely but not impossible)
event that a different one is needed for some purpose in the
future.

The bottom line is that none of these restrictions, including
the SMTP one and the IDNA ones, are a property or requirement of
the DNS.

    best,
      john

---

From: [email-masked] (Martin Rex)
Date: Mon, 18 Feb 2013 17:07:12 +0100 (CET)

> RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936,

Let's see, here is the list of RFCs that update STD13:
 *NONE*

http://tools.ietf.org/html/std13

;-)

-Martin

---

From: "Carlos M. martinez" <[email-masked]>
Date: Wed, 20 Feb 2013 22:46:16 -0400

Wasn't the 'evil bit' able to hold the value 2 ?

Use all evil bits for IP addresses and we'll soon have no need for IPv6.

:D

~C.

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 20 Feb 2013 22:46:40 -0500

> Wasn't the 'evil bit' able to hold the value 2 ?
Yes, but we need an RFC for that.  From RFC 3514:

6. IANA Considerations

   This document defines the behavior of security elements for the 0x0
   and 0x1 values of this bit.  Behavior for other values of the bit may
   be defined only by IETF consensus [RFC2434].

		--Steve Bellovin, https://www.cs.columbia.edu/~smb