Subject: zones w/ downs syndrom

From: Bill Manning <[email-masked]>
Date: Wed, 2 Aug 2000 08:33:55 -0700 (PDT)

is it useful to distinguish the existance of zone files that consist
of a single SOA record?

-- 
--bill

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

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 02 Aug 2000 10:54:17 -0700

> is it useful to distinguish the existance of zone files that consist

no.  without at least one NS RR, it's not a valid zone.

---

From: "Cricket Liu" <[email-masked]>
Date: Wed, 2 Aug 2000 12:12:55 -0600

> is it useful to distinguish the existance of zone files that consist

Distinguish them from what?  Where?

cricket

---

From: Terry Lambert <[email-masked]>
Date: Wed, 02 Aug 2000 13:21:37 -0700

> no.  without at least one NS RR, it's not a valid zone.

I use such a beast to allow DNSUPDAT to create all of the
other zone data.  This is because DNSUPDAT can't create
SOA recors in masters, for no reason prohibited by the
RFCs, but disallows it for fear it's a slave, not a master
(per the last discussion on DNSEXT on this topic).

I think that it's not a valid zone, but it's "mostly
harmless", at worst.

-- 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: Robert Elz <[email-masked]>
Date: Thu, 03 Aug 2000 07:00:32 +1000

Date:        Wed, 02 Aug 2000 13:21:37 -0700
    From:        Terry Lambert <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think that it's not a valid zone, but it's "mostly
  | harmless", at worst.

It can't be a valid zone, as zones are created by the NS records
that separate them from their parents (and the NS records in the
parent should be a copy of the NS records in the child).

Something with only an SOA record is conceptually no different than
something with only an A record - except that the SOA record makes
no sense in that context.

kre

---

From: Randy Bush <[email-masked]>
Date: Thu, 3 Aug 2000 08:13:13 -0700 (PDT)

%   | I think that it's not a valid zone, but it's "mostly
%   | harmless", at worst.
% 
% It can't be a valid zone, as zones are created by the NS records
% that separate them from their parents (and the NS records in the
% parent should be a copy of the NS records in the child).

	the NS records that separate the zone from its parent
	(in the predominate implementation) are found in the
	parent. If an SOA record, and only an SOA record exists
	in the child, it will appear to not be a lame delegation.
	e.g. a valid delegation.  The statements from yourself, Paul
	and MAP indicate that a valid zone must have at least two
	RR's, an SOA and an NS.  Others (Lars, Andreas, et.al.) think
	that it might be "useable" and therefore is valid.  

	So, this desolves into three questions:

	) what is a valid delegation?
	) what is a valid reception of a delegation?
	) what is a valid zone?

--bill

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 7 Aug 2000 11:08:55 -0700 (PDT)

> is it useful to distinguish the existance of zone files that consist

Apparently this question is Bill's (somewhat provocative) response to
a comment I made at the Pittsburgh interoperability session regarding
such zone files.  Let me explain the background a bit...

I find zones with only a SOA record to be both harmless and quite
useful when setting up new zones by means of dynamic update: a zone
consisting of only the SOA is first created in the master server using
an out-of-band mechanism, and then all the remaining zone data
including the NS records are added using the standard dynamic update
protocol.

Unfortunately, there is an ambiguity in the IXFR protocol that affects
zones with only an SOA.  An incremental transfer is normally
identified by the fact that it begins with two consecutive SOAs, but a
nonincremental (AXFR-style) transfer of a zone with only an SOA will
consist of two consecutive copies of the SOA and will therefore be
misinterpreted as the start of an incremental transfer.

This ambiguity can be resolved by examining the serial numbers of the
SOAs, and I would like to amend the IXFR specification with a
requirement to do exactly that.  However, there seems to be some
opposition to this, on the grounds that zones consisting of only the
SOA supposedly should never exist in the first place.

> parent should be a copy of the NS records in the child).

It may not be considered a valid zone by a resolver, but there is
nothing wrong with it from the perspective of an authoritative server.
I would consider it an operational error to delegate authority to a
zone with no NS records, but such a zone should still be allowed to
exist transiently in its authoritative servers while those servers
are being configured.
-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Aug 2000 15:39:38 -0400

>exist transiently in its authoritative servers while those servers

Now, this may be just a beer-fogged memory of mine, but I thought I once
read that the MNAME in the SOA could serve as an implicit NS record.  I.e.,
the   server in the SOA needn't appear in an NS record.

I thought I once saw this, but I recall another time that I tried to find
the text and failed finding it.

Perhaps this came from RFC 1033:
>SOA  (Start Of Authority)
>
>           <name>  [<ttl>]  [<class>]  SOA  <origin>  <person>  (
>                           <serial>
>                           <refresh>
>                           <retry>
>                           <expire>
>                           <minimum> )
...
>
>   <origin> is the name of the host on which the master zone file
>   resides.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 7 Aug 2000 13:24:20 -0700 (PDT)

> the   server in the SOA needn't appear in an NS record.

It is true that the SOA MNAME need not appear in an NS record, and
it often doesn't in the case of "hidden primary" configurations, where
all the servers listed in NS records are slaves to an unlisted master.

However, this does not mean that the SOA MNAME "serves as an implicit
NS".  Resolvers only send queries to the NSes, never to the SOA
MNAME, and there still has to be at least one NS listed for correct
resolution (and more than one for redundance).
-- 
Andreas Gustafsson, [email-masked]

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 07 Aug 2000 17:56:11 -0400

Loosening IXFR is just addressing a symptom. The *cause* is RFC 2136's
arbitrary restriction on the dynamic addition or deletion of SOA records.
Obsolete that restriction, and you can create the zones entirely through
dynamic update, with the NS records popping into existence
*simultaneously* with the addition of the SOA record. Then you never get
any "down's syndrome" and no IXFR complications.

- Kevin

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 07 Aug 2000 15:44:00 -0700

> arbitrary restriction on the dynamic addition or deletion of SOA records.

Arbitrary?  As the author, let me just say, it's not there arbitrarily.

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 07 Aug 2000 19:36:42 -0400

> Arbitrary?  As the author, let me just say, it's not there arbitrarily.

Maybe "arbitrary" was a bit strong. I've been known to abuse that term at times. Technically, it's not "arbitrary", since a justification is given for the restriction, namely:

"there is no provision for a slave server to be told who its master
   servers are."

To me, this sounds like nothing more than an implementation detail; in truth there are a myriad out-of-band ways to tell a slave server who its masters are, some less convenient, reliable and/or secure than others.

Could you please explain why/how this became a *protocol* restriction? It seems I'm overlooking something which is obvious to everyone else.

                                                                   - Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 08 Aug 2000 00:00:19 -0400

Terry,
           I don't see that every new feature of DNS needs to enhance
security. The point of allowing dynamic zone creation is not to enhance
security, but to provide convenience and productivity for administrators.
It is sufficient, is it not? that it not *harm* security. I don't see that
it does. The security of the Dynamic Updates themselves is, we agree, not
the issue, and as for the security of initiating master/slave
relationships, people can just keep on using the same presumably-secure
out-of-band mechanisms for this as they are using today -- the fact that
the zone was created dynamically doesn't impact this much one way or the
other. What *new* security challenge does dynamic zone-creation raise?

- Kevin

P.S. Of course I have searched the archives for these alleged discussions,
every which way I could think of. They seem to be missing from the
archives, or at least are very well hidden. Pointers or suggestions as to
their whereabouts would be greatly appreciated.

Terry Lambert wrote:

> Paul A Vixie wrote:
> > > Loosening IXFR is just addressing a symptom.  The
> > > *cause* is RFC 2136's arbitrary restriction on the
> > > dynamic addition or deletion of SOA records.
> >
> Anyone who disagrees with that needs to go back and
> read the list archives.
>
> It's not arbitrary.  We all discussed this before.
> It's just not useful in the context of a master;
> the protection is a bit over the top, if your updater
> has already got a security relationship in place with
> the master.
>
> For a slave, it's a real problem, since there is not
> a preexisting security relationship that can be used
> as a lever, without adding more complex transactions
> or assumptions about the master/slave relationship.
>
> Creating zones in a slave is a much harder proposition,
> and the current restriction makes this not a problem.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 8 Aug 2000 08:39:15 +0859 ()

Kre;

> ps: I am deliberately making no comment on the issues of whether IXFR ought
> to be able to deal with a "zone" that contains no more than an SOA record,
> nor whether or not it really should be possible to use dynamic update to
> add the SOA record to a zone.

It is an issue of whether AXFR ought to be able to deal with a "zone"
that contains no more than an SOA record.

							Masataka Ohta

---

From: Terry Lambert <[email-masked]>
Date: Mon, 07 Aug 2000 17:35:00 -0700

-- Terry Lambert

---

From: Robert Elz <[email-masked]>
Date: Tue, 08 Aug 2000 08:48:32 +1000

Date:        Mon, 7 Aug 2000 11:08:55 -0700 (PDT)
    From:        [email-masked] (Andreas Gustafsson)
    Message-ID:  <[email-masked]>

  | I find zones with only a SOA record to be both harmless and quite
  | useful when setting up new zones by means of dynamic update: a zone
  | consisting of only the SOA is first created in the master server using
  | an out-of-band mechanism, and then all the remaining zone data
  | including the NS records are added using the standard dynamic update
  | protocol.

To me, as an operational issue, that just makes no sense.   Is the zone
with an SOA record installed on some server or not (when it is first
created)?   If it is, then how much more difficult can it possibly be to
create the "null" zone with both the SOA and NS record, instead of with
just the SOA record ?

On the other hand, if the zone isn't going to be loaded into any server
at all, then I don't really care what records it has in it, for all practical
purposes it simply doesn't exist.

kre

---

From: Terry Lambert <[email-masked]>
Date: Tue, 08 Aug 2000 14:21:01 -0700

Kevin Darcy wrote:
> Terry,
>            I don't see that every new feature of DNS needs
> to enhance security.

Me neither; however, I do see that it needs to not damage it.

Don't get me wrong.  I am the person who brought this up as
an issue for me, since I didn't like having an out-of-band
interface to support.

> The point of allowing dynamic zone creation is not to
> enhance security, but to provide convenience and productivity
> for administrators.  It is sufficient, is it not? that it not
> *harm* security. I don't see that it does.

The problem is the creation of zones in slaves.

The main arguments are that this is an operational issue,
since the creation of zones over the wire is not specified
as part of the protocol; my argument in the original
discussions was that _it should be_, and that _the purpose
of the wire protocol is to do all operations which can be
dones to a DNS server_.  This makes it a protocol, not an
operational issue.

The problem with slaves is that you would permit arbitrary
data to be enteres into slaves by outside parties by doing
poisining or spoofing of masters, either of which is
unacceptable.

> The security of the Dynamic Updates themselves is, we
> agree, not the issue, and as for the security of
> initiating master/slave relationships, people can just
> keep on using the same presumably-secure out-of-band
> mechanisms for this as they are using today -- the fact
> that the zone was created dynamically doesn't impact this
> much one way or the other. What *new* security challenge
> does dynamic zone-creation raise?

Primarily, the problem is that the OOB mechanism exists
now.  People just don't like it, because it doesn't use
the DNS protocol.

> P.S. Of course I have searched the archives for these
> alleged discussions, every which way I could think of.
> They seem to be missing from the archives, or at least
> are very well hidden. Pointers or suggestions as to

The current mailing list is "[email-masked]",
which is the old address.  You should look in the
archives of the current list, which is actually named
"[email-masked]", so you are probably looking
at the wrong archives (which also explains why this
thread is not being filtered to the correct mailbox by
my MUA).

-- Terry Lambert

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 08 Aug 2000 20:34:02 -0400

> dones to a DNS server_.  This makes it a protocol, not an

I'd love to see a protocol for DNS server configuration as well, and
obviously I'd want it to be secure. But are there any drafts, any
designs, any prototypes for such a thing? Allowing dynamic zone creation
on masters is something that pays off in the near term. I don't see why
a concrete near-term gain should be held hostage to a mere idea or a
promise of better things to come.

> poisining or spoofing of masters, either of which is

Yes, this is a design challenge of the new protocol. Obviously a way
would need to be found to prevent abuses.

> now.  People just don't like it, because it doesn't use

Well, actually, my slaves *do* use the DNS protocol to determine what
zones to start slaving or stop slaving: every night they treewalk-query
their way through our internal-root namespace, checking delegations. So,
technically, I'm not even using an OOB mechanism, yet my slaves always
slave the zones I want them to. Perhaps then you can appreciate why your
angst about OOB mechanisms doesn't carry much weight with me. The lack
of dynamic zone creation is a *much* bigger deal in my particular neck
of the woods. I want to move *all* zone maintenance to secured Dynamic
Update, but there's this annoying little SOA exception...

Even in environments where the tree-walking part of the above approach
is not practical, e.g. in exceptionally large namespaces like the
Internet DNS, I expect one could use the receipt of a new SOA NOTIFY to
trigger a delegation-check and possible subsequent slave zone creation.
For added security, change the NOTIFY spec to allow them to be signed --
only a minor extension and probably overdue anyway.

> thread is not being filtered to the correct mailbox by

Those are list, i.e. mail addresses, but according to
http://www.ietf.org/html.charters/dnsext-charter.html , the
archive location for the WG is ftp://ops.ietf.org/pub/lists. From that
source, I've been able to download namedroppers archives stretching
more-or-less continuously from the present day back to the 80's, yet
I can't find the discussions to which you refer using any of the search
terms I've tried -- many of them. I also checked the dnssec archives: no
success. Any other ideas?

-Kevin