Subject: a.dns.int

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Feb 2000 19:19:52 -0000

As has been discussed here before, many system administrators would like
to use IP addresses in NS records and MX records.

I propose that DNSEXT update RFC 1034 to require that DNS caches
manufacture artificial A records for dotted-decimal IPv4 addresses (in
canonical form), and for addresses with a.dns.int appended: e.g.,

   192.48.96.2.           604800 IN A 192.48.96.2
   192.48.96.2.a.dns.int. 604800 IN A 192.48.96.2

You may object that these records won't be universally accessible until
all caches have been upgraded. But we can also delegate .0 through .255
and a.dns.int to a bunch of servers that manufacture the same records.

Unfortunately, BIND already goes out of its way to return NXDOMAIN for
numeric TLDs. This is why I'm proposing a.dns.int: it's something that
can be made to work for everyone very easily, as soon as desired.

I already have a very small, very fast special-purpose server that
manufactures PTR records and matching A records under in-addr.arpa for
firewalls. See http://cr.yp.to/dnscache/faq/walldns.html. Adapting it
for this job would be trivial.

I also propose that dns.int be set aside for other subdomains that have
global semantics but that are expected to be manufactured by caches.

---Dan

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: [email-masked]
Date: Wed, 16 Feb 2000 14:10:46 +1100

> can be made to work for everyone very easily, as soon as desired.

	Dan, please stop spreading untruths.  It is obvious that you did
	not attempt to even create such a zone because it you had you
	would have found out that there are no impediments.

	The following test zone loads without error as zone 1 on BIND
	8.2.2-P5.

	Mark

$TTL 3600
@	SOA	bsdi.dv.isc.org. marka.isc.org. (
		1 3600 1200 3600000 3600 )
	NS bsdi.dv.isc.org.
2.3.4	A	2.3.4.1
--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Feb 2000 19:54:45 -0000

Let me add some practical comments.

Thousands of system administrators are _already_ using dotted-decimal
domain names in MX records. My MTA, like sendmail, supports these names.

My DNS cache now supports dotted-decimal domain names. This provides an
immediate benefit for other MTAs.

It's reasonably clear what will happen to this protocol in the future.
System administrators will continue to use dotted-decimal domain names.
There will be occasional failures from other MTAs running under other
DNS caches; the MTA implementors and the DNS implementors will react by
adding support. Eventually, no matter what DNSEXT does, dotted-decimal
domain names will be a de facto standard.

DNSEXT can reduce the number of failures by documenting this situation,
and by delegating some TLDs to the servers that I described.

The only remaining problem will be the (many) versions of BIND that
destroy dotted-decimal domain names. I'm willing to add one line of code
to support a.dns.int for BIND's benefit; this won't eliminate the
problem but it will provide an easy workaround.

---Dan

---

From: Rob Austein <[email-masked]>
Date: Mon, 21 Feb 2000 20:28:15 -0500

Date: Mon, 21 Feb 2000 20:14:11 -0500
   From: "D. J. Bernstein" <[email-masked]>

   Thousands of system administrators are _already_ using dotted-decimal
   domain names in MX records.

Interesting.  Do you have evidence to support this assertion?

---

From: "Michael H. Warfield" <[email-masked]>
Date: Mon, 21 Feb 2000 22:05:18 -0500

> Interesting.  Do you have evidence to support this assertion?

	I can support his assertion here by simply saying that I'm the
technical POC for a couple hundred domains and that it is a common
practice (whether or not it is one I encourage or discourage).  Even if
I go back and tell everyone that this is wrong and that they have to
change, they're just going to come back to me and claim "well it's
always worked before".  As to the claim of "thousands", I can not
personally atest to that.  But if it's only a FEW thousand, then I may
well know of a significant fraction of that few.  Right or wrong, agree
or disagree, that's what it be.

> the word 'unsubscribe' in a single line as the message text body.

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  [email-masked]
  (The Mad Wizard)      |  (770) 331-2437   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

---

From: Robert Elz <[email-masked]>
Date: Tue, 22 Feb 2000 16:40:06 +1100

Date:        20 Feb 2000 19:54:45 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Thousands of system administrators are _already_ using dotted-decimal
  | domain names in MX records. My MTA, like sendmail, supports these names.

Your MTA might, sendmail does not.   It happens that on many systems
the way sendmail is written dotted quads happen to work - but that's
purely coincidence.   Sendmail uses gethostbyname() to translate the
domain name part of the RDATA of an MX record (the MX target) from
a name to an IP address.   But gethostbyname() is also used by applications
like telnet, ftp, ... for the same purpose.  It is very common for those
applications to expect to work given a dotted quad instead of a domain
name - they're documented to do that.   But the coding is often, shall we
say, sub-optimal, and attempted the DNS translation first, then would try
treating the supplied string as a dotted quad only if that failed.

While that is really the most general way, in that it allows domain names
that are syntatically identical to a dotted quad, it put rather a burden
on the root servers, with many queries that were never going to succeed,
and at a time when negative caching was barely used.

So, gethostbyname() was altered to look for dotted quads, and simply return
the equivalent IP address, and avoid DNS lookups altogether.   This came long
after sendmail started using it - and if gethostnyname() were changed back
to the way it used to be, this practice of sticking dotted quads in MX
records would fail miserably, with no changes to sendmail at all.

What sendmail does allow, believe it or not, is an MX record with
[a.b.c.d] as its valie (dotted quad in brackets) - that's also not
really aimed at working for the value in an MX record, but is a by-product
of code to handle mail to user@[a.b.c.d] (literal address).   While I
guess one could rely upon that, I have never seen anyone, ever, write an
MX record value that way.

And we have been through this before.

  | It's reasonably clear what will happen to this protocol in the future.
  | System administrators will continue to use dotted-decimal domain names.

You are dreaming.   There are just three reasons anyone would do such a thing.
One is simple ignorance.   The next is some perceived performance
improvement in not having to translate the domain name to an address.
And third, some bizarre desire to be perverse.

Because of the way BIND (as you said) treats straight dotted quads as
illegal domain names, nothing that can be done in any reasonable timeframe
is going to help any of those groups.

The need to add ".a.dns.int." (or any other suffix) will kill all the
first group - if they were to know than a simple IP address wouldn't work
as is, then they'd just use a more normal domain name instead.  Then, if
there's to be (most hosts) still using the DNS to translate the dotted quad
as a domain name (with the "a.dns.int" or even without it), any possible
performance benefit is lost - the only people who could possibly win are
those who know the lookups will be done using a server which knows not to
actually send queries - of which there are less than a negligible number
deployed.  In practice it will be a performance loss, as essentially no
servers are going to be synthesising a.b.c.d. IN A a.b.c.d RR's for the
additional section meaning that an extra DNS lookup to do that translation
would be needed (except where something short circuits that - and nothing will
with .a.dns.int. appended).  For the last group, I simply don't care.

In practice, essentially everyone I see attempting to do this (and yes,
there are some, though not many) are in the first group, and as soon as
it is explained to them the way they're supposed to use MX records, they
do it as defined, then, and forever after.   When they get it wrong, they
also usually leave out the trailing "." in the MX target value, and get
a.b.c.d.$ORIGIN anyway, which isn't going to work in any of these schemes.

kre

ps: the practice of using gethostbyname() for MX target lookups is also what
makes mail sometimes fail (bounce) when DNS lookups suffer an outage
(server unavailable, etc).   There are still sites around that use NIS
server provided DNS lookups, and who have gethostbyname() do a lookup in
the NIS database.   NIS (last time I looked anyway) had no way to signal
"temporary failure" - only "here is the address" or "no such name".  When
the NIS server was unable to translate the name to an address, the protocol
could only say "no such name", which causes the mail to bounce.   And yes,
I have actually seen the effects of this.   Broken without a doubt, but it
does happen.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 22 Feb 2000 09:49:13 +0100

>domain names will be a de facto standard.

Dan Bernstein made this argument in DRUMS some years ago, and found little 
to no support from other mail developers there.

That doesn't mean he cannot be right, it just means that he's proposed 
dotted-decimal MX targets before, and did not get agreement from other mail 
developers.

>and by delegating some TLDs to the servers that I described.

I think the Right Thing in this situation (where Bernstein argues for a 
point of view not shared with many others) is for Bernstein to delegate 
this as a subdomain under cr.yp.to or other domains that he controls, and 
publish his grant of this domain name to the community in a suitable format 
(such as an info RFC).

There is no magic associated with a.dns.int.

                    Harald A

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Terry Lambert <[email-masked]>
Date: Tue, 22 Feb 2000 10:00:04 -0800

Robert Elz wrote:
> 
> What sendmail does allow, believe it or not, is an MX
> record with [a.b.c.d] as its valie (dotted quad in brackets)
> - that's also not really aimed at working for the value in
> an MX record, but is a by-product of code to handle mail to
> user@[a.b.c.d] (literal address).   While I guess one could
> rely upon that, I have never seen anyone, ever, write an

This is actually not quite correct.

Sendmail doesn't allow bracketed dotted quads in an MX
record.  The use of brackets is a signal to sendmail to
not attempt an MX lookup of the item in brackets.

In practice, this means that you can specify bracketed
machine names in things like the ``mailertable'' file
right hand side argument (local configuration data),
and no lookup will occur, but _not_ in MX records.

For non-bracketed dotted quads, the hacked version of
gethostbyname() in common use will eventually call
inet_pton() on a completely numeric value.  You _can_
override this behaviour, even for a completely numeric
value, by placing an additional dot at the end, in
which case it _will_ do a DNS lookup on the numeric
value.

As you point out, this is a terrible practice, in that
it unreasonably loads the root servers with things that
can never really be resolved, since there do not exist
delegations at the root for numerics not in reverse
format in the in-addr.arpa zone.

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Feb 2000 20:11:11 -0000

> to no support from other mail developers there.

False. Most MTAs _already_ permitted IP addresses in MX records.

Two exceptions came to light in that discussion. At least one of them
(vmailer) was subsequently changed to permit IP addresses in MX records,
for precisely the reasons I've explained.

One virtue of making this change in the DNS protocol is that there are
relatively few DNS cache installations, using a relatively small variety
of implementations. In the short term, many interoperability failures
will be prevented; in the long term, perhaps MTA implementors will
eventually be able to stop worrying about the problem.

Another virtue of making this change in the DNS protocol is that it will
automatically apply to other applications, such as applications using
SRV records, with no extra effort.

> delegate this as a subdomain under cr.yp.to

You don't mind if software starts assigning special meanings to domains
that could be transferred to other people later?

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Feb 2000 23:12:39 -0000

Rob Austein writes:
> Do you have evidence to support this assertion?

Peter Koch reported in 1998 that there were 223 *.de dotted-decimal MX
records. If you try MX lookups on several thousand second-level domains
obtained from PTR lookups on random IP addresses---note that this is
biased towards large sites---you'll see some dotted-decimal MX records.

If there's any serious dispute about the accuracy of my estimate, we can
get the .com database from NSI and try a random sample of (say) 100000
domains.

---Dan

---

From: Bill Manning <[email-masked]>
Date: Tue, 22 Feb 2000 15:44:37 -0800 (PST)

% 
% Rob Austein writes:
% > Do you have evidence to support this assertion?
% 
% Peter Koch reported in 1998 that there were 223 *.de dotted-decimal MX
% records. If you try MX lookups on several thousand second-level domains
% obtained from PTR lookups on random IP addresses---note that this is
% biased towards large sites---you'll see some dotted-decimal MX records.
% 
% If there's any serious dispute about the accuracy of my estimate, we can
% get the .com database from NSI and try a random sample of (say) 100000
% domains.
% 
% ---Dan

I, for one, would appreciate it if you would take this on and publish
the results. Preferably that can be independently verified.  Can you
do this in the next few weeks?

--bill

---

From: Randy Bush <[email-masked]>
Date: Tue, 22 Feb 2000 15:34:53 -0800

as we have real work to do in preparation for adelaide, this digression and
pissing contest will have to move off this list at the end of today.

randy

[email-masked] is the mailing list for the ietf dnsext wg.  see
<http://www.ietf.org/html.charters/dnsext-charter.html> for the wg charter.
messages should be on topics appropriate to the dnsext wg, which are various
discussion of the dns protocols or administrivia of the wg itself.  the list
is moderated.

calls for papers, announcements of events not directly relevant to the dns
protocols, etc. are not appropriate.  discussion of problems with particular
implementations, announcements of releases, sites' misconfigurations, etc.
should be done on mailing lists for the particular implementations.

there is a wg for dns operational practice, dnsop, whose charter can be
found at <http://www.ietf.org/html.charters/dnsop-charter.html>.

there is a mailing list for discussion of whose implementation is better,
and why someone else's is broken.  it is [email-masked].  all
discussions of such nature should occur there or on /dev/null.  unlike the
namedroppers list, [email-masked] is not archived.

discussion of this policy is a topic for the poisson wg.  poisson's charter
can be found at <http://www.ietf.org/html.charters/poisson-charter.html>.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 23 Feb 2000 16:04:58 +0100

>False. Most MTAs _already_ permitted IP addresses in MX records.

I was talking about the people present on the list, not about MTAs.

>that could be transferred to other people later?

In that respect, too, there is nothing unique about a.dns.int.

                Harald