Subject: Re: draft-stjohns-secure-notify-00.txt

From: [email-masked]
Date: Thu, 03 Jul 2003 12:14:19 +1000

> If tiddlywinks.dom consists of a single machine running an HTTP server,
> an SMTP server, and a DNS server, then demanding a second DNS server is
> a really bad idea: it adds expense while decreasing reliability. See
> http://cr.yp.to/djbdns/third-party.html.

	And not having a second nameserver puts the failure load
	on the caching nameserver (which is often a shared resource)
	verses on the end machine making the lookup (which is often
	a individual resource).

	In otherwords it is anti-social not to provide redundancy.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 Jul 2003 04:06:48 +0000

> 	In otherwords it is anti-social not to provide redundancy.

twice in the last month hotbar.com's nameservers have gone off the
air (at that time there were only two and both were on the same lan)
and the resulting query load (evidently a lot of win32 clients using
some kind of browser plugin) caused a multihour ~1Kqps spike on the
root name servers.  1Kqps more or less doesn't exactly break anything,
but i will echo marka's sentiments above: not providing redundancy
is antisocial (and irresponsible, and unprofessional, and so on).

(as to whether that redundancy ought to be expressed in the parent
domain name of the NS RR targets or not, i'm still considering the
proposal... it makes as much sense, on the face of it, as the
recommendation that they be on different lans.)

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Jul 2003 10:59:02 -0000

Jim Reid writes:
> So what?

These clueless parent activities cause interoperability failures. For
example, when the clueless .fr administrators refuse to delegate domains
to servers that don't know the root server addresses, they are breaking
the recommended configuration of non-caching non-root servers. Vixie has
admitted that those servers shouldn't have to know the root addresses.

Perhaps you're happy with some of these clueless parent activities
because they favor your software---but the IETF is _not_ supposed to
require or encourage this sort of behavior. See RFC 2119, section 6.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Jul 2003 11:02:09 -0000

Jim Reid writes:
> I suspect that cr.yp.to consists of not much more than an HTTP server, 
> an SMTP server and a DNS server. Yet this zone has two NS records.

The cr.yp.to web and mail services are spread across several machines in   
my office, so the DNS services are too. For a while, all the services 
were on one machine, and there was only one DNS server. 

Either way, this is a good example of RFC 2182 being incorrect. Like the
administrators of AOL, Harvard, CERT, et al., I have all my DNS servers   
on my own network. Moving them to third-party networks would _not_ be a 
good idea.

> > If tiddlywinks.dom consists of a single machine running an
> > HTTP server, an SMTP server, and a DNS server, then demanding
> > a second DNS server is a really bad idea: it adds expense
> > while decreasing reliability.
> This is utter nonsense and you should know better. 

http://cr.yp.to/djbdns/third-party.html analyzes the costs and benefits 
in detail, and explains exactly why RFC 2182 is incorrect. Have you read
the analysis? Is there some point that you don't understand?

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Jul 2003 11:15:48 -0000

Paul Vixie writes:
> root name servers.

More details, please. How exactly were these clients generating extra
load on the root servers?

Do you also demand that every DNS server accept dynamic updates so that
clueless Microsoft clients don't send updates to the root servers?

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Jul 2003 11:40:59 -0000

> verses on the end machine making the lookup (which is often

``Having a second nameserver puts the failure load on the web client,
which is often a shared resource---a proxy like Squid. An HTTP failure
consumes more resources than a DNS failure.''

There are actually six separate load issues, all of which are discussed
in http://cr.yp.to/djbdns/third-party.html. None of them matter for the
vast majority of sites. I notice that you aren't screaming ``Every web
site on the Internet needs third-party HTTP servers!''

If you care so much about DNS load, why don't you encourage in-bailiwick
server names, and why don't you tell RIPE and ARIN to start allowing
glue? Gluelessness is a much larger source of load than server outages.

---

From: Matt Larson <[email-masked]>
Date: Thu, 3 Jul 2003 08:57:15 -0400

> load on the root servers?

Paul may have something else in mind when he mentions browser
plug-ins, but the culprit is also Microsoft's name server shipped with
NT and 2000.  If, when performing a lookup, it cannot get a response
from any of a zone's authoritative servers (because of lameness,
non-responsiveness--whatever), it queries that zone's parent for a
fresh copy of its child's NS RRset.  I suppose the reasoning is that
the NS RRset in its cache could be out of date, so why not fetch the
latest information?  While well-intentioned, in practice this recovery
technique can backfire and pound the parent zone's servers.  We see
this all the time when a popular com or net zone drops completely off
the net.

For more thoughts on this topic, see Section 2.1 of
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-bad-dns-res-01.txt.

> clueless Microsoft clients don't send updates to the root servers?

All the carefully reasoned web pages in the world about how things
ought to behave will not change the fact that the real world is a
messy place.  While we can strive for perfection, we have to
accommodate reality.  And in my world, multiple distributed
authoritative servers per zone make things run more smoothly.

We are straying into operational territory and should move this
discussion to [email-masked].

Matt

--
Matt Larson <[email-masked]>
VeriSign Naming and Directory Services

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Jul 2003 15:06:18 -0000

Matt Larson writes:
> the culprit is also Microsoft's name server shipped with
> fresh copy of its child's NS RRset

Suppose there's a major network cut---for example, Japan losing its
connectivity to the rest of the Internet. Every time one of those
Microsoft programs in Japan tries to look up a site outside Japan, it
will end up pestering a high-level server, such as the Japan root
server. Right?

If this ends up taking down the high-level server, do you blame

   (1) Microsoft's unusual query strategy, or
   (2) millions of sites that haven't bought Japanese DNS service?

When you say ``NT and 2000,'' are you deliberately excluding more recent
releases of Windows? Has Microsoft changed its query strategy now?

P.S. The query strategy is a protocol issue, and should be discussed on
namedroppers. Your dnsop-bad-dns-res document is misdirected.

P.P.S. Your document fails to provide verifiable software information.
It doesn't even contain the word ``Microsoft.''

---

From: [email-masked]
Date: Fri, 04 Jul 2003 08:35:22 +1000

> site on the Internet needs third-party HTTP servers!''

	Replicating a HTTP server is generally a much harder process
	than providing getting secondary DNS service.  If your HTTP
	service is read-only it is much easier to do.  The fact that
	HTTP supports active components makes it a difficult service
	to replicate.   Lack of support for SRV records also makes
	it a difficult service to replicate.

	Having a redundant DNS service allows you to make use of
	redundant mail servers which will reduce the load on the
	clients as they usually do have dead server detection.
	Are you going to say that backup mail exchangers are a
	bad thing as well?
 
> glue? Gluelessness is a much larger source of load than server outages.

	I encourage nameservers to serve the zones they live in.
	One level of indirection is not bad.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Jul 2003 23:29:41 -0000

[email-masked] writes:
> Are you going to say that backup mail exchangers are a bad thing as well?

Third-party mail exchangers are even less useful than third-party HTTP
servers. Sure, a few sites have them (in which case they should have DNS
servers spread just as widely), but most sites shouldn't and don't.

> The fact that HTTP supports active components makes it a difficult
> service to replicate.

Let me get this straight. You're saying that replication is terribly
important, but that the importance suddenly disappears when you're too
lazy to find a third party with the right web-serving software?

Some of us have DNS software that supports ``active components,'' by the
way: load balancing, scheduled record creation, etc. Your own DNS server
supports client differentiation that you fail to replicate correctly.

  [ ARIN/RIPE gluelessness ]
> One level of indirection is not bad.

We're talking about gluelessness on every reverse lookup. Have you ever
studied your logs? How can you possibly claim to care about the load
from the occasional server outage when you clearly don't care about the
much larger load caused by gluelessness?

---

From: Yasuhiro Orange Morishita / 森下泰宏<[email-masked]>
Date: Sun, 06 Jul 2003 19:51:22 +0900 (JST)

> glue? Gluelessness is a much larger source of load than server outages.

I found in-bailiwick servers on database of RIPE NCC, as follows.
So, I think we can use in-bailiwick name on IP address block of RIPE NCC.
--
Yasuhiro 'Orange' Morishita
DNS Technical Engineer
Research and Development department, Japan Registry Service Co.,Ltd. (JPRS)
E-Mail: [email-masked] / [email-masked]

% dnsq ns 4.4.e164.arpa. ns.ripe.net
2 4.4.e164.arpa:
133 bytes, 1+0+3+3 records, response, noerror
query: 2 4.4.e164.arpa
authority: 4.4.e164.arpa 14400 NS ns1.4.4.e164.arpa
authority: 4.4.e164.arpa 14400 NS ns2.4.4.e164.arpa
authority: 4.4.e164.arpa 14400 NS ns3.4.4.e164.arpa
additional: ns1.4.4.e164.arpa 14400 A 208.184.60.4
additional: ns2.4.4.e164.arpa 14400 A 81.200.68.218
additional: ns3.4.4.e164.arpa 14400 A 81.200.66.29

% whois -h whois.ripe.net 4.4.e164.arpa
% This is the RIPE Whois server.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/ripencc/pub-services/db/copyright.html

domain:       4.4.e164.arpa
descr:        Domain for UK ENUM trial
admin-c:      ALTH-RIPE
tech-c:       JIRE-RIPE
zone-c:       JIRE-RIPE
nserver:      ns1.4.4.e164.arpa
nserver:      ns2.4.4.e164.arpa
mnt-by:       UK-ENUM-MNT
changed:      [email-masked] 20020521
source:       RIPE
(snip)

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Jul 2003 13:11:10 -0000

At last report, RIPE was continuing to reject glued delegations inside
in-addr.arpa. They claimed that a glued delegation would be a ``loop.''
That's what's forcing the extra load that I'm talking about.

> authority: 4.4.e164.arpa 14400 NS ns1.4.4.e164.arpa

It's always nice to see glue. However, that domain is an internal RIPE
experiment; it has no relevance to the RIPE in-addr.arpa registration
policy.