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

From: Robert Elz <[email-masked]>
Date: Tue, 01 Jul 2003 17:51:35 +0700

Date:        Mon, 30 Jun 2003 17:03:01 -0400
    From:        Mike StJohns <[email-masked]>
    Message-ID:  <5.2.1.1.2.20030630165223.026f4008@localhost>

  | The reason I like 
  | the name diversity constraint is because it provides one more resolution 
  | path to the delegated zone, even if the glue records in the parent are 
  | messed up or more probably, missing.

For what it is worth, and this might almost be a first time in history,
I agree with djb's comments on this.   I won't repeat those, but I would
add that if you can't trust the parent zone to have your delegation
configured correctly, you may as well give up and go someplace else
completely - adding a server that has a name somewhere else isn't very
likely to help (sure, you can craft a case where it actually solves an
imagined potential problem, but in reality...)

  | To be clear, your issue is with "that at least one name points to a server 
  | not named in the child zone" and not with the rest of it as above?

Here, I agree with your and not Andreas - parent zone admins should do
their utmost to ensure that the child zone is correctly configured before
updating delegations - it is the only tool that exists to cause people
managing the delegated domains to get things right.

But this only extends to the technical requirements, "good policy" can't
be enforced (shouldn't be anyway), so even if it were reaosnable to attempt
to discover the attachment points of different servers, that wouldn't
be reasonable for the parent to do.   Checking that the servers are
properly configured and answering correctly however it can easily, and
should always, do.

kre

--
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: Mike StJohns <[email-masked]>
Date: Tue, 01 Jul 2003 13:25:55 -0400

OK - the non-child named secondary is out.

Let's try and bring this back to the question that I really want answered.

Assuming that a parent will update NS records based on what a child sends 
it under the secure notify (let's not argue this assumption for now),  what 
is a reasonable set of checks the parent should apply to the data sent to 
it by the child?

Select one or more.
a) None - trust the child to do what it is supposed to and just update the 
records when told to do so.
b) Check to make sure the systems named in the NS records can be resolved 
(e.g. either glue records exist or other resolution)
c) check...can be reached
d) check... are serving the child zone
e) Check that there are at least 2 distinct servers listed in the NS 
records (e.g. resolve to different A records?)

Note that the child will be checking to see if the parent actually 
publishes the new records and will repeat the notify if the new records 
aren't published after some period of time.  Should the child zone, 
regardless of any secure notify capability, check its delegation status at 
the parent periodically?  (Actually, probably a topic for another thread, 
but could add this to the secure notify document as the code to do secure 
notify will have to do this in part).

At 12:50 7/1/2003, Jim Reid wrote:
> >>>>> "kre" == Robert Elz <[email-masked]> writes:
>
>     kre> Here, I agree with your and not Andreas - parent zone admins
>     kre> should do their utmost to ensure that the child zone is
>     kre> correctly configured before updating delegations - it is the
>     kre> only tool that exists to cause people managing the delegated
>     kre> domains to get things right.
>
>     kre> But this only extends to the technical requirements, "good
>     kre> policy" can't be enforced (shouldn't be anyway), so even if
>     kre> it were reaosnable to attempt to discover the attachment
>     kre> points of different servers, that wouldn't be reasonable for
>     kre> the parent to do.  Checking that the servers are properly
>     kre> configured and answering correctly however it can easily, and
>     kre> should always, do.
>
>Agreed. But even this is not enough. Even in the TLDs that do have
>these checks, entropy takes over eventually. ISTR Patrik Faltstrom's
>survey of .se which showed 20-25% of the .se delegations were broken
>even although they were checked and found to be correct at the time
>the delegations were made. So the question becomes one of policy. Who
>will be the DNS delegation checking police? What do they check? And
>how do they deal with offenders?

---

From: Jim Reid <[email-masked]>
Date: Tue, 01 Jul 2003 09:50:06 -0700

---

From: Robert Elz <[email-masked]>
Date: Wed, 02 Jul 2003 04:23:23 +0700

Date:        Tue, 01 Jul 2003 13:25:55 -0400
    From:        Mike StJohns <[email-masked]>
    Message-ID:  <5.2.1.1.2.20030701130715.024b0168@localhost>

  | Select one or more.

(b) (c) & (d).

(e) would be nice, but is very difficult to do in a meaningful
way, and I'm not sure that doing half a job is worth it - that is,
really determining for sure that there are 2 servers is very hard
to accomplish, just knowing that there are 2 different A records
isn't really sufficient, so I probably wouldn't bother with that
one.

  | Note that the child will be checking to see if the parent actually 
  | publishes the new records and will repeat the notify if the new records 
  | aren't published after some period of time.

One would hope that if the child is automating a delegation request, that
it is also checking to make sure that all the servers are functioning
correctly, before sending a request to the parent.   We cannot, of course,
depend upon that for anything, but operationally, it is what should be
happening, so the parent getting lots of repeated update requests which it
is just refusing to carry out shouldn't be normal.

  | Should the child zone, 
  | regardless of any secure notify capability, check its delegation status at 
  | the parent periodically?

Most likely, but it isn't clear to me what it should do when it finds itself
no longer listed.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 Jul 2003 09:10:40 -0000

> d) check... are serving the child zone

Please don't use vague words like ``serving.'' Very few people know what
service is actually necessary for interoperability. The average parent
script writers certainly don't; I've seen them try TCP queries in 
violation of RFC 1123, treat the SOA suggestions from a particular book
as requirements, demand root addresses from the child servers, et al.

> (e.g. either glue records exist or other resolution)

This is a better suggestion, because it's hard for parent script writers
to screw up. They'll use gethostbyname() rather than trying to write
their own resolver. But it's important to emphasize that glue is allowed
and encouraged, even though it means that gethostbyname() will fail.

> records (e.g. resolve to different A records?)

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.

DNS servers should be spread as widely as the other servers at the site.
For some sites this means DNS servers all over the globe. For others it
means a grand total of one DNS server. ``Two different A records'' is a
wild oversimplification, horribly inadequate for some sites and actively
counterproductive for others.

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

---

From: Jim Reid <[email-masked]>
Date: Wed, 02 Jul 2003 05:39:00 -0700

>>>>> "djb" == D J Bernstein <[email-masked]> writes:

    djb> Please don't use vague words like ``serving.'' Very few
    djb> people know what service is actually necessary for
    djb> interoperability. The average parent script writers certainly
    djb> don't; I've seen them try TCP queries in violation of RFC
    djb> 1123, treat the SOA suggestions from a particular book as
    djb> requirements, demand root addresses from the child servers,
    djb> et al.

So what? A parent is entitled to apply and enforce any criteria they
want on the delegations they make. Whether those criteria are good or
bad is irrelevant: if someone wants a name in a certain part of the
tree, they have to play by the parent's rules. The checks you refer to
are not done for reasons of interoperability. They're mainly done to
apply a clue threshold to the people responsible for the DNS for the
name that's being registered. This reduces the load on the registry's
support staff as they don't get swamped by calls from registrants
about how to set up and run name servers. If you've ever visited a TLD
registry -- as I have -- you'd be amazed at the number of calls they
get from people who believe paying $25 or so for a name registration
entitles them to hours of DNS consultancy and hand-holding.

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

This is utter nonsense and you should know better. RFC1034 is very
clear that tiddlywinks.dom should have at least two name servers and
RFC2182 explains why. 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.

---

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

> 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]

---

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.

---

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: Masataka Ohta <[email-masked]>
Date: Thu, 3 Jul 2003 20:46:21 +0859 ()

DJB;

> on my own network. Moving them to third-party networks would _not_ be a 

Well, the fundamental problem is not in RFC2182.

The fundamental probelm is that DNS is a (luckily enough, not so
intelligent) intermediate entity, violating the end to end princple.

As such, moving them to third-party WGs is not a solution.

As DNS does not follow the principle, it is valunerable to problems
of lack of robustness and efficiency, which is common to protocols
ignoring the principle.

Anycast root servers can help the situation unless the needs on
DNS is not so demanding.

							Masataka Ohta

---

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.

---

From: Jim Reid <[email-masked]>
Date: Sun, 06 Jul 2003 06:48:33 -0700

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

    djb> It's always nice to see glue. However, that domain is an
    djb> internal RIPE experiment;

No it's not. You simply don't have the faintest clue what you're
talking about. I registered 4.4.e164.arpa on behalf of the UK
government for the national ENUM trial which is co-ordinated by the UK
ENUM Group, UKEG. The delegation is not an experiment by anyone. And
certainly not by RIPE NCC.

    djb> it has no relevance to the RIPE in-addr.arpa registration

That's wrong too. The template and procedure used by RIPE NCC for
handling ENUM delegations is identical to that for delegations in
their part of the in-addr.arpa tree.

BTW, there is a big difference between RIPE NCC and RIPE, a distinction
that appears to have eluded you.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Jul 2003 15:19:14 -0000

Jim, how exactly do you claim that European users can register glue for
their (big, direct from RIPE) in-addr.arpa delegations?

http://www.ripe.net/reverse/howtoreverse.html specifically states ``IP
address not allowed here'' for the ``nserver'' part of an in-addr.arpa
delegation request. There's no other line allowing a server IP address.

You claim that e164.arpa and in-addr.arpa have ``identical'' procedures.
Evidently you are claiming that, since e164.arpa allows IP addresses on
the nserver line, in-addr.arpa must also allow them; in short, that the
RIPE web page is wrong. Do you have any evidence to back up this claim?

Of course, even if RIPE and ARIN do fix their procedures someday to
_allow_ glue, the considerable extra load from reverse lookups will
continue until most people _use_ glue. If your company truly cares about
DNS load, why is it encouraging people to set up glueless delegations?

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 7 Jul 2003 09:28:58 +0859 ()

djb;

You are the first party and your peers are the second parties.

DNS, however, is an intermediate system requiring third party
operators, selection on which you virtually have no influence,
for root, TLD, in-addr.arpa. and other important domains.

Having yet another third parties of your own choice for your
own domains is not a bad idea for extra redundancy of your
domains.

> their (big, direct from RIPE) in-addr.arpa delegations?

I don't know the situations in Europe, but, I think you are not saying
you want to operate in-addr.arpa. servers by yourself.

							Masataka Ohta

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Jul 2003 18:36:27 -0000

I wrote:
: Jim, how exactly do you claim that European users can register glue for
: their (big, direct from RIPE) in-addr.arpa delegations?

If Jim's claim was correct, I'd like to document the procedure on my web
pages, so that my users can take advantage of automatic glued [ab].ns...
names. But Jim hasn't responded. Has anyone here successfully convinced
RIPE to add a glued in-addr.arpa server name such as

   3.5.7.in-addr.arpa NS ns1.3.5.7.in-addr.arpa

or should I assume that Jim didn't know what he was talking about?

Masataka Ohta writes:
> own domains is not a bad idea for extra redundancy of your domains.

Using glueless names doesn't add any redundancy. It creates hassles for
the server administrator, creates noticeable delays on occasion for the
client users, and produces a far larger increase in DNS load than any of
the third-party-server issues that prompted this discussion.

---

From: Mohsen Souissi <[email-masked]>
Date: Thu, 10 Jul 2003 16:26:10 +0200

Hi Mike,

Please find my comments below.

On 30 Jun, Mike StJohns wrote:
| At 16:39 6/30/2003, Andreas Gustafsson wrote:
| >In draft-stjohns-secure-notify-00.txt, M. StJohns writes:
| > >   In fact, best practice requires that a zone be served by at least one
| > >   server that can be referenced by a name not within that zone.
| >
| >My interpretation of RFC2182 is that a zone should have at least one
| >server on a geographically and topologically distinct network, but I
| >see no requirement that it be referenced by a name in a different
| >zone.
| 
| yeah - I can actually read 2182 either way - specifically section 6 
| discussion of the selection of secondaries.  I'd be interested in 
| understanding what others think is best practice here.  The reason I like 
| the name diversity constraint is because it provides one more resolution 
| path to the delegated zone, even if the glue records in the parent are 
| messed up or more probably, missing.
| 
| 
| > >   The parent zone MUST verify the names pointed to by the NS are
| > >   resolvable, that at least one name points to a server not named in
| > >   the child zone, and that it has glue A records for any server named
| > >   in the child zone. [Q:  Does this make sense, or is it better to just
| > >   trust the child?] If these conditions are not satisfied, the parent
| > >   server MUST NOT install the new records, and MUST log the problem
| >
| >I don't think this makes sense.  Whether the best practice is to have
| >a server in a different zone or just on a different network, it is
| >just an operational recommendation and not something that should be
| >enforced as part of the protocol.
| 
| 
| To be clear, your issue is with "that at least one name points to a server 
| not named in the child zone" and not with the rest of it as above?  Yeah - 
| this might either be a) removed, b) turned into a policy configuration item 
| (e.g. something the parent zone wants to enforce on the child - in which 
| case this section become MAY) or c) left as a MUST.  My guess is that 
| either a or b is probably appropriate given our off line discussion.

==> I believe that updating Parent DS Record and updating Parent NS
Records for a given child are completely different. Using the same
NOTIFY to either update DS and/or NS records at the Parent zone adds
much more complexity on the Parent side.

It is not necessarily the role of the Parent master server to check
whether the new NS's are resolvable or not. As mentioned Jim Reid,
some TLDs check zone configuration on authoritative nameservers for
the child zone before creating/modifying the child NS
delegation. Checking DNS configuration is for some TLDs far more than
just checking whether the NS names are resolvable or not. Just have a
look at http://www.zonecheck.fr and you see the numerous
mandatory/optional tests one can enable for checking a DNS zone. Once
again, I agree with Jim when he says that how NS's are updated at the
Parent is rather related to the Parent's policy.

My humble suggestion is to deal with only one feature at a time if we
want to add some extra semantics to the NOTIFY message. I think that
the DS update should be simpler.

Regards,

Mohsen.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 12 Jul 2003 07:30:59 +0859 ()

Djb;

> Using glueless names doesn't add any redundancy.

Using third party servers does add redundancy.

> It creates hassles for
> client users,

They are minor issues to be negligible.

> and produces a far larger increase in DNS load than any of

It's me who pointed out that intermingled glueless delegations
sometimes cause loops about 10 years ago.

But, it has nothing to do with "third party servers" and is not
a third-party-server issues.

Use correct terminology.

							Masataka Ohta

---

From: "D. J. Bernstein" <[email-masked]>
Date: 12 Jul 2003 01:26:47 -0000

Masataka Ohta writes:
> nothing to do with "third party servers"

Adding third-party servers has several minor effects, positive and
negative, on DNS load. Someone whined about one of these effects, while
ignoring the _much_ larger effect that gluelessness has on DNS load.

Small efficiency issues have to be viewed in the context of larger
efficiency issues. It's silly to claim that one has ``nothing to do
with'' the other.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 12 Jul 2003 20:34:24 +0859 ()

DJB;

> ignoring the _much_ larger effect that gluelessness has on DNS load.

Issues caused by complicated relationships between servers operated
by a single party has nothing to to with "third party servers", even
if the same issues can be caused by complicated relationships between
servers operated by multiple servers.

> efficiency issues. It's silly to claim that one has ``nothing to do

See above.

						Masataka Ohta