[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
UPDATE is atomic, i.e., all prerequisites must be satisfied or else
no update operations will take place. There are no data dependent
error conditions defined after the prerequisites have been met.
Also note section 3.4.2.4:
3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose NAME,
TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted, unless
the NAME is the same as ZNAME and either the TYPE is SOA or the TYPE is
NS and the matching Zone RR is the only NS remaining in the RRset, in
which case this Update RR is ignored.
Also note pseudocode in section 3.4.2.7, which has only one "return" and
its value is "NOERROR".
> So, you still haven't answered my question. [...] Masataka Ohta
So, yes, I have. Several times now. I note, though, that you have not yet
answered mine, so I'll repeat it: why can't IXFR use UPDATE's wire encoding?
As an implementor yourself, doesn't it bother you to have two slightly
different delta encodings with slightly different semantics?
=========================================================================
Date: Thu, 29 Feb 1996 22:14:33 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: UPDATE edits applied tonight
thanks to masataka ohta for pointing out this minor editorial oversight:
*** 1.9 1996/02/22 21:45:19
--- update.ms 1996/03/01 06:13:27
***************
*** 440,444 ****
and RDATA must match the RR being deleted. TTL must be specified as zero (0)
and will otherwise be ignored by the primary master. CLASS must be
! specified as NONE to distinguish this from an RR addition.
.Sh "2.6 - Reserved Section"
.LP
--- 440,445 ----
and RDATA must match the RR being deleted. TTL must be specified as zero (0)
and will otherwise be ignored by the primary master. CLASS must be
! specified as NONE to distinguish this from an RR addition. If no such RRs
! exist, then this Update RR will be silently ignored by the primary master.
.Sh "2.6 - Reserved Section"
.LP
=========================================================================
Date: Fri, 1 Mar 1996 17:36:47 +1100
Reply-To: Robert Elz <kre@MUNNARI.OZ.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Robert Elz <kre@MUNNARI.OZ.AU>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
In-Reply-To: Your message of "Fri, 01 Mar 1996 14:37:25 +0200."
<199603010537.OAA05283@necom830.hpcl.titech.ac.jp>
Date: Fri, 1 Mar 1996 14:37:25 JST
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Message-ID: <199603010537.OAA05283@necom830.hpcl.titech.ac.jp>
Deletion in section 2.5.4
is NOT described to be silently ignored. Right?
Actually, it is.
Once the pre-reqs have been satisfied, all of the updates are
to be done (or attempted), regardless of whether some of them
fail, there's no stopping part way.
With that you can safely delete something that might not exist
as a part of an update - eg: a host registering its address with
the DNS can say 'delete my old address, add my new address'
without having to check first to see whether it had an old
address to delete.
kre
=========================================================================
Date: Thu, 29 Feb 1996 23:14:00 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: Your message of "Fri, 01 Mar 1996 15:47:40 +0200."
<199603010647.PAA05572@necom830.hpcl.titech.ac.jp>
> Now, I think:
>
> > UPDATE is atomic, i.e., all prerequisites must be satisfied or else
> > no update operations will take place. There are no data dependent
> > error conditions defined after the prerequisites have been met.
>
> is a very bad thing to do.
>
> I think modifying DNS database with sloppy request is not a rational
> thing to do.
Any data dependencies can be expressed in the prerequisites section. Some
updates will have no prerequisites; this is why a previous draft had different
opcodes for ADD vs ADDNAMENEW vs ADDNAMEEXIST. The current draft attempts to
preserve those semantics, which the working group worked long and hard to help
define, while also preserving the RFC 1035 DNS Message Format.
Since a precise update with precise prerequisites is possible, I reject your
characterization of the current UPDATE specification as (sic) "sloppy request."
>> So, yes, I have. Several times now. I note, though, that you have not yet
>> answered mine, so I'll repeat it: why can't IXFR use UPDATE's wire encoding?
>
> IXFR will, if UPDATE format is properly updated.
> Masataka Ohta
That is not a technical objection. I consider my question (above) unanswered.
I will rephrase it, since it's possible that our language barrier is assisting
our miscommunication:
What semantics does IXFR need that
UPDATE's wire format fails to provide?
I have answered the inverse of this question several times. You have not yet
even addressed yourself to the above question, even though this is the fourth
time I have asked it. Please constrain your next reply to that one subject,
if you desire progress in this discussion.
=========================================================================
Date: Fri, 1 Mar 1996 16:06:04 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Robert Elz <kre@munnari.OZ.AU>
In-Reply-To: <22486.825662207@munnari.OZ.AU>; from "Robert Elz" at Mar 1,
96 5:36 pm
> With that you can safely delete something that might not exist
> as a part of an update - eg: a host registering its address with
> the DNS can say 'delete my old address, add my new address'
> without having to check first to see whether it had an old
> address to delete.
I think wild card deletions, if any, do not have to match
anything.
But, for specific deletions, it is too dangerous.
For example, if a host specifically deletes its old address A1,
which someone changed to something else A2, the true old address
A2 remains undeleted.
Masataka Ohta
=========================================================================
Date: Fri, 1 Mar 1996 15:47:40 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Paul A Vixie <paul@vix.com>
In-Reply-To: <9603010612.AA02301@wisdom.home.vix.com>; from "Paul A Vixie" at
Feb 29, 96 10:12 pm
> An oversight. I will correct this in the next editorial update.
> Also note pseudocode in section 3.4.2.7, which has only one "return" and
> its value is "NOERROR".
Describing the same thing in different formats should, surely,
be avoided. :-)
Now, I think:
> UPDATE is atomic, i.e., all prerequisites must be satisfied or else
> no update operations will take place. There are no data dependent
> error conditions defined after the prerequisites have been met.
is a very bad thing to do.
I think modifying DNS database with sloppy request is not a rational
thing to do.
> So, yes, I have. Several times now. I note, though, that you have not yet
> answered mine, so I'll repeat it: why can't IXFR use UPDATE's wire encoding?
IXFR will, if UPDATE format is properly updated.
Masataka Ohta
=========================================================================
Date: Fri, 1 Mar 1996 18:27:57 +1100
Reply-To: Robert Elz <kre@MUNNARI.OZ.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Robert Elz <kre@MUNNARI.OZ.AU>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: Your message of "Fri, 01 Mar 1996 16:06:04 +0200."
<199603010706.QAA05681@necom830.hpcl.titech.ac.jp>
Date: Fri, 1 Mar 96 16:06:04 JST
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <199603010706.QAA05681@necom830.hpcl.titech.ac.jp>
I think wild card deletions, if any, do not have to match
anything.
If by "wild card" you mean '*' (in DNS sense), then those only
operate on the '*' record itself, and are irrelevant. If you
mean 'delete all records' or 'delete all A records' then yes.
But, for specific deletions, it is too dangerous.
I don't see how?
For example, if a host specifically deletes its old address A1,
which someone changed to something else A2, the true old address
A2 remains undeleted.
Surely this depends on what the host wants. Usually I'd say
it would "delete all addresses", "add these addresses", that's
easier. But if all a host cares about is that address X no
longer exists for it, then what is important is that address X
not exist, whether that's because it didn't exist, or because
it is now deleted doesn't really matter.
The general question of the nefarious "someone else" is really
all about who is authorised to make changes, you can get all
kinds of problems if you envisage random others making changes
to something which your model has someone else being responsible
for.
kre
=========================================================================
Date: Fri, 1 Mar 1996 17:34:47 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Robert Elz <kre@munnari.OZ.AU>
In-Reply-To: <22525.825665277@munnari.OZ.AU>; from "Robert Elz" at Mar 1,
96 6:27 pm
Kre;
According to your assumption;
> The general question of the nefarious "someone else" is really
> all about who is authorised to make changes, you can get all
> kinds of problems if you envisage random others making changes
> to something which your model has someone else being responsible
> for.
the authority should grasp how the current state is.
If it doesn't, it should ask. Otherwise, the result is same as
random-others-making-changes.
> Usually I'd say
> it would "delete all addresses", "add these addresses", that's
> easier.
Of course.
> But if all a host cares about is that address X no
> longer exists for it, then what is important is that address X
> not exist, whether that's because it didn't exist, or because
> it is now deleted doesn't really matter.
Can you give realistic example of the case assuming some responsible
authority exist?
Masataka Ohta
=========================================================================
Date: Fri, 1 Mar 1996 17:56:28 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Paul A Vixie <paul@vix.com>
In-Reply-To: <9603010714.AA02982@wisdom.home.vix.com>; from "Paul A Vixie" at
Feb 29, 96 11:14 pm
Paul;
> Any data dependencies can be expressed in the prerequisites section. Some
> updates will have no prerequisites; this is why a previous draft had different
> opcodes for ADD vs ADDNAMENEW vs ADDNAMEEXIST. The current draft attempts to
> preserve those semantics, which the working group worked long and hard to help
> define, while also preserving the RFC 1035 DNS Message Format.
At some meeting, we decided to temporaliry keep the feature only
because Sue put it and there were no strong reason to remove, even
though it makes the protocol complex.
Now, if you want to unify the formats, it is a good reson to remove
redundant feature to make protocols (both IXFR and UPDATE) and
implementations simple.
> Since a precise update with precise prerequisites is possible, I reject your
> characterization of the current UPDATE specification as (sic) "sloppy request."
Since why? Since a precise update is possible without prerequisite, it's
not a reason.
> >> So, yes, I have. Several times now. I note, though, that you have not yet
> >> answered mine, so I'll repeat it: why can't IXFR use UPDATE's wire encoding?
> > IXFR will, if UPDATE format is properly updated.
> That is not a technical objection.
It's not an objection at all. It's my technocal replay.
> I consider my question (above) unanswered.
> I will rephrase it, since it's possible that our language barrier is assisting
> our miscommunication:
>
> What semantics does IXFR need that
> UPDATE's wire format fails to provide?
I'm afraid your question is wrong.
According to your logic, all the protocols will be bloated.
The corrent one would be:
What semantics UPDATE doesn't need that the current
UPDATE's wire format provide?
It's a problem of UPDATE, not IXFR.
> I have answered the inverse of this question several times.
Your currnet answer is because:
"the working group worked long and hard to help define"
which is purely intechnical and too weak as a reason to put
redundant features.
Learn to KISS.
Masataka Ohta
=========================================================================
Date: Fri, 1 Mar 1996 02:00:51 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: Your message of "Fri, 01 Mar 1996 17:56:28 +0200."
<199603010856.RAA06459@necom830.hpcl.titech.ac.jp>
> At some meeting, we decided to temporaliry keep the feature only
> because Sue put it and there were no strong reason to remove, even
> though it makes the protocol complex.
Do you mean, sir, that you have waited from then until now to remind us that
we have been on the wrong track and that none of the complexity we've added
to UPDATE has actually been necessary?
Or do you mean that while UPDATE does not KISS your principles, you are willing
to abstain so long as your own IXFR's fate is not tied to UPDATE's?
> Now, if you want to unify the formats, it is a good reson to remove
> redundant feature to make protocols (both IXFR and UPDATE) and
> implementations simple.
Thus sweeping away the last year of work and discussion in the working group?
>>Since a precise update with precise prerequisites is possible, I reject your
>>characterization of the current UPDATE specification as (sic) "sloppy
>>request."
>
> Since why? Since a precise update is possible without prerequisite, it's
> not a reason.
That it is or is not a reason does not change the fact that the update
operation is not "sloppy" as you said previously. The fact that the update
operations fail silently is meaningless in the presence of the prerequisites
section. We can argue about whether the prerequisites section is the right
way to express this feature, but you cannot and have not successfully argued
that there is anything imprecise about the way it works now.
Precise update without prerequisites requires rollback of partial updates
when some subatomic operation fails. The number and kind of different
operations needed was approaching Turing status. We're not here to design
a programming language.
Finally, there are expressions possible with separate prerequisites that are
not possible if every operation has to _do_ something. I have been to every
DNSIND meeting and I followed the discussion of this very carefully and I am
satisfied that the semantics Sue put in were the best solution we could come
up with. (My quibbles with it had to do with encoding, not feature set.)
> > That is not a technical objection.
>
> It's not an objection at all. It's my technocal replay.
Technical? I think not. You're lobbing grenades and not naming specifics.
> > What semantics does IXFR need that
> > UPDATE's wire format fails to provide?
>
> I'm afraid your question is wrong.
>
> According to your logic, all the protocols will be bloated.
According to my logic, any protocol that works is better than one we argue
about for another year. And, according to my logic, any protocol which
invents something new rather than using something else which is already
defined to perform a superset of the needed functionality is going to cause
unnecessary work for vendors and unnecessary bugs in implementations.
IXFR is not defined in a way that would allow it to be used by UPDATE.
UPDATE is, however, defined in a way that would allow it to be used as
the basic protocol unit of IXFR.
> The corrent one would be:
>
> What semantics UPDATE doesn't need that the current
> UPDATE's wire format provide?
None. The current UPDATE protocol represents the best efforts of the best
collection of DNS brainpower I have ever seen assembled. The feature set
and the prospective uses have been hashed over often enough that I have no
doubt at all as to whether a smaller set or a different way of expressing
them would be "enough better" to justify further churn.
I _cannot_ make the same statement about IXFR, though I have already stated
that it will work and I know of no reason to delay its advancement.
> It's a problem of UPDATE, not IXFR.
Do you really feel that this was the best point in time to bring up a
showstopper?
> > I have answered the inverse of this question several times.
>
> Your currnet answer is because:
>
> "the working group worked long and hard to help define"
>
> which is purely intechnical and too weak as a reason to put
> redundant features.
I was there. Apparently you were not, or if you were, you were not paying
attention or did not understand what was being discussed.
> Learn to KISS.
> Masataka Ohta
I briefly considered a reply to that last rude comment, but I have decided
that you probably do not understand what you said.
I believe that you have made the best effort you can make to work as part of
a group, and that this effort was insufficient to the requirements. At this
point your reason for adhering to IXFR's current definition seems to be that
it's _yours_ and you're not going to let anybody else mess it up. I can't
argue with that, because this isn't about fact or reason any more.
I will implement your IXFR in BIND when your draft becomes a standard. If
I had more time, I would write up a competing IXFR draft and let the IESG
sort it all out. But I don't have time. None of us do. Microsoft NT 4.0
has a WINS-based dynamic update system, and if we're not all very careful
and diligent, it's going to kick our butts.
=========================================================================
Date: Fri, 1 Mar 1996 21:01:23 +1100
Reply-To: Robert Elz <kre@MUNNARI.OZ.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Robert Elz <kre@MUNNARI.OZ.AU>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: Your message of "Fri, 01 Mar 1996 17:34:47 +0200."
<199603010835.RAA06137@necom830.hpcl.titech.ac.jp>
Date: Fri, 1 Mar 96 17:34:47 JST
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <199603010835.RAA06137@necom830.hpcl.titech.ac.jp>
Can you give realistic example of the case assuming some responsible
authority exist?
I don't know if you consider this realistic or not, or whether
you consider me responsible or not, but I do a lot of DNS updates
(hours a day doing nothing else typically). Others also do
(some of) the same updates I do.
If I could use dnyamic update, instead of editing the master
file, and I get a request like
please change the MX record for a.b.c from
p.q.r to x.y.z, I'd like to be able to say
in zone b.c, delete "a.b.c in mx ?? p.q.r", add "a.b.c in mx ?? x.y.z".
(I assume I know what ?? is).
I don't want to delete all the MX's, a.b.c may have other MX's I
am supposed to leave alone.
Further, if it happens that one of the other people who does
these updates has sent the same request, why should I care?
As long as the p.q.r MX is gone, and the x.y.z is installed,
I want to be told "success", and not "you failed" in which case
I would have to go and investigate why.
I don't have to worry about the nw one being installed twice, as
the same data can't exist twice in the DNS, one copy of it is
all that can be present, if the data is there already, the new
one will simply be merged into it (ie: vanish).
kre
=========================================================================
Date: Fri, 1 Mar 1996 05:51:00 PST
Reply-To: Randy Bush <randy@PSG.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Randy Bush <randy@PSG.COM>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: namedroppers <namedroppers@internic.net>
X-cc: iesg <iesg@cnri.reston.va.us>
OK, kiddies. These issues were not raised during WG last call. They do
not seem to be show stoppers now.
You may not like that it does not use Paul's *changed* DynUpd format, but
as I have mentioned to Paul, IMHO that has a very serious problem (the
add/delete granularity is not the same as a user thinks it is unless the
user's view of atomicity is lost).
Can we please differentiate the usual "I would do it differently" bickering
in which so many of this group seem wont to indulge, and issues which make
the IXFR proposal not technically workable?
randy
=========================================================================
Date: Fri, 1 Mar 1996 10:35:00 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: the packet size problem
X-To: "Donald E. Eastlake 3rd" <dee@cybercash.com>
In-Reply-To: Your message of "Fri, 01 Mar 1996 09:51:35 EST."
<Pine.SUN.3.91.960229094356.10948A-100000@cybercash.com>
> I agree that reliable MTU discovery would be hard but you should use what
> MTU info you have and I don't see occasional framentation as fatal.
Fragmentation doesn't worry me. Maybe it's "harmful" as Mogul and Kent said.
Maybe it's not. Who cares? All that matters to me is ICMP unreachables due
to oversized datagrams. Things larger than about 576 bytes can be ICMP'd into
nonexistence by a gateway who does not implement fragmentation for datagrams
larger than that. I need to avoid that.
> Unless the web or something pushes a reasonable "transaction TCP" into
> virtually universal deployment, I agree.
Given:
RFC-1644 - Braden, R. T/TCP -- TCP Extensions for Transactions Functional
Specification. 1994 July; 38 p. (Format: TXT=87362 bytes)
RFC-1379 - Braden, R. Extending TCP for Transactions - Concepts. 1992 November;
38 p. (Format: TXT=91354 bytes)
...and that there is a freely available implementation for SunOS 4.1.3,
another one for BSD (Reno and later) and that FreeBSD includes this in its
basic CDROM, I think this is the technology we ought to use.
HTTP-NG seems to be basing their spec on T/TCP as well.
> I guess an explicitly structured multipacket response could avoid overflowing
> the re-assembly buffer but otherwise is not much better than fragmentation.
I'm not, as I said, concerned about fragmentation. Just datagram lossage.
> If the resovler could say how big its buffer was, then you could send what
> you want up to that although it would be good to take into account known MTU
> info (like at least how big the MTU is on each end's local net connection).
>
> Seems to me just about everyone can handle Ethernet size packets these days
> which would give you about three times the size of the current limit for
> UDP and would go a long way towards reducing truncation.
"Just send big datagrams" is not something I would feel comfortable pushing
for as the next DNS transport standard. Had Router Requirements pushed for
a larger reassembly buffer size, we could use one. They didn't. We can't.
> Big enough transfers probably should use TCP andyway.
Yes. But with your SIGs and KEYs, and IPv6's AAAAs, I think we're going to
be into the 1KB size range before too long, as the average case. I don't
think we want to use TCP in the average case.
=========================================================================
Date: Fri, 1 Mar 1996 10:56:57 -0700
Reply-To: Paul Mockapetris <pvm@HOME.NET>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul Mockapetris <pvm@HOME.NET>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Randy Bush <randy@psg.com>,
namedroppers <namedroppers@internic.net>
X-cc: iesg <iesg@CNRI.Reston.VA.US>
At 05:51 AM 3/1/96 PST, Randy Bush wrote:
>OK, kiddies. These issues were not raised during WG last call. They do
>not seem to be show stoppers now.
>
>You may not like that it does not use Paul's *changed* DynUpd format, but
>as I have mentioned to Paul, IMHO that has a very serious problem (the
>add/delete granularity is not the same as a user thinks it is unless the
>user's view of atomicity is lost).
>
>Can we please differentiate the usual "I would do it differently" bickering
>in which so many of this group seem wont to indulge, and issues which make
>the IXFR proposal not technically workable?
>
>randy
The old IESG will not be considering this matter: it will be left to the new
IESG. Sorry about that, but that's the way the cookie crumbles.
My view is the differences seem to be above the threshold of pointless
bickering, and should be resolved.
paul (new PHONE and postal addresses)
@Home main: 415-944-7200
385 Ravendale direct: 415-944-7221
Mountain View, CA 94043 fax: 415-944-8501
=========================================================================
Date: Fri, 1 Mar 1996 19:10:01 -0800
Reply-To: "Douglas M. Todd, Jr." <doug@FC.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: "Douglas M. Todd, Jr." <doug@FC.COM>
Organization: fc.com, Inc.
Subject: Could some one provide some guidence
X-To: namedroppers@internic.net
with the setting up of two domains with one dns machine?
==DMT>
--
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Douglas M. Todd, Jr.
fc.com, Inc.
One Federal Street BLD 102
Springfield, MA 01105 PHN: 413-733-7333 FAX: 413-733-7725
Email: Doug@fc.com or Bunyan@msn.com
=========================================================================
Date: Sat, 2 Mar 1996 15:34:48 +1100
Reply-To: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Subject: Re: the packet size problem
In-Reply-To: Your message of "Fri, 01 Mar 1996 10:35:00 -0800."
<9603011835.AA04300@wisdom.home.vix.com>
Just a data point here.
A compressed A RR takes 2+2+2+2+4+4 = 16 bytes.
A compressed AAAA RR takes 2+2+2+2+4+16 = 28 bytes.
This format shows the greatest percentage growth. I would expect
once all the overhead is taken into account you will see packet
approximently 50% bigger than their A counterparts.
Mark
--
Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au
UUCP: ....!uunet!syd.dms.csiro.au!marka
=========================================================================
Date: Sat, 2 Mar 1996 19:18:05 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Paul A Vixie <paul@vix.com>
In-Reply-To: <9603011000.AA03779@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 1, 96 2:00 am
> > At some meeting, we decided to temporaliry keep the feature only
> > because Sue put it and there were no strong reason to remove, even
> > though it makes the protocol complex.
>
> Do you mean, sir, that you have waited
I haven't waited. I pointed it out in the WG meeting.
> from then until now to remind us that
> we have been on the wrong track and that none of the complexity we've added
> to UPDATE has actually been necessary?
As the WG consensus, when I pointed it out, was to keep the feature
temporarily, why you think the complexity was necessary?
> Thus sweeping away the last year of work and discussion in the working group?
Is it a technical problem?
Now, I have a question to you: which protocol is likely to be wrongly
implemented?
1) complex one
2) simple one
You can assume they share the same power.
Masataka Ohta
=========================================================================
Date: Sat, 2 Mar 1996 19:27:07 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Robert Elz <kre@munnari.OZ.AU>
In-Reply-To: <22550.825674483@munnari.OZ.AU>; from "Robert Elz" at Mar 1,
96 9:01 pm
> Can you give realistic example of the case assuming some responsible
> authority exist?
>
> I don't know if you consider this realistic or not, or whether
> you consider me responsible or not, but I do a lot of DNS updates
> (hours a day doing nothing else typically).
I'm afraid:
> please change the MX record for a.b.c from
> p.q.r to x.y.z, I'd like to be able to say
>
> in zone b.c, delete "a.b.c in mx ?? p.q.r", add "a.b.c in mx ?? x.y.z".
> (I assume I know what ?? is).
"(I assume I know what ?? is)" is unrealistic, unless you have
queried MX.
Moreover, if you process a request:
> please change the MX record for a.b.c from
> p.q.r to x.y.z
and someone else process another request:
> please change the MX record for a.b.c from
> x.y.z to u.v.w
in a wrong order, it might not be a responsible behaviour.
Moreover, I think I can give you a suggestion. If you are so busy
changing DNS database,
> Further, if it happens that one of the other people who does
> these updates has sent the same request, why should I care?
it will reduce your work load to partition work and never perform
the same change twice.
Masataka Ohta
=========================================================================
Date: Sat, 2 Mar 1996 13:09:33 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: Your message of "Sat, 02 Mar 1996 19:18:05 +0200."
<199603021018.TAA02097@necom830.hpcl.titech.ac.jp>
> > > At some meeting, we decided to temporaliry keep the feature only
> > > because Sue put it and there were no strong reason to remove, even
> > > though it makes the protocol complex.
Now that I've considered this for an extra day, I disagree with the above
characterization of events. Please consider the current encoding and note
that we cannot define a datagram or stream for UDP/53 or TCP/53 that does
not comform to the DNS Message Format defined by RFC 1035. Note the clever
(some say insane) overloading I've put into CLASS to make room for all the
kinds of updates we have defined. Ask yourself how we would also express
the different prerequisites for these updates, since to get an UPDATE with
no prerequisites sections, the update ops would have to contain their own
prerequisites as Sue's did with ADDNAMENEW and ADDNAMEEXIST and so on.
To implement the requirements of section 5 of dynDNS-07, the best method I
can come up with is a separate prerequisites section. I am not willing to
participate anew in the debate as to whether the section 5's requirements are
all valid; I think they were and I think they still are and if you don't
agree then we are going to have to agree to disagree.
If you think there's a simpler encoding for update operations than I have,
that will preserve the ability to meet the requirements in section 5, I am
listening (keenly).
> > Do you mean, sir, that you have waited
>
> I haven't waited. I pointed it out in the WG meeting.
Your objection was noted at the time and the consensus went against you. As
someone whose objections have often failed to sway the consensus, I can tell
you that you are at this moment tilting at a windmill if you want to rewrite
section 5, which I remember to be the basis of your objections anyway.
> > from then until now to remind us that
> > we have been on the wrong track and that none of the complexity we've added
> > to UPDATE has actually been necessary?
>
> As the WG consensus, when I pointed it out, was to keep the feature
> temporarily, why you think the complexity was necessary?
See above.
> > Thus sweeping away the last year of work and discussion in the
> > working group?
>
> Is it a technical problem?
It is a reality problem. We can't take another year at this. The world is
not sitting on its hands waiting for us to finish our discussion.
> Now, I have a question to you: which protocol is likely to be wrongly
> implemented?
>
> 1) complex one
>
> 2) simple one
>
> You can assume they share the same power.
> Masataka Ohta
I would say that a protocol with two similar yet incompatible encodings for
similar features of which one is a subset of the other, is going to be harder
to implement correctly.
=========================================================================
Date: Sat, 2 Mar 1996 18:39:23 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
In-Reply-To: randy@PSG.COM's message of 1 Mar 1996 06:09:22 -0800
>Can we please differentiate the usual "I would do it differently" bickering
>in which so many of this group seem wont to indulge, and issues which make
>the IXFR proposal not technically workable?
>
>randy
I've said it before and I'll say it again: I know of no issues which will
make IXFR as sent to the IESG "not technically workable." If I did, I
would have spoken up during WG last call.
My objection is light weight; if the IESG kicks it back, you'll all be
hearing more from me on the subject. If IESG stamps it "proposed standard"
then I will implement it in BIND, as-is.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Sat, 2 Mar 1996 18:43:18 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: the packet size problem
In-Reply-To: Mark.Andrews@DMS.CSIRO.AU's message of 1 Mar 1996 20:47:22 -0800
> This format shows the greatest percentage growth. I would expect
> once all the overhead is taken into account you will see packet
> approximently 50% bigger than their A counterparts.
Indeed. So, when I say "dig dec.com mx" and get back a 373 byte reply,
I am safe in assuming that if all the A RRs were AAAA RRs, it would have
been a 560 byte reply. We are all assuming that these AAAA RRs won't be
signed.
So, T/TCP anyone?
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Sun, 3 Mar 1996 14:41:30 +1100
Reply-To: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Subject: Re: the packet size problem
X-To: Paul A Vixie <paul@vix.com>
In-Reply-To: Your message of "Sat, 02 Mar 1996 18:43:18 -0800."
<VIXIE.96Mar2184316@wisdom.vix.com>
> > This format shows the greatest percentage growth. I would expect
> > once all the overhead is taken into account you will see packet
> > approximently 50% bigger than their A counterparts.
>
> Indeed. So, when I say "dig dec.com mx" and get back a 373 byte reply,
> I am safe in assuming that if all the A RRs were AAAA RRs, it would have
> been a 560 byte reply. We are all assuming that these AAAA RRs won't be
> signed.
>
> So, T/TCP anyone?
I suspect the web will force the vendors hands here or we will
all have to learn how to tune the existing kernels to cope.
We can't mandate T/TCP we can however abserve what is happening
and lodge Requests For Enhancements with our vendors. Keep track
of those error counters.
Mark
> --
> Paul Vixie
> La Honda, CA "Illegitimibus non carborundum."
> <paul@vix.com>
> pacbell!vixie!paul
>
--
Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au
UUCP: ....!uunet!syd.dms.csiro.au!marka
=========================================================================
Date: Mon, 4 Mar 1996 08:58:26 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: Paul A Vixie <paul@vix.com>
In-Reply-To: <9603022109.AA08828@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 2, 96 1:09 pm
> > > > At some meeting, we decided to temporaliry keep the feature only
> > > > because Sue put it and there were no strong reason to remove, even
> > > > though it makes the protocol complex.
>
> Now that I've considered this for an extra day, I disagree with the above
> characterization of events.
I think you have forgotten my explanation on how atomicity is maintained
with simple data format.
(1) Get SOA serial (or any serialization number)
(2) Check whatever prerequisites with normal DNS query
(3) Send update with no prerequisite but with deletion
request of SOA obtained at (1), failure of which should
cause atomic failure of the entire update.
I explained this method to WG, which was the reason why:
> > > > At some meeting, we decided to temporaliry keep the feature only
> > > > because Sue put it and there were no strong reason to remove, even
> > > > though it makes the protocol complex.
was discussed.
With the above approach, name servers don't have to have any code
for prerequisite, while updaters can ask ANY strange prerequisite
such as partial match, logical OR condition etc.
I do assume that failure of non-wild-card deletion voids the entire
update. So, I want to know a realistic example on whether it matters
or not.
> If you think there's a simpler encoding for update operations than I have,
> that will preserve the ability to meet the requirements in section 5, I am
> listening (keenly).
See above. I did post it to the ML. If you want to confirm, try to search
a word "optimistic" in ML log.
> It is a reality problem. We can't take another year at this. The world is
> not sitting on its hands waiting for us to finish our discussion.
It seems to me that that is a good reason to choose a simpler protocol.
And, on the plain to LA, I remember one reason on why my format is
good to IXFR.
That is, the format allows to pack multiple updates in a single UDP packet.
With the current dynupd format, it is impossible to pack them, unless
we (newly?) allow to pack multiple messages into a single UDP
packet (which may not be disallowed by RFC103[45]).
Masataka Ohta
Masataka Ohta
=========================================================================
Date: Mon, 4 Mar 1996 10:15:03 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: Last Call: Incremental Zone Transfer in DNS to Proposed
X-To: wsimpson@GREENDRAGON.COM
In-Reply-To: <5026.wsimpson@greendragon.com>; from "William Allen Simpson" at
Mar 1, 96 2:24 am
Bill;
> In addition, I believe that the draft places too much emphasis on UDP
> instead of TCP transfers. The recommendation that UDP be tried
> first (page 2) merely adds to the traffic in the most likely case for
> need of IXFR -- rapidly changing large zones that will be ultimately too
> large for UDP.
As UDP SOA query is, anyway, necessary, there is no increase of
traffic.
> Moreover, I believe that the draft places too much emphasis on sending
> all the many small differential updates, rather than "optional"
> condensation. Insufficient rationale is given in the draft for the
> usefulness of this mode of operation, and it is made the default.
When I asked for examples on why that mode is useful, Kre has kindly
answered but no one else.
> Finally, the author has not availed himself of repeated offers of
> assistance in correcting grammer, punctuation, and overall flow of the
> document.
I have put all such assistances to the draft (unless some of them
conflicts each other).
> I had hoped that the latest draft would have reflected the
> proffered assistance of members of the list.
It has.
> However, all of these issues had been previously raised on the WG list.
So can the current draft be as it is now.
I'd like to thank all the contributers, again.
> A new issue is how to handle zones that are greater than 64K.
See BIND.
Masataka Ohta
=========================================================================
Date: Sun, 3 Mar 1996 00:44:19 -0800
Reply-To: Paul Wren <Paul.Wren@SOFTWARE.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul Wren <Paul.Wren@SOFTWARE.COM>
Subject: Power PC NT port of BIND-NT 4.9.3p1 with GUI Install, Applet
X-To: bind-users-request@vix.com, bindnt-request@drcoffsite.com,
namedroppers@internic.net
PowerPC NT Version:
BIND-NT 4.9.3 with a graphical installation program and GUI control-panel applet
is now available for the PowerPC architecture at http://www.software.com,
joining the previously available Intel, MIPS, and Alpha ports from the same
place.
This is the same code available from Larry Kahn for NT and Paul Vixie for
Unix, (and unlike some other recent interlopers, all credit goes to _them_)
but packaged as an easily-installed binary. We are making it available to
help our customers of Post.Office that need a DNS they can get running
relatively painlessly.
The PowerPC port uses MS Visual C++ V4.0, which makes it a "beta" since
Larry Kahn is still using 2.2 due to some compatibility headaches. The port
runs and is stable in our own in-house testing, but we would recommend
caution before committing production systems to this port.
Since it is still freeware we can't spend a ton of time on support, although
we will be glad to help to the extent possible, at the address
DNS@software.com. Primarily BIND is still a group-support effort from the
existing mailing lists.
=========================================================================
Date: Wed, 6 Mar 1996 12:00:28 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: rcode = zone_error needed in DNS UPDATE draft?
In-Reply-To: vbais@PALLAS2.INTEL.COM's message of 28 Feb 1996 15:16:22 -0800
I will add a NOTZONE error and signal it from the prerequisites and
update-prescan sections. Zone section processing will still signal
NOTAUTH since this is a different error.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Wed, 6 Mar 1996 18:42:55 -0500
Reply-To: "john.p.mcnicholas" <john.p.mcnicholas@AWO.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: "john.p.mcnicholas" <john.p.mcnicholas@AWO.COM>
Subject: Noforward with Internal Root
X-To: "todd s. aven" <todd.aven@bankerstrust.com>
X-cc: bind <bind@uunet.uu.net>
Todd, thank you for your help regarding my question that I posted to
namedroppers on 2/13/96. I have since obtained a clean compile of bind 4.9.3
with your noforward command. The only thing I had to change was to define
TRUE=1 and FALSE=0 in ns_forw.c. However, I'm experiencing some strange things.
I set the name server up as an internal root. It has delegated authority for a
subdomain to a child server. Resolving queries for all internal domains works
fine. However, queries about subdomain hosts cause "noforward: dname=FQDN" to
appear in the named.run. Is this normal?
Then I add a forwarders command to the internal root to allow internal users to
resolve external names. Queries bound for internal subdomains then get
forwarded to the external NS. However, queries for external hosts don't get
past the internal root. My guess is that the internal root considers itself
god and refuses to forward queries for unknown domains.
Then I add a noforward command to prevent queries from being forwarded to
novell.com. Now, the internal subdomain queries still get forwarded to the
external NS but not until it's compared to the noforward table. Queries for
www.novell.com or any other external domain still don't make it past the
internal root.
Finally, I add an additional noforward command to include the internal
subdomain. Queries for that subdomain are again compared against the noforward
table. This time, a match is found and the query is correctly forwarded to the
subdomain NS. Outbound queries for external hosts are still stopped by the
Internal root without any reference to forwarders nor noforwarders.
The Internal root's named.root file:
. IN SOA issns5002.awo. dnsadmin.issns5002.awo. (
199603051 ; serial
14400 ; refresh
3600 ; retry
3600000 ; expire
14400 ) ; minimum
IN NS issns5002.awo.
issns5002.awo. 14400 IN A 10.0.10.25
Any help would be greatly appreciated,
John
=========================================================================
Date: Thu, 7 Mar 1996 12:20:35 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: rcode = zone_error needed in DNS UPDATE draft?
X-To: paul@VIX.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <VIXIE.96Mar6120020@wisdom.vix.com>; from "Paul A Vixie" at Mar
6, 96 12:00 pm
> I will add a NOTZONE error and signal it from the prerequisites and
> update-prescan sections.
Paul, could you explain why you think the prerequisite section
still necessary?
Masataka Ohta
=========================================================================
Date: Wed, 6 Mar 1996 19:57:58 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: rcode = zone_error needed in DNS UPDATE draft?
X-To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: Your message of "Thu, 07 Mar 1996 12:20:35 +0200."
<199603070320.MAA16776@necom830.hpcl.titech.ac.jp>
> > I will add a NOTZONE error and signal it from the prerequisites and
> > update-prescan sections.
>
> Paul, could you explain why you think the prerequisite section
> still necessary?
> Masataka Ohta
I have done so. Several times. All I can do at this point is remind you
that we have reached "working group consensus" on the semantics of UPDATE
in draft-07. You are the only dissenter. Life goes on.
=========================================================================
Date: Wed, 6 Mar 1996 19:08:00 CST
Reply-To: Len Lynch <llynch@MCS.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Len Lynch <llynch@MCS.COM>
Subject: Stealth DNS inquiry
X-To: john.p.mcnicholas@AWO.COM, namedroppers@rs.internic.net,
tserle@MELPAR.ESYS.COM
I'm battling with BIND! So far it's winning.
I saw a few others battling with 4.9.x, is this because 4.8.3 has problems
with stealth DNS as well?
I'm having problems with the forwarders, the problem is that they forward too
well, things that they should be authoritative for are still forwarded...
1) Has anyone run across a FAQ on setting up 'stealth' internal DNS setups?
I know that this is not something that should be entered into lightly.
2) All my available sources (BIND and DNS, BIFW's, ctpd.faq, BOG, etc) say
that you should not add entries into the cache file. It is in not clear to
me that what is called for is an internal root server. I see peole taking
this line action. Is this the only way?
3) Firewall books talk about having a 'fake' external DNS that answers for the
world, and an internal that houses the internal domains. The internal DNS
uses forwarders to resolve addresses that it is not aware of. Using this setup
does the internal domain HAVE to be the same as the external domain name for
it to work and for delegation to work within the internal net?
4) The problem I see with having the same parent zones inside and outside is
that it is not easily maintained, and if you need to setup additional servers
to provide redundancy, your management problems really kick-in.
5) Is it legal to have an internal root server that still forwards? If so
what version of BIND is suggested to "cut" ones teeth on?
Thanks!
-LLL
-----------------------------------+---------------------------------------
Lenard Lynch, TIS Analyst RM917 | http://www.mcs.com/~llynch/
Tribune Information Networks | 435 N.Michigan Ave, Chicago, IL 60610
llynch@tribune.com || @mcs.com | 312.222.2482:vox, 312.222.2626:fax
=========================================================================
Date: Thu, 7 Mar 1996 14:13:29 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: rcode = zone_error needed in DNS UPDATE draft?
X-To: Paul A Vixie <paul@vix.com>
In-Reply-To: <9603070357.AA12446@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 6, 96 7:57 pm
> I have done so. Several times. All I can do at this point is remind you
> that we have reached "working group consensus" on the semantics of UPDATE
> in draft-07. You are the only dissenter. Life goes on.
We have reached the "working group consensus" on the
semantics of IXFR. It has even finished the WG last call.
So, if you object, make your objection technically founded.
So far, your only technical claim is that UPDATE is so only
because you wrongly thought prerequisite were necessary, which
was technically proven to be wrong long before.
Masataka Ohta
=========================================================================
Date: Thu, 7 Mar 1996 01:01:55 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: rcode = zone_error needed in DNS UPDATE draft?
In-Reply-To: mohta@NECOM830.HPCL.TITECH.AC.JP's message of 6 Mar 1996 23:57:48
-0800
> So, if you object, make your objection technically founded.
My argument is from software engineering economics, not technology. My
informal poll of three vendors here at IETF in LA yielded a 100% result of
"yes, the IETF is going to look like a collection of idiots if they come up
with two similar-but-different encodings that could have been a single
encoding."
IXFR will work. But it would also work, albeit without its UDP capability,
if it used the UPDATE delta encoding instead of what it uses now. I don't
consider the UDP transport for IXFR to be a significant loss, for reasons I
explained in person a few hours ago. The changes you're suggesting for
UPDATE to make it work without a prerequisites section would be far more
sweeping, and would remove the ability to use fine- grained marker records
whose value or presence is not being changed by the update -- a loss which
would constrain UPDATE's future uses quite seriously.
> So far, your only technical claim is that UPDATE is so only
> because you wrongly thought prerequisite were necessary, which
> was technically proven to be wrong long before.
I hope our in-person discussion this evening in the terminal room was as
informative and educational for you as it was for me.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Thu, 7 Mar 1996 01:22:33 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: forwarding loops in UPDATE
Viraj Bais of Intel and our own Masataka Ohta each took the time to tell me
today that the forwarding algorythm of dynDNS-07 (section 6) was susceptible
to forwarding loops.
My cheap solution was to require that the ID and message be compared to
other things on the forwarding queue before a message was forwarded;
Ohta-san pointed out that my draft specifies that a new ID be assigned
during forwarding. Thus all forwarded packets will differ even if looping.
The reason for assigning a new ID is that the <ID,sourceaddr,sourceport> is
how a server determines that it has received a duplicate request, and the
<sourceaddr,sourceport> will be different when the packet is forwarded, thus
requiring a new ID to be generated so as to prevent inadvertant duplicate
<ID,addr,port> tuples. So, no help there.
My next cheap solution was to compare only the message content. Ohta-san and
I realized at about the same instant that this could result in false positives
in the loop detection. (It turns out that BIND does this for queries already,
but that's no excuse.)
Ohta-san's next suggestion was to remove the forwarding capability, since he
does not see merit in my firewall argument (wherein the primary master server
is separated from update clients by a firewall, but slave servers are able
to reach to both horizons and therefore forward from one to the other). I
still think we need to address the firewall case.
My own thinking is that we can get away with just warning server administrators
that an AXFR dependency graph with loops in it will have catastrophic failure
modes for UPDATE even though they were totally acceptable for QUERY(AXFR).
The looping AXFR graph is never necessary for correct server operation, and
has almost always been inadvertent and an error when I've encountered it in
real life.
I think the document can progress with only a small added warning.
We will no doubt hear more about this at tomorrow's DNSIND meeting. But not
everyone on namedroppers will be at the meeting, and as Randy used to like to
remind us, the WG is the mailing list, not the folks who come to meetings.
Since I already know about this issue, I'm reporting it to the whole WG (you).
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Thu, 7 Mar 1996 10:58:01 -0800
Reply-To: "Todd S. Aven" <Todd.Aven@BANKERSTRUST.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: "Todd S. Aven" <Todd.Aven@BANKERSTRUST.COM>
Subject: Re: Stealth DNS inquiry
X-To: Len Lynch <llynch@MCS.COM>
In-Reply-To: <m0tuUBn-0003l5C@mercury.mcs.com>
Len,
On Wed, 6 Mar 1996, Len Lynch wrote:
> I'm having problems with the forwarders, the problem is that they forward too
> well, things that they should be authoritative for are still forwarded...
The algorithm imbedded in 4.9.3 dictates the following process for name
resolution:
1. Is the data held locally? This can be either because the answer is
cached or the server is authoritative for the zone. If so, return the answer
directly.
2. Are there forwarders? If so, send the query to them.
3. Is an NS record available for the requested domain or some point closer
to the root? If so, refer/recurse to the authoritative server(s).
Note carefully that if you have a forwarder defined, you'll never get to (3)!
A typical split-DNS environment is an internal DNS server authoritative for
some or all internal zones forwarding to a DNS server on the firewall
authoritative for external zone(s) and able to resolve against the full
public DNS hierarchy. The forwarding bit causes the problems you observe.
I wrote some simple patches to BIND 4.9.3-REL that allow you to modify this
process so that (2) is skipped for certain domain hierarchies that you
specify.
> 2) All my available sources (BIND and DNS, BIFW's, ctpd.faq, BOG, etc) say
> that you should not add entries into the cache file. It is in not clear to
> me that what is called for is an internal root server. I see peole taking
> this line action. Is this the only way?
The 'false-root' approach allows you to delegate domains to yourself
(internally). Unfortunately, the forwarders configuration obviates the
delegation.
My preference is to avoid false roots and instead use a 'stub' directive for
each internal 'top-level' zone to load only the NS records for the zone into
the forwarding server. By 'top-level', I mean both name->address and
address->name (in-addr.arpa) zones.
Of course, if you make your forwarding internal server authoritative for
all zones, you don't need 'noforward' or 'stub' or even false roots. It
just happens that for reasonable size enterprises, this is neither
desirable nor feasible.
> 3) Firewall books talk about having a 'fake' external DNS that answers for the
> world, and an internal that houses the internal domains. The internal DNS
> uses forwarders to resolve addresses that it is not aware of. Using this setup
> does the internal domain HAVE to be the same as the external domain name for
> it to work and for delegation to work within the internal net?
Definitely not. In fact, you may find life easier if your external domain is
different from your internal domain, when it comes to failure modes of SMTP
mail forwarding on the firewall.
> 4) The problem I see with having the same parent zones inside and outside is
> that it is not easily maintained, and if you need to setup additional servers
> to provide redundancy, your management problems really kick-in.
If your internal and external zones contain distinct (different) data, I
don't see how it would be more or less difficult if the domain names are
the same.
> 5) Is it legal to have an internal root server that still forwards? If so
> what version of BIND is suggested to "cut" ones teeth on?
I have not tested my 'noforward' patches with a false-root configuration. If
it works, please let me know.
Regards,
Todd.Aven@BankersTrust.Com
=========================================================================
Date: Thu, 7 Mar 1996 11:08:34 -0800
Reply-To: "Todd S. Aven" <Todd.Aven@BANKERSTRUST.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: "Todd S. Aven" <Todd.Aven@BANKERSTRUST.COM>
Subject: Re: Noforward with Internal Root
X-To: "john.p.mcnicholas" <john.p.mcnicholas@awo.com>
X-cc: bind <bind@uunet.uu.net>
In-Reply-To: <9603062341.AA2863@CServe-Hub4.inhouse.compuserve.com>
John,
As I mentioned in my posting on namedroppers moments ago, I have never tested
the 'noforward' patches with the false-root scenario. In fact, my preference
is to avoid that configuration entirely. Instead, I use the 'stub' directive
to load the top-level internal zone's NS records on the forwarding server for
which it is not authoritative and for which a 'noforward' directive exists.
Subordinates of zones that are not being forwarded will thus be reachable by
standard recursion/referral.
Regards,
Todd.Aven@BankersTrust.Com
=========================================================================
Date: Thu, 7 Mar 1996 03:43:20 -0800
Reply-To: Don Lewis <gdonl@GV.SSI1.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Don Lewis <gdonl@GV.SSI1.COM>
Subject: Re: Noforward with Internal Root
X-To: "Todd S. Aven" <Todd.Aven@BANKERSTRUST.COM>
In-Reply-To: "Todd S. Aven" <Todd.Aven@BANKERSTRUST.COM> "Re: Noforward with
Internal Root" (Mar 7, 11:08am)
On Mar 7, 11:08am, "Todd S. Aven" wrote:
} Subject: Re: Noforward with Internal Root
} John,
}
} As I mentioned in my posting on namedroppers moments ago, I have never tested
} the 'noforward' patches with the false-root scenario.
I doubt that your patches would do anything useful in the configuration.
If your domain is foo.com, and your fake-root server receives a query for
baz.net, it will answer with an authoritative NXDOMAIN, patches or no,
unless you delegate *all* the top level domains. I would think this would
be a configuration nightmare.
The fake-root configuration is only useful if you don't want your internal
DNS to be able to resolve any external names. Youp probably only want to
do this if you don't have any IP connectivity to the net. Generally, what
you do is configure your email software to forward all email that doesn't
match your internal domain name to a smart host on the Internet that is
able to access the outside DNS and actually deliver the mail. The transfer
mechanism for email being sent to the smart host is often UUCP.
--- Truck
=========================================================================
Date: Thu, 7 Mar 1996 11:42:00 CST
Reply-To: Len Lynch <llynch@MCS.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Len Lynch <llynch@MCS.COM>
Subject: Re: Stealth DNS configuration
X-To: namedroppers@rs.internic.net
On Mar 7, 11:08am, "Todd S. Aven" wrote:
+
+> 3) Firewall books talk about having a 'fake' external DNS that answers for the
+> world, and an internal that houses the internal domains. The internal DNS
+> uses forwarders to resolve addresses that it is not aware of. Using this setup
+> does the internal domain HAVE to be the same as the external domain name for
+> it to work and for delegation to work within the internal net?
+
+Definitely not. In fact, you may find life easier if your external domain is
+different from your internal domain, when it comes to failure modes of SMTP
+mail forwarding on the firewall.
+
So far I'm with you, I agree that I will find it easier to have my internal
and external domains different. The $64000 question is: Does the internal
domain HAVE to be a subdomain of the current parent domains (com, net, edu,
us, org, etc.)? What I have been attempting, unsuccesffully, is to configure
an internal domain (and that there is no confusion that it is definately an
internal domain and not the hidden part of an external domain) that ends in
a company abbreviation (i.e. business_unit.company_abbrev.).
I was configuring an internal Macintosh using OpenTransport the other day (
some of my users are creative types) and it would not allow me to add the
internal company_abbrev. as a valid suffix for the resolver search criteria.
Is this because it is not legal for objects to exist in a first level domain?
I am using SunOS 5.4 and the 4.8.3 BIND that is supported by Sun. When I setup
the internal NS on the private domain, it works well. I am experiencing
problems with getting other zones inside of the private domain to recognize
each other and exchange records. I tend to think that I'm not understanding
something about configuring this "primary private NS" and not understanding
how the other internal zones should relate to this primary.
If I've got X business units that all want to manage their own DNS, do these
have to be secondaries for the primary pirvate NS that the FireWall will talk
to directly? Are these "remote" DNS servers set up to be forwarders as well?
If so, do they forward to the Firewall or to the primary NS that the FireWall
will resolve to?
Thanks,
-----------------------------------+---------------------------------------
Lenard Lynch, TIS Analyst RM917 | http://www.mcs.com/~llynch/
Tribune Information Networks | 435 N.Michigan Ave, Chicago, IL 60610
llynch@tribune.com || @mcs.com | 312.222.2482:vox, 312.222.2626:fax
=========================================================================
Date: Fri, 8 Mar 1996 09:30:38 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: IXFR/UPDATE format
X-To: paul@VIX.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <VIXIE.96Mar7010152@wisdom.vix.com>; from "Paul A Vixie" at Mar
7, 96 1:01 am
> > So, if you object, make your objection technically founded.
>
> My argument is from software engineering economics, not technology.
I think it technical to discuss which format is more economical
to reduce the software engineering effort.
> My
> informal poll of three vendors here at IETF in LA yielded a 100% result of
> "yes, the IETF is going to look like a collection of idiots if they come up
> with two similar-but-different encodings that could have been a single
> encoding."
I agree.
> IXFR will work. But it would also work, albeit without its UDP capability,
> if it used the UPDATE delta encoding instead of what it uses now. I don't
> consider the UDP transport for IXFR to be a significant loss, for reasons I
> explained in person a few hours ago.
You are now trying to pack multiple RRs (upto 64KB) in TCP
AXFR messages.
Are there any reason not to do so with IXFR?
If there aren't, the current UPDATE format is no good even on
TCP transport.
That is, a nameserver should add some separater RRs, which will most
naturally be the current and/or updated SOA. The nameserver then, should
remove the separater RR from the update data section to prevent
confusion. At this time, the nameserver will delete prerequisite
section, which is not necessary for IXFR, without much added
complexity.
So, the remaining difference is on how deletions and additions
are represented.
BTW, IXFR does work as a newtype query RR for compactified zone
transfer because, between nameservers of the next age, IXFR
query is used even if it results in the full zone transfer.
> The changes you're suggesting for
> UPDATE to make it work without a prerequisites section would be far more
> sweeping,
Far more sweeping to reduce implementation effort, especially when
forwarding is also removed. :-)
> and would remove the ability to use fine- grained marker records
> whose value or presence is not being changed by the update -- a loss which
> would constrain UPDATE's future uses quite seriously.
I'm not against to use the fine-grained marker. I did write "SOA
(or any marker)".
Masataka Ohta
=========================================================================
Date: Thu, 7 Mar 1996 18:48:41 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: diffs from dynDNS-07 to dnsDNS-08, per DNSIND meeting at LA IETF
X-To: namedroppers@internic.net
4. added section 1.2 (renumbering 1.3), 7.19, 7.20, 7.21 and 7.22 per
conversation with PVM re: glue RR updates and zone cut clarifications.
3. added a NOTZONE error code and used it from within prerequisites processing
and update prescan sections. several section numbers changed.
2. changed the Reserved Section's name to "Additional Data Section" to be
compatible with current Secure DNS Updates draft.
1. added a sentence to the end of section 2.5.4 to make it compatible with
the surrounding text.
*** update.ms 1996/02/22 21:45:19 1.9
--- update.ms 1996/03/08 02:30:52
***************
*** 18,20 ****
.nr DI +3m
! .ds LF Expires September 1996
.ds CF
--- 19,21 ----
.nr DI +3m
! .ds LF Expires October 1996
.ds CF
***************
*** 22,24 ****
.ds LH INTERNET-DRAFT
! .ds RH February 1996
.ds CH DNS UPDATE
--- 23,25 ----
.ds LH INTERNET-DRAFT
! .ds RH March 1996
.ds CH DNS UPDATE
***************
*** 31,35 ****
INTERNET-DRAFT Susan Thomson (Bellcore)
! <draft-ietf-dnsind-dynDNS-07.txt> Yakov Rekhter (Cisco)
Jim Bound (DEC)
! February 1996
.fi
--- 32,36 ----
INTERNET-DRAFT Susan Thomson (Bellcore)
! <draft-ietf-dnsind-dynDNS-08.txt> Yakov Rekhter (Cisco)
Jim Bound (DEC)
! March 1996
.fi
***************
*** 136,138 ****
.RE
! .Sh "1.2 - New Assigned Numbers"
.DS
--- 137,144 ----
.RE
! .Sh "1.2 - Glue RRs"
! .LP
! For the purpose of determining whether a domain name used in the UPDATE
! protocol is contained within a specified zone, a domain name is ``in'' a zone
! if it is owned by that zone's domain name. See section 7.19 for details.
! .Sh "1.3 - New Assigned Numbers"
.DS
***************
*** 143,144 ****
--- 149,151 ----
RCODE = NOTAUTH (TBD: 9?)
+ RCODE = NOTZONE (TBD: 10?)
Opcode = UPDATE (5)
***************
*** 164,166 ****
+---------------------+
! | Reserved | reserved for future use
+---------------------+
--- 171,173 ----
+---------------------+
! | Additional Data | additional data
+---------------------+
***************
*** 172,175 ****
invariants (in terms of zone content) required for this update. The Update
! section contains the edits to be made, and the Reserved section has no defined
! use in this specification.
.Sh "2.1 - Transport Issues"
--- 179,182 ----
invariants (in terms of zone content) required for this update. The Update
! section contains the edits to be made, and the Additional Data section has
! no defined use in this specification.
.Sh "2.1 - Transport Issues"
***************
*** 204,206 ****
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
! | XXCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
--- 211,213 ----
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
! | ADCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
***************
*** 286,287 ****
--- 293,300 ----
T}
+ NOTZONE|10?|T{
+ .nf
+ A name used in the Prerequisite or
+ Update Section is not within the
+ zone denoted by the Zone Section.
+ T}
.TE
***************
*** 293,296 ****
The number of RRs in the Update Section.
! .IP XXCOUNT
! The number of RRs in the Reserved Section.
.RE
--- 306,309 ----
The number of RRs in the Update Section.
! .IP ADCOUNT
! The number of RRs in the Additional Data Section.
.RE
***************
*** 317,319 ****
UPDATE uses this section to denote the zone of the records being updated.
! All records to be updated will be in the same zone, and therefore the Zone
Section is allowed to contain exactly one record. The ZNAME is the zone
--- 330,332 ----
UPDATE uses this section to denote the zone of the records being updated.
! All records to be updated must be in the same zone, and therefore the Zone
Section is allowed to contain exactly one record. The ZNAME is the zone
***************
*** 441,444 ****
and will otherwise be ignored by the primary master. CLASS must be
! specified as NONE to distinguish this from an RR addition.
! .Sh "2.6 - Reserved Section"
.LP
--- 454,458 ----
and will otherwise be ignored by the primary master. CLASS must be
! specified as NONE to distinguish this from an RR addition. If no such RRs
! exist, then this Update RR will be silently ignored by the primary master.
! .Sh "2.6 - Additional Data Section"
.LP
***************
*** 476,478 ****
Next, the Prerequisite Section is checked to see that all prerequisites are
! satisfied by the current state of the zone.
.LP
--- 490,494 ----
Next, the Prerequisite Section is checked to see that all prerequisites are
! satisfied by the current state of the zone. Using the definitions expressed
! in Section 1.2, if any RR's NAME is not within the zone specified in the
! Zone Section, signal NOTZONE to requestor.
.LP
***************
*** 519,520 ****
--- 535,538 ----
return (FORMERR)
+ if (zone_of(rr.name) != ZNAME)
+ return (NOTZONE);
if (rr.class == ANY)
***************
*** 574,578 ****
.Sh "3.4.1 - Prescan"
! The Update Section is parsed into RRs and each RR's CLASS is checked to see
! if it is ANY, NONE, or the same as the Zone Class, else signal a FORMERR to
! the requestor.
.br
--- 592,597 ----
.Sh "3.4.1 - Prescan"
! The Update Section is parsed into RRs and each RR's CLASS is checked to see if
! it is ANY, NONE, or the same as the Zone Class, else signal a FORMERR to the
! requestor. Using the definitions in Section 1.2, each RR's NAME must be in
! the zone specified by the Zone Section, else signal NOTZONE to the requestor.
.br
***************
*** 591,592 ****
--- 610,613 ----
[rr] for rr in updates
+ if (zone_of(rr.name) != ZNAME)
+ return (NOTZONE);
if (rr.class == zclass)
***************
*** 749,756 ****
sections, or placing zeros (0) in the these ``count'' fields and not
! including any part of the original update. The XXCOUNT will be set to zero
! (0) the Reserved Section will be made empty in responses, no matter what was
! present in the request. The QR bit is set to one (1), and the response is
! sent back to the requestor. If the requestor used UDP, then the response
! will be sent to the requestor's source UDP port. If the requestor used TCP,
! then the response will be sent back on the requestor's open TCP connection.
.\"............................................................................
--- 770,778 ----
sections, or placing zeros (0) in the these ``count'' fields and not
! including any part of the original update. The ADCOUNT will be set to zero
! (0) the Additional Data Section will be made empty in responses, no matter
! what was present in the request. The QR bit is set to one (1), and the
! response is sent back to the requestor. If the requestor used UDP, then the
! response will be sent to the requestor's source UDP port. If the requestor
! used TCP, then the response will be sent back on the requestor's open TCP
! connection.
.\"............................................................................
***************
*** 794,796 ****
Update Section:|(see previous text)
! Reserved Section:|(empty)
.TE
--- 816,818 ----
Update Section:|(see previous text)
! Additional Data Section:|(empty)
.TE
***************
*** 862,864 ****
master server, it must allocate a new ID and prepare to enter the role of
! ``forwarding server'', which is a requestor with respect to the forward server.
.LP
--- 884,886 ----
master server, it must allocate a new ID and prepare to enter the role of
! ``forwarding server,'' which is a requestor with respect to the forward server.
.LP
***************
*** 894,896 ****
.bp
! .Sh "7 - Design and Implementation Notes"
.LP
--- 916,918 ----
.bp
! .Sh "7 - Design, Implementation, Operation, and Protocol Notes"
.LP
***************
*** 910,915 ****
.LP
! 7.3. The Reserved Zone might be used if some of the RRs later needed for
! Secure DNS Update are not actually zone updates, but rather ancillary keys or
! signatures not intended to be stored in the zone (as an update would be),
! yet necessary for validating the update operation.
.LP
--- 932,937 ----
.LP
! 7.3. The Additional Data Section might be used if some of the RRs later
! needed for Secure DNS Update are not actually zone updates, but rather
! ancillary keys or signatures not intended to be stored in the zone (as an
! update would be), yet necessary for validating the update operation.
.LP
***************
*** 971,975 ****
.LP
! 7.13. The Reserved Section in requests will be made empty by requestors,
! passed through unchanged by forwarders and ignored by primary master servers.
! The Reserved Section in responses will be made empty by primary master
servers, ignored by forwarders, and ignored by requestors. This is intended
--- 993,997 ----
.LP
! 7.13. The Additional Data Section will be made empty by requestors, passed
! through unchanged by forwarders and ignored by primary master servers. The
! Additional Data Section in responses will be made empty by primary master
servers, ignored by forwarders, and ignored by requestors. This is intended
***************
*** 1004,1005 ****
--- 1026,1057 ----
state.
+ .LP
+ 7.18. In a deep AXFR dependency graph, it has not historically been an error
+ for slaves to depend mutually upon each other. This configuration has been
+ used to enable a zone to flow from the primary master to all slaves even
+ though not all slaves have continuous connectivity to the primary master.
+ UPDATE's use of the AXFR dependency graph for forwarding prohibits this kind
+ of dependency loop, since UPDATE forwarding has no loop detection analagous
+ to the SOA SERIAL pretest used by AXFR.
+ .LP
+ 7.19. For UPDATE's purposes, a zone is said to own all names at or below the
+ zone's root. This allows an UPDATE message to add or delete names below a
+ zone cut so as to create and maintain ``glue'' records needed for delegation
+ when a name server is within the zone being delegated.
+ .LP
+ 7.20. Previously existing names which are occluded by a new zone cut are still
+ considered part of the parent zone, for the purposes of zone transfers, even
+ though queries for such names will be referred to the new subzone's servers.
+ If a zone cut is removed, all parent zone names that were occluded by it will
+ again become visible to queries. (This is a clarification of RFC 1034.)
+ .LP
+ 7.21. If a node contains any name server delegations (NS RRs), this node is
+ said to be owned by the child zone, and the parent will answer only with a
+ nonauthoritative referral to the child zone's servers if queried for a name
+ at or below the child zone's root, except in the case of an QTYPE=NS query
+ at the zone cut itself, for which the parent zone's servers would answer
+ authoritatively. (This is a clarification of RFC 1034.)
+ .LP
+ 7.22. If a server is authoritative for both a zone and its child, then queries
+ for names at the zone cut between them will be answered authoritatively using
+ only data from the child zone. (This is a clarification of RFC 1034.)
.\"............................................................................
=========================================================================
Date: Thu, 7 Mar 1996 18:49:26 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: dynDNS-08
X-To: internet-drafts@cnri.reston.va.us, namedroppers@internic.net
DNSIND Working Group Paul Vixie (Ed.) (ISC)
INTERNET-DRAFT Susan Thomson (Bellcore)
<draft-ietf-dnsind-dynDNS-08.txt> Yakov Rekhter (Cisco)
Jim Bound (DEC)
March 1996
Dynamic Updates in the Domain Name System (DNS UPDATE)
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The Domain Name System was originally designed to support queries of
a statically configured database. While the data was expected to
change, the frequency of those changes was expected to be fairly low,
and all updates were made as external edits to a zone's Master File.
Using this specification of the UPDATE opcode, it is possible to add
or delete RRs or RRsets from a specified zone. Prerequisites are
specified separately from update operations, and can specify a
dependency upon either the previous existence or nonexistence of an
RRset, or the existence of a single RR.
UPDATE is atomic, i.e., all prerequisites must be satisfied or else
no update operations will take place. There are no data dependent
error conditions defined after the prerequisites have been met.
Expires October 1996 [Page 1]
INTERNET-DRAFT DNS UPDATE March 1996
1 - Definitions
This document intentionally gives more definition to the roles of
``Master,'' ``Slave,'' and ``Primary Master'' servers, and their
enumeration in NS RRs, and the SOA MNAME field. In that sense, the
following server type definitions can be considered an addendum to
[RFC1035], and are intended to be consistent with [NOTIFY]:
Slave an authoritative server that uses AXFR or IXFR to
retrieve the zone and is named in the zone's NS
RRset.
Master an authoritative server configured to be the source
of AXFR or IXFR data for one or more slave servers.
Primary Master master server at the root of the AXFR/IXFR dependency
graph. The primary master is named in the zone's SOA
MNAME field and optionally by an NS RR. There is by
definition only one primary master server per zone.
A domain name identifies a node within the domain name space tree
structure. Each node has a set (possibly empty) of Resource Records
(RRs). All RRs having the same NAME, CLASS and TYPE are called a
Resource Record Set (RRset).
The pseudocode used in this document is for example purposes only. If
it is found to disagree with the text, the text shall be considered
authoritative. If the text is found to be ambiguous, the pseudocode can
be used to help resolve the ambiguity.
1.1 - Comparison Rules
1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE, RDLENGTH
and RDATA fields are equal. Note that the time-to-live (TTL) field is
explicitly excluded from the comparison.
1.1.2. The rules for comparison of character strings in names are
specified in [RFC1035 2.3.3].
1.1.3. Wildcarding is disabled. That is, a wildcard (``*'') in an
update only matches a wildcard (``*'') in the zone, and vice versa.
1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in the
update, and will not otherwise be followed. All UPDATE operations are
done on the basis of canonical names.
Expires October 1996 [Page 2]
INTERNET-DRAFT DNS UPDATE March 1996
1.1.5. The following RR types cannot be appended to an RRset. If the
following comparison rules are met, then an attempt to add the new RR
will result in the replacement of the previous RR:
SOA compare only NAME, CLASS and TYPE -- it is not possible to
have more than one SOA per zone, even if any of the data
fields differ.
WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL -- only
one WKS RR is possible for this tuple, even if the services
masks differ.
CNAME compare only NAME, CLASS, and TYPE -- it is not possible to
have more than one CNAME RR, even if their data fields differ.
1.2 - Glue RRs
For the purpose of determining whether a domain name used in the UPDATE
protocol is contained within a specified zone, a domain name is ``in'' a
zone if it is owned by that zone's domain name. See section 7.19 for
details.
1.3 - New Assigned Numbers
CLASS = NONE (TBD: 254?)
RCODE = YXDOMAIN (TBD: 6?)
RCODE = YXRRSET (TBD: 7?)
RCODE = NXRRSET (TBD: 8?)
RCODE = NOTAUTH (TBD: 9?)
RCODE = NOTZONE (TBD: 10?)
Opcode = UPDATE (5)
2 - Update Message Format
The DNS Message Format is defined by [RFC1035 4.1]. Some extensions are
necessary (for example, more error codes are possible under UPDATE than
under QUERY) and some fields must be overloaded (see description of
CLASS fields below).
The overall format of an UPDATE message is, following [ibid]:
Expires October 1996 [Page 3]
INTERNET-DRAFT DNS UPDATE March 1996
+---------------------+
| Header |
+---------------------+
| Zone | specifies the zone to be updated
+---------------------+
| Prerequisite | RRs or RRsets which must (not) preexist
+---------------------+
| Update | RRs or RRsets to be added or deleted
+---------------------+
| Additional Data | additional data
+---------------------+
The Header section specifies that this message is an UPDATE, and
describes the size of the other sections. The Zone section names the
zone that is to be updated by this message. The Prerequisite section
specifies the starting invariants (in terms of zone content) required
for this update. The Update section contains the edits to be made, and
the Additional Data section has no defined use in this specification.
2.1 - Transport Issues
An update transaction may be carried in a UDP datagram, if the request
fits, or in a TCP connection (at the discretion of the requestor). When
TCP is used, the message is in the format described in [RFC1035 4.2.2].
2.2 - Message Header
The header of the DNS Message Format is defined by [RFC 1035 4.1]. Not
all opcodes define the same set of flag bits, though as a practical
matter most of the bits defined for QUERY (in [ibid]) are identically
defined by the other opcodes. UPDATE uses only one flag bit (QR).
The DNS Message Format specifies record counts for its four sections
(Question, Answer, Authority, and Additional). UPDATE uses the same
fields, and the same section formats, but the naming and use of these
sections differs as shown in the following modified header, after
[RFC1035 4.1.1]:
Expires October 1996 [Page 4]
INTERNET-DRAFT DNS UPDATE March 1996
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode | Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
These fields are used as follows:
ID A 16-bit identifier assigned by the entity that generates any
kind of request. This identifier is copied in the
corresponding reply and can be used by the requestor to match
replies to outstanding requests, or by the server to detect
duplicated requests from some requestor.
QR A one bit field that specifies whether this message is a
request (0), or a response (1).
Opcode A four bit field that specifies the kind of request in this
message. This value is set by the originator of a request
and copied into the response. The Opcode value that
identifies an UPDATE message is five (5).
Z Reserved for future use. Should be zero (0) in all requests
and responses. A non-zero Z field should be ignored by
implementations of this specification.
Expires October 1996 [Page 5]
INTERNET-DRAFT DNS UPDATE March 1996
RCODE Response code - this four bit field is undefined in requests
and set in responses. The values and meanings of this field
within responses are as follows:
Mneumonic Value Description
------------------------------------------------------------
NOERROR 0 No error condition.
FORMERR 1 The name server was unable to interpret
the request due to a format error.
SERVFAIL 2 The name server encountered an internal
failure while processing this request,
for example an operating system error
or a forwarding timeout.
NXDOMAIN 3 Some name that ought to exist,
does not exist.
NOTIMP 4 The name server does not support
the specified Opcode.
REFUSED 5 The name server refuses to perform the
specified operation for policy or
security reasons.
YXDOMAIN 6? Some name that ought not to exist,
does exist.
YXRRSET 7? Some RRset that ought not to exist,
does exist.
NXRRSET 8? Some RRset that ought to exist,
does not exist.
NOTAUTH 9? The server is not authoritative for
the zone named in the Zone Section.
NOTZONE 10? A name used in the Prerequisite or
Update Section is not within the
zone denoted by the Zone Section.
ZOCOUNT The number of RRs in the Zone Section.
PRCOUNT The number of RRs in the Prerequisite Section.
UPCOUNT The number of RRs in the Update Section.
ADCOUNT The number of RRs in the Additional Data Section.
Expires October 1996 [Page 6]
INTERNET-DRAFT DNS UPDATE March 1996
2.3 - Zone Section
The Zone Section has the same format as that specified in [RFC1035
4.1.2], with the fields redefined as follows:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ ZNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
UPDATE uses this section to denote the zone of the records being
updated. All records to be updated must be in the same zone, and
therefore the Zone Section is allowed to contain exactly one record.
The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is the
zone's class.
2.4 - Prerequisite Section
This section contains a set of RRset prerequisites which must be
satisfied at the time the UPDATE packet is received by the primary
master server. There are five possible sets of semantics that can be
expressed here, summarized as follows and then explained below.
(1) RRset exists (value independent). At least one RR with a
specified NAME and TYPE (in the zone and class specified by the
Zone Section) must exist.
(2) RRset exists (value dependent). A set of RRs with a specified
NAME and TYPE exists and has the same members with the same
RDATA sections as the RRset specified here in this Section.
(3) RRset does not exist. No RRs with a specified NAME and TYPE (in
the zone and class denoted by the Zone Section) can exist.
(4) Name is in use. At least one RR with a specified NAME (in the
zone and class specified by the Zone Section) must exist. Note
that this prerequisite is NOT satisfied by empty nonterminals.
Expires October 1996 [Page 7]
INTERNET-DRAFT DNS UPDATE March 1996
(5) Name is not in use. No RR of any type is owned by a specified
NAME. Note that this prerequisite IS satisfied by empty
nonterminals.
The syntax of these is as follows:
2.4.1 - RRset Exists (Value Independent)
At least one RR with a specified NAME and TYPE (in the zone and class
specified in the Zone Section) must exist.
For this prerequisite, a requestor adds to the section a single RR whose
NAME and TYPE are equal to that of the zone RRset whose existence is
required. The RDLENGTH is zero and the RDATA section is therefore
empty. CLASS must be specified as ANY to differentiate this condition
from that of an actual RR whose RDLENGTH is naturally zero (0) (e.g.,
NULL). TTL is specified as zero (0).
2.4.2 - RRset Exists (Value Dependent)
A set of RRs with a specified NAME and TYPE exists and has the same
members with the same RDATA sections as the RRset specified here in this
section. While RRset ordering is undefined and therefore not
significant to this comparison, the sets be identical in their extent.
For this prerequisite, a requestor adds to the section an entire RRset
whose preexistence is required. NAME and TYPE are that of the RRset
being denoted. CLASS is that of the zone. TTL must be specified as
zero (0) and is ignored when comparing RRsets for identity.
2.4.3 - RRset Does Not Exist
No RRs with a specified NAME and TYPE (in the zone and class denoted by
the Zone Section) can exist.
For this prerequisite, a requestor adds to the section a single RR whose
NAME and TYPE are equal to that of the RRset whose nonexistence is
required. The RDLENGTH of this record is zero (0), and RDATA field is
therefore empty. CLASS must be specified as NONE in order to
distinguish this condition from a valid RR whose RDLENGTH is naturally
zero (0) (for example, the NULL RR). TTL must be specified as zero (0).
Expires October 1996 [Page 8]
INTERNET-DRAFT DNS UPDATE March 1996
2.4.4 - Name Is In Use
Name is in use. At least one RR with a specified NAME (in the zone and
class specified by the Zone Section) must exist. Note that this
prerequisite is NOT satisfied by empty nonterminals.
For this prerequisite, a requestor adds to the section a single RR whose
NAME is equal to that of the name whose ownership of an RR is required.
The RDLENGTH is zero and the RDATA section is therefore empty. CLASS
must be specified as ANY to differentiate this condition from that of an
actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TYPE must
be specified as ANY to differentiate this case from that of an RRset
existence test. TTL is specified as zero (0).
2.4.5 - Name Is Not In Use
Name is not in use. No RR of any type is owned by a specified NAME.
Note that this prerequisite IS satisfied by empty nonterminals.
For this prerequisite, a requestor adds to the section a single RR whose
NAME is equal to that of the name whose nonownership of any RRs is
required. The RDLENGTH is zero and the RDATA section is therefore
empty. CLASS must be specified as NONE. TYPE must be specified as ANY.
TTL must be specified as zero (0).
2.5 - Update Section
This section contains RRs to be added to or deleted from the zone. The
encoding is similar to that used by the Prerequisite Section. There are
four possible sets of semantics, summarized below and with details to
follow.
(1) Add RRs to an RRset.
(2) Delete an RRset.
(3) Delete all RRsets from a name.
(4) Delete an RR from an RRset.
The syntax of these is as follows:
2.5.1 - Add To An RRset
RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH and
RDATA are those being added, and CLASS is the same as the zone class.
Any duplicate RRs will be silently ignored by the primary master.
Expires October 1996 [Page 9]
INTERNET-DRAFT DNS UPDATE March 1996
2.5.2 - Delete An RRset
One RR is added to the Update Section whose NAME and TYPE are those of
the RRset to be deleted. TTL must be specified as zero (0) and is
otherwise not used by the primary master. CLASS must be specified as
ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty. If
no such RRset exists, then this Update RR will be silently ignored by
the primary master.
2.5.3 - Delete All RRsets From A Name
One RR is added to the Update Section whose NAME is that of the name to
be cleansed of RRsets. TYPE must be specified as ANY. TTL must be
specified as zero (0) and is otherwise not used by the primary master.
CLASS must be specified as ANY. RDLENGTH must be zero (0) and RDATA
must therefore be empty. If no such RRsets exist, then this Update RR
will be silently ignored by the primary master.
2.5.4 - Delete An RR From An RRset
RRs to be deleted are added to the Update Section. The NAME, TYPE,
RDLENGTH and RDATA must match the RR being deleted. TTL must be
specified as zero (0) and will otherwise be ignored by the primary
master. CLASS must be specified as NONE to distinguish this from an RR
addition. If no such RRs exist, then this Update RR will be silently
ignored by the primary master.
2.6 - Additional Data Section
This section is reserved for use by future extensions to this protocol.
It will be ignored by servers, and made empty by requestors which
implement only the protocol described by this document.
Expires October 1996 [Page 10]
INTERNET-DRAFT DNS UPDATE March 1996
3 - Server Behavior
A server, upon receiving an UPDATE request, will signal NOTIMP to the
requestor if the UPDATE opcode is not recognized or if it is recognized
but has not been implemented. Otherwise, processing continues as
follows.
3.1 - Process Zone Section
3.1.1. The Zone Section is checked to see that there is exactly one RR
therein and that the RR's ZTYPE is SOA, else signal FORMERR to
requestor. Next, the ZNAME and ZCLASS are checked to see if the zone so
named is one of this server's authority zones, else signal NOTAUTH to
requestor. If the server is a zone slave, the request will be forwarded
toward the primary master.
3.1.2 - Pseudocode For Zone Section Processing
if (zcount != 1 || ztype != SOA)
return (FORMERR)
if (zone_type(zname, zclass) == SLAVE)
return forward()
if (zone_type(zname, zclass) == MASTER)
return update()
return (NOTAUTH)
Sections 3.2 through 3.8 describe the primary master's behaviour,
whereas Section 6 describes a forwarder's behaviour.
3.2 - Process Prerequisite Section
Next, the Prerequisite Section is checked to see that all prerequisites
are satisfied by the current state of the zone. Using the definitions
expressed in Section 1.2, if any RR's NAME is not within the zone
specified in the Zone Section, signal NOTZONE to requestor.
3.2.1. For RRs in this section whose CLASS is ANY, test to see that TTL
and RDLENGTH are both zero (0) else signal FORMERR to requestor. If
TYPE is ANY, test to see that there is at least one RR in the zone whose
NAME is the same as that of the Prerequisite RR, else signal NXDOMAIN to
the requestor. If TYPE is not ANY, test to see that there is at least
one RR in the zone whose NAME and TYPE are the same as that of the
Prerequisite RR, else signal NXRRSET to requestor.
Expires October 1996 [Page 11]
INTERNET-DRAFT DNS UPDATE March 1996
3.2.2. For RRs in this section whose CLASS is NONE, test to see that the
TTL and RDLENGTH are both zero (0) else signal FORMERR to requestor. If
the TYPE is ANY, test to see that there are no RRs in the zone whose
NAME is the same as that of the Prerequisite RR, else signal YXDOMAIN to
requestor. If the TYPE is not ANY, test to see that there are no RRs in
the zone whose NAME and TYPE are the same as that of the Prerequisite
RR, else signal YXRRSET to requestor.
3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
test to see that the TTL is zero (0) else signal FORMERR to requestor.
Then, build an RRset for each unique <NAME,TYPE> and compare each
resulting RRset for set equality (same members, no more, no less) with
RRsets in the zone. If any Prerequisite RRset is not entirely and
exactly matched by a zone RRset, signal NXRRSET to requestor. If any RR
in this section has a CLASS other than ZCLASS or NONE or ANY, signal
FORMERR to requestor.
3.2.4 - Table Of Metavalues Used In Prerequisite Section
CLASS TYPE RDATA Meaning
------------------------------------------------------------
ANY ANY empty Name is in use
ANY rrset empty RRset exists (value independent)
NONE ANY empty Name is not in use
NONE rrset empty RRset does not exist
zone rrset rr RRset exists (value dependent)
Expires October 1996 [Page 12]
INTERNET-DRAFT DNS UPDATE March 1996
3.2.5 - Pseudocode for Prerequisite Section Processing
for rr in prerequisites
if (rr.ttl != 0)
return (FORMERR)
if (zone_of(rr.name) != ZNAME)
return (NOTZONE);
if (rr.class == ANY)
if (rr.rdlength != 0)
return (FORMERR)
if (rr.type == ANY)
if (!zone_name<rr.name>)
return (NXDOMAIN)
else
if (!zone_rrset<rr.name, rr.type>)
return (NXRRSET)
if (rr.class == NONE)
if (rr.rdlength != 0)
return (FORMERR)
if (rr.type == ANY)
if (zone_name<rr.name>)
return (YXDOMAIN)
else
if (zone_rrset<rr.name, rr.type>)
return (YXRRSET)
if (rr.class == zclass)
temp<rr.name, rr.type> += rr
else
return (FORMERR)
for rrset in temp
if (zone_rrset<rrset.name, rrset.type> != rrset)
return (NXDOMAIN)
3.3 - Check Requestor's Permissions
3.3.1. Next, the requestor's permission to update the RRs named in the
Update Section may be tested in an implementation dependent fashion or
using mechanisms specified in a subsequent Secure DNS Update protocol.
If the requestor does not have permission to perform these updates, the
server may write a warning message in its operations log, and may either
signal REFUSED to requestor, or ignore the permission problem and
proceed with the update.
Expires October 1996 [Page 13]
INTERNET-DRAFT DNS UPDATE March 1996
3.3.2. While the exact processing is implementation defined, if these
verification activities are to be performed, this is the point in the
server's processing where such performance should take place, since if a
REFUSED condition is encountered after an update has been partially
applied, it will be necessary to undo the partial update and restore the
zone to its original state before answering the requestor.
3.3.3 - Pseudocode for Permission Checking
if (security policy exists)
if (this update is not permitted)
if (local option)
log a message about permission problem
if (local option)
return (REFUSED)
3.4 - Process Update Section
Next, the Update Section is processed as follows.
3.4.1 - Prescan The Update Section is parsed into RRs and each RR's
CLASS is checked to see if it is ANY, NONE, or the same as the Zone
Class, else signal a FORMERR to the requestor. Using the definitions in
Section 1.2, each RR's NAME must be in the zone specified by the Zone
Section, else signal NOTZONE to the requestor.
3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
unrecognized type, then signal FORMERR to the requestor. For RRs whose
CLASS is ANY or NONE, check the TTL to see that it is zero (0), else
signal a FORMERR to the requestor. For any RR whose CLASS is ANY, check
the RDLENGTH to make sure that it is zero (0) (that is, the RDATA field
is empty), and that the TYPE is not AXFR, MAILA, MAILB, or any other
QUERY metatype besides ANY, or any unrecognized type, else signal
FORMERR to the requestor.
Expires October 1996 [Page 14]
INTERNET-DRAFT DNS UPDATE March 1996
3.4.1.3 - Pseudocode For Update Section Prescan
[rr] for rr in updates
if (zone_of(rr.name) != ZNAME)
return (NOTZONE);
if (rr.class == zclass)
if (rr.type & ANY|AXFR|MAILA|MAILB)
return (FORMERR)
elsif (rr.class == ANY)
if (rr.ttl != 0 || rr.rdlength != 0
|| rr.type & AXFR|MAILA|MAILB)
return (FORMERR)
elsif (rr.class == NONE)
if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
return (FORMERR)
else
return (FORMERR)
3.4.2 - Update The Update Section is parsed into RRs and these RRs are
processed in order.
3.4.2.1. If any system failure (such as an out of memory condition, or a
hardware error in persistent storage) occurs during the processing of
this section, signal SERVFAIL to the requestor and undo all updates
applied to the zone during this transaction.
3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to the
zone. In case of duplicate RDATAs (which for SOA RRs is always the
case, and for WKS RRs is the case if the ADDRESS and PROTOCOL fields
both match), the Zone RR is replaced by Update RR. If the TYPE is SOA
and there is no Zone SOA RR, or the new SOA.SERIAL is lower (according
to [KRE1996]) than the current Zone SOA RR's SOA.SERIAL, the Update RR
is ignored. In the case of a CNAME Update RR and a non-CNAME Zone RRset
or vice versa, ignore the CNAME Update RR, otherwise replace the CNAME
Zone RR with the CNAME Update RR.
Expires October 1996 [Page 15]
INTERNET-DRAFT DNS UPDATE March 1996
3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY, all
Zone RRs with the same NAME are deleted, unless the NAME is the same as
ZNAME in which case only those RRs whose TYPE is other than SOA or NS
are deleted. For any Update RR whose CLASS is ANY and whose TYPE is not
ANY all Zone RRs with the same NAME and TYPE are deleted, unless the
NAME is the same as ZNAME in which case neither SOA or NS RRs will be
deleted.
3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose NAME,
TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted, unless
the NAME is the same as ZNAME and either the TYPE is SOA or the TYPE is
NS and the matching Zone RR is the only NS remaining in the RRset, in
which case this Update RR is ignored.
3.4.2.5. Signal NOERROR to the requestor.
3.4.2.6 - Table Of Metavalues Used In Update Section
CLASS TYPE RDATA Meaning
---------------------------------------------------------
ANY ANY empty Delete all RRsets from a name
ANY rrset empty Delete an RRset
NONE rrset rr Delete an RR from an RRset
zone rrset rr Add to an RRset
Expires October 1996 [Page 16]
INTERNET-DRAFT DNS UPDATE March 1996
3.4.2.7 - Pseudocode For Update Section Processing
[rr] for rr in updates
if (rr.class == zclass)
if (rr.type == CNAME)
if (zone_rrset<rr.name, ~CNAME>)
next [rr]
elsif (zone_rrset<rr.name, CNAME>)
next [rr]
if (rr.type == SOA)
if (!zone_rrset<rr.name, SOA> ||
zone_rr<rr.name, SOA>.serial > rr.soa.serial)
next [rr]
for zrr in zone_rrset<rr.name, rr.type>
if (rr.type == CNAME || rr.type == SOA ||
(rr.type == WKS && rr.proto == zrr.proto &&
rr.address == zrr.address) ||
rr.rdata == zrr.rdata)
zrr = rr
next [rr]
zone_rrset<rr.name, rr.type> += rr
elsif (rr.class == ANY)
if (rr.type == ANY)
if (rr.name == zname)
zone_rrset<rr.name, ~(SOA|NS)> = Nil
else
zone_rrset<rr.name, *> = Nil
elsif (rr.name == zname &&
(rr.type == SOA || rr.type == NS))
next [rr]
else
zone_rrset<rr.name, rr.type> = Nil
elsif (rr.class == NONE)
if (rr.type == SOA)
next [rr]
if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
next [rr]
zone_rr<rr.name, rr.type, rr.data> = Nil
return (NOERROR)
Expires October 1996 [Page 17]
INTERNET-DRAFT DNS UPDATE March 1996
3.5 - Stability
When a zone is modified by an UPDATE operation, the server must commit
the change to nonvolatile storage before sending a response to the
requestor or answering any queries or transfers for the modified zone.
It is reasonable for a server to store only the update records as long
as a system reboot or power failure will cause these update records to
be incorporated into the zone the next time the server is started. It
is also reasonable for the server to copy the entire modified zone to
nonvolatile storage after each update operation, though this would have
suboptimal performance for large zones.
3.6 - Zone Identity
If the zone's SOA SERIAL is changed by an update operation, that change
must be in a positive direction (using modulo 2**32 arithmetic as
specified by [KRE1996]). Attempts to replace an SOA with one whose
SERIAL is less than the current one will be silently ignored by the
primary master server.
If the zone's SOA's SERIAL is not changed as a result of an update
operation, then the server shall increment it automatically before the
SOA or any changed name or RR or RRset is included in any response or
transfer. The primary master server's implementor might choose to
autoincrement the SOA SERIAL if any of the following events occurs:
(1) Each update operation.
(2) A name, RR or RRset in the zone has changed and has subsequently
been visible to a DNS client since the unincremented SOA was
visible to a DNS client, and the SOA is about to become visible to
a DNS client.
(3) A configurable period of time has elapsed since the last update
operation. This period shall be less than or equal to one third of
the zone refresh time, and the default shall be the lesser of that
maximum and 300 seconds.
(4) A configurable number of updates has been applied since the last
SOA change. The default value for this configuration parameter
shall be one hundred (100).
It is imperative that the zone's contents and the SOA's SERIAL be
tightly synchronized. If the zone appears to change, the SOA must
appear to change as well.
Expires October 1996 [Page 18]
INTERNET-DRAFT DNS UPDATE March 1996
3.7 - Atomicity
During the processing of an UPDATE transaction, the server must ensure
atomicity with respect to other (concurrent) UPDATE or QUERY
transactions. No two transactions can be processed concurrently if
either depends on the final results of the other; in particular, a QUERY
should not be able to retrieve RRsets which have been partially modified
by a concurrent UPDATE, and an UPDATE should not be able to start from
prerequisites that might not still hold at the completion of some other
concurrent UPDATE. Finally, if two UPDATE transactions would modify the
same names, RRs or RRsets, then such UPDATE transactions must be
serialized.
3.8 - Response
At the end of UPDATE processing, a response code will be known. A
response message is generated by copying the ID and Opcode fields from
the request, and either copying the ZOCOUNT, PRCOUNT, and UPCOUNT fields
and associated sections, or placing zeros (0) in the these ``count''
fields and not including any part of the original update. The ADCOUNT
will be set to zero (0) the Additional Data Section will be made empty
in responses, no matter what was present in the request. The QR bit is
set to one (1), and the response is sent back to the requestor. If the
requestor used UDP, then the response will be sent to the requestor's
source UDP port. If the requestor used TCP, then the response will be
sent back on the requestor's open TCP connection.
4 - Requestor Behaviour
4.1. From a requestor's point of view, any authoritative server for the
zone can appear to be able to process update requests, even though only
the primary master server is actually able to modify the zone's master
file. Requestors are expected to know the name of the zone they intend
to update and to know or be able to determine the name servers for that
zone.
4.2. If update ordering is desired, the requestor will need to know the
value of the existing SOA RR. Requestors who update the SOA RR must
update the SOA SERIAL field in a positive direction (as defined by
[KRE1996]) and to preserve the other SOA fields unless the requestor's
explicit intent is to change them. The SOA SERIAL field must never be
set to zero (0).
Expires October 1996 [Page 19]
INTERNET-DRAFT DNS UPDATE March 1996
4.3. If the requestor has reasonable cause to believe that all of a
zone's servers will be equally reachable, then it should arrange to try
the primary master server (as given by the SOA MNAME field if matched by
some NS NSDNAME) first to avoid unnecessary forwarding inside the slave
servers. (Note that the primary master will in some cases not be
reachable by all requestors, due to firewalls or network partitioning.)
4.4. Once the zone's name servers been found and possibly sorted so that
the ones more likely to be reachable and/or support the UPDATE opcode
are listed first, the requestor composes an UPDATE message of the
following form and sends it to the first name server on its list:
ID: (new)
Opcode: UPDATE
Zone zcount: 1
Zone zname: (zone name)
Zone zclass: (zone class)
Zone ztype: T_SOA
Prerequisite Section: (see previous text)
Update Section: (see previous text)
Additional Data Section: (empty)
4.5. If the requestor receives a response, and the response has an RCODE
other than SERVFAIL or NOTIMP, then the requestor returns an appropriate
response to its caller.
4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or if
no response is received within an implementation dependent timeout
period, or if an ICMP error is received indicating that the server's
port is unreachable, then the requestor will delete the unusable server
from its internal name server list and try the next one, repeating until
the name server list is empty. If the requestor runs out of servers to
try, an appropriate error will be returned to the requestor's caller.
5 - Duplicate Detection, Ordering and Mutual Exclusion
5.1. For correct operation, mechanisms may be needed to ensure
idempotence, order UPDATE requests and provide mutual exclusion. This
is due to DNS's use of UDP, a datagram protocol which does not ensure
reliable delivery. An UPDATE message or response might be delivered
zero times, one time, or multiple times. Datagram duplication is of
particular interest since it covers the case of the so-called ``replay
attack'' where a correct request is duplicated maliciously by an
intruder.
Expires October 1996 [Page 20]
INTERNET-DRAFT DNS UPDATE March 1996
5.2. Multiple UPDATE requests or responses in transit might be delivered
in any order, due to network topology changes or load balancing, or to
multipath forwarding graphs wherein several slave servers all forward to
the primary master. In some cases, it might be required that the
earlier update not be applied after the later update, where ``earlier''
and ``later'' are defined by an external time base visible to some set
of requestors, rather than by the order of request receipt at the
primary master.
5.3. A requestor can ensure transaction idempotence by explicitly
deleting some ``marker RR'' (rather than deleting the RRset of which it
is a part) and then adding a new ``marker RR'' with a different RDATA
field. The Prerequisite Section should specify that the original
``marker RR'' must be present in order for this UPDATE message to be
accepted by the server.
5.4. If the request is duplicated by a network error, all duplicate
requests will fail since only the first will find the original ``marker
RR'' present and having its known previous value. The decisions of
whether to use such a ``marker RR'' and what RR to use are left up to
the application programmer, though one obvious choice is the zone's SOA
RR as described below.
5.5. Requestors can ensure update ordering by externally synchronizing
their use of successive values of the ``marker RR.'' Mutual exclusion
can be addressed as a degenerate case, in that a single succession of
the ``marker RR'' is all that is needed.
5.6. A special case where update ordering and datagram duplication
intersect is when an RR validly changes to some new value and then back
to its previous value. Without a ``marker RR'' as described above, this
sequence of updates can leave the zone in an undefined state if
datagrams are duplicated.
5.7. To achieve an atomic multitransaction ``read-modify-write'' cycle,
a requestor could first retrieve the SOA RR, and build an UPDATE message
one of whose prerequisites was the old SOA RR. It would then specify
updates that would delete this SOA RR and add a new one with an
incremented SOA SERIAL, along with whatever actual prerequisites and
updates were the object of the transaction. If the transaction
succeeds, the requestor knows that the RRs being changed were not
otherwise altered by any other requestor.
Expires October 1996 [Page 21]
INTERNET-DRAFT DNS UPDATE March 1996
6 - Forwarding
When a zone slave forwards an UPDATE message upward toward the zone's
primary master server, it must allocate a new ID and prepare to enter
the role of ``forwarding server,'' which is a requestor with respect to
the forward server.
6.1. The set of forward servers will be same as the set of servers this
zone slave would use as the source of AXFR or IXFR data. So, while the
original requestor might have used the zone's NS RRset to locate its
update server, a forwarder always forwards toward its designated zone
master servers.
6.2. If the original requestor used TCP, then the TCP connection from
the requestor is still open and the forwarder must use TCP to forward
the message. If the original requestor used UDP, the forwarder may use
either UDP or TCP to forward the message, depending on the
implementation.
6.3. It is reasonable for forward servers to be forwarders themselves,
if the AXFR dependency graph being followed is a deep one involving
firewalls and multiple connectivity realms. In most cases the AXFR
dependency graph will be shallow and the forward server will be the
primary master server.
6.4. The forwarder will not respond to its requestor until it receives a
response from its forward server. UPDATE transactions involving
forwarders are therefore time synchronized with respect to the original
requestor and the primary master server.
6.5. When there are multiple possible sources of AXFR data and therefore
multiple possible forward servers, a forwarder will use the same
fallback strategy with respect to connectivity or timeout errors that it
would use when performing an AXFR. This is implementation dependent.
6.6. When a forwarder receives a response from a forward server, it
copies this response into a new response message, assigns its
requestor's ID to that message, and sends the response back to the
requestor.
Expires October 1996 [Page 22]
INTERNET-DRAFT DNS UPDATE March 1996
7 - Design, Implementation, Operation, and Protocol Notes
Some of the principles which guided the design of this UPDATE
specification are as follows. Note that these are not part of the
formal specification and any disagreement between this section and any
other section of this document should be resolved in favour of the other
section.
7.1. Using metavalues for CLASS is possible only because all RRs in the
packet are assumed to be in the same zone, and CLASS is an attribute of
a zone rather than of an RRset. (It is for this reason that the Zone
Section is not optional.)
7.2. Since there are no data-present or data-absent errors possible from
processing the Update Section, it is necessary to state data-present and
data-absent dependencies in the Prerequisite Section.
7.3. The Additional Data Section might be used if some of the RRs later
needed for Secure DNS Update are not actually zone updates, but rather
ancillary keys or signatures not intended to be stored in the zone (as
an update would be), yet necessary for validating the update operation.
7.4. It is expected that in the absence of Secure DNS Update, a server
will only accept updates if they come from a source address that has
been statically configured in the server's description of a primary
master zone. DHCP servers would be likely candidates for inclusion in
this statically configured list.
7.5. It is not possible to create a zone using this protocol, since
there is no provision for a slave server to be told who its master
servers are. It is expected that this protocol will be extended in the
future to cover this case. Therefore, at this time, the addition of SOA
RRs is unsupported. For similar reasons, deletion of SOA RRs is also
unsupported.
7.6. The prerequisite for specifying that a name own at least one RR
differs semantically from QUERY, in that QUERY would return
<NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at this
name, while UPDATE's prerequisite condition [Section 2.4.4] would NOT be
satisfied.
7.7. It is possible for a UDP response to be lost in transit and for a
request to be retried due to a timeout condition. In this case an
UPDATE that was successful the first time it was received by the primary
master might ultimately appear to have failed when the response to a
Expires October 1996 [Page 23]
INTERNET-DRAFT DNS UPDATE March 1996
duplicate request is finally received by the requestor. (This is
because the original prerequisites may no longer be satisfied after the
update has been applied.) For this reason, requestors who require an
accurate response code must use TCP.
7.8. Because a requestor who requires an accurate response code will
initiate their UPDATE transaction using TCP, a forwarder who receives a
request via TCP must forward it using TCP.
7.9. Deferral of SOA SERIAL autoincrements is made possible so that
serial numbers can be conserved and wraparound at 2**32 can be made an
infrequent occurance. Visible (to DNS clients) SOA SERIALs need to
differ if the zone differs. Note that the Authority Section SOA in a
QUERY response is a form of visibility, for the purposes of this
prerequisite.
7.10. A zone's SOA SERIAL should never be set to zero (0) due to
interoperability problems with some older but widely installed
implementations of DNS. When incrementing an SOA SERIAL, if the result
of the increment is zero (0) (as will be true when wrapping around
2**32), it is necessary to increment it again or set it to one (1). See
[KRE1996] for more detail on this subject.
7.11. Due to the TTL minimalization necessary when caching an RRset, it
is recommended that all TTLs in an RRset be set to the same value.
While the DNS Message Format permits variant TTLs to exist in the same
RRset, and this variance can exist inside a zone, such variance will
have counterintuitive results and its use is discouraged.
7.12. Zone cut management presents some obscure corner cases to the add
and delete operations in the Update Section. It is possible to delete
an NS RR as long as it's not the last RR in the RRset. If deleting all
RRs from a name, SOA and NS RRs at the top of a zone are unaffected. If
deleting RRsets, it is not possible to delete either SOA or NS RRsets at
the top of a zone. An attempt to add an SOA will be treated as a
replace operation.
7.13. The Additional Data Section will be made empty by requestors,
passed through unchanged by forwarders and ignored by primary master
servers. The Additional Data Section in responses will be made empty by
primary master servers, ignored by forwarders, and ignored by
requestors. This is intended to make it possible for future requestor
specifications to use this section as a way to determine that a response
was generated according to a future primary master server specification.
Expires October 1996 [Page 24]
INTERNET-DRAFT DNS UPDATE March 1996
7.14. No semantic checking is required in the primary master server when
adding new RRs. Therefore a requestor can cause CNAME or NS or any
other kind of RR to be added even if their target name does not exist or
does not have the proper RRsets to make the original RR useful. Primary
master servers which implement this kind of checking should take great
care to avoid out-of-zone dependencies (whose veracity cannot be
authoritatively checked) or signals to the requestor during processing
of the Update Section after the prescan.
7.15. Nonterminal or wildcard CNAMEs are not well specified by RFC 1035
and their use will probably lead to unpredictable results. Their use is
discouraged.
7.16. Before adding a delegation to a zone, all RRsets at or below the
new zone cut should be removed, except for ``glue'' which are A RRs
below the zone cut which are targets of NS RRs at the zone cut.
7.17. A primary server implementation may choose to perform part of its
permission checking during the Update Section processing. This may be
needed if the permissions won't be known until the final form of an
RRset is known. In this case, a primary server can signal REFUSED to
the requestor as long as it also undoes all partial updates and restores
the zone to its original state.
7.18. In a deep AXFR dependency graph, it has not historically been an
error for slaves to depend mutually upon each other. This configuration
has been used to enable a zone to flow from the primary master to all
slaves even though not all slaves have continuous connectivity to the
primary master. UPDATE's use of the AXFR dependency graph for
forwarding prohibits this kind of dependency loop, since UPDATE
forwarding has no loop detection analagous to the SOA SERIAL pretest
used by AXFR.
7.19. For UPDATE's purposes, a zone is said to own all names at or below
the zone's root. This allows an UPDATE message to add or delete names
below a zone cut so as to create and maintain ``glue'' records needed
for delegation when a name server is within the zone being delegated.
7.20. Previously existing names which are occluded by a new zone cut are
still considered part of the parent zone, for the purposes of zone
transfers, even though queries for such names will be referred to the
new subzone's servers. If a zone cut is removed, all parent zone names
that were occluded by it will again become visible to queries. (This is
a clarification of RFC 1034.)
Expires October 1996 [Page 25]
INTERNET-DRAFT DNS UPDATE March 1996
7.21. If a node contains any name server delegations (NS RRs), this node
is said to be owned by the child zone, and the parent will answer only
with a nonauthoritative referral to the child zone's servers if queried
for a name at or below the child zone's root, except in the case of an
QTYPE=NS query at the zone cut itself, for which the parent zone's
servers would answer authoritatively. (This is a clarification of RFC
1034.)
7.22. If a server is authoritative for both a zone and its child, then
queries for names at the zone cut between them will be answered
authoritatively using only data from the child zone. (This is a
clarification of RFC 1034.)
8 - Security Considerations
In the absence of DNS Security, the protocol described by this document
makes it possible for anyone who can reach an authoritative name server
to alter the contents of a zone. This strongly indicates a need for out
of band access control such as static access control lists enforced by
the server, or firewall techniques, or both.
At the time of this writing, work is progressing (see [DNSSEC]) on the
general problem of DNS Security; however, no specification exists (at
this time) for updating security related RRs, or for using security
related RRs to control UPDATE access.
Acknowledgements
We would like to thank the IETF DNSIND working group for their input and
assistance, in particular, Rob Austein, Randy Bush, Donald Eastlake,
Masataka Ohta, Mark Andrews, and Robert Elz.
Expires October 1996 [Page 26]
INTERNET-DRAFT DNS UPDATE March 1996
References
[RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specification,''
RFC 1035, USC/Information Sciences Institute, November 1987.
[DNSSEC]
Donald E. Eastlake and Charles W. Kaufman, ``Domain Name System
Protocol Security Extensions,'' Internet Draft, January 1996, <draft-
ietf-dnssec-secext-09.txt>.
[IXFR]
M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February
1996, <draft-ietf-dnsind-ixfr-06.txt>.
[NOTIFY]
P. Vixie, ``Notify: a mechanism for prompt notification of authority
zone changes,'' Internet Draft, February 1996, <draft-ietf-dnsind-
notify-06.txt>.
[KRE1996]
R. Elz, ``Serial Number Arithmetic,'' Internet Draft, February 1996,
<draft-ietf-dnsind-serial-00.txt>.
Authors' Addresses
Yakov Rekhter Susan Thomson
Cisco Systems Bellcore
170 West Tasman Drive 445 South Street
San Jose, CA 95134-1706 Morristown, NJ 07960
+1 914 528 0090 +1 201 829 4514
<yakov@cisco.com> <set@thumper.bellcore.com>
Jim Bound Paul Vixie
Digital Equipment Corp. Internet Software Consortium
110 Spitbrook Rd ZK3-3/U14 Star Route Box 159A
Nashua, NH 03062-2698 Woodside, CA 94062
+1 603 881 0400 +1 415 747 0204
<bound@zk3.dec.com> <paul@vix.com>
Expires October 1996 [Page 27]
=========================================================================
Date: Thu, 7 Mar 1996 23:47:55 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: BIND vs. AXFR
In-Reply-To: paul@VIX.COM's message of 24 Feb 1996 16:38:52 -0800
At the LA IETF DNSIND, I brought up "BIND vs. AXFR" and the feedback I got
back was strongly in favour of just fixing BIND, in both 4.9.3-P2 and in the
upcoming 4.9.4-T1A, to accept the full range of the AXFR protocol as specified
in RFC 1034/5, and then having 4.9.4-T1A (and later revs) just send the newer,
more efficient and entirely compliant AXFR stream that will cause pre-4.9.3-P2
named-xfer to dump core.
I will note this in the release notes when the time comes.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Thu, 7 Mar 1996 23:54:00 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: the packet size problem
In-Reply-To: paul@VIX.COM's message of 24 Feb 1996 23:05:52 -0800
My numbers and other facts were somewhat wrong in my earlier post. The limit
is 576 bytes, not 562; and it occurs in end hosts due to reassembly buffer size
problems, not in gateways and their inability to fragment. (Thanks go out to
Rob Austein and Thomas Narten for explaining these things to me.)
T/TCP doesn't do what we need, since it still relies on keeping the connection
up between transactions and if BIND could do that, I'd be using TCP more often.
(The problem is the number of flows, and therefore file descriptors, needed at
any given time.)
Various folks have recommended that we specify a new bit, MORE, using the last
remaining MBZ bit in the DNS Message Format. (DNSSEC consumed two of three.)
MORE is interesting since it applies both in the multipacket UDP case, and in
the multimessage TCP case. (Currently a UDP response is limited to 512 bytes,
and a TCP response to QUERY is limited to 64K bytes, and a TCP response to a
QUERY for AXFR uses an end marker to differentiate end-of-zone from connection
reset.)
I think MORE is the right answer since we can't hitch our wagon to IPv6's
larger reassembly buffer, and I truly do expect the average secure or AAAA
response to overflow the UDP datagram size limit.
I'll write this up in more detail in a week or so.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Thu, 7 Mar 1996 23:58:46 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: DNS Working Group redux?
In-Reply-To: paul@VIX.COM's message of 24 Feb 1996 23:18:06 -0800
Frank Kastenholz, an Area Director responsible for the DNSIND WG, held a short
session discussing future IETF DNS work, at the end of the LA IETF DNSIND
meeting. He collected a list of problems folks thought they had to solve, and
promised to discuss the issue further after DNSIND's work items are complete.
Frank showed no predisposition one way or another toward rechartering DNSIND
vs creating a new (DNSEVOLV?) WG. He was concerned that DNSIND was nine months
late with its deliverables and did not want us to try to take on any new work
until we finish. I considered this a very reasonable response and I am doing
my homework as fast as I can :-).
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Fri, 8 Mar 1996 01:29:01 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: draft-ietf-dnsind-notify-06.txt
In-Reply-To: gson@ARANEUS.FI's message of 24 Feb 1996 03:22:50 -0800
> Some comments regarding draft-ietf-dnsind-notify-06.txt:
>
> 1. There are two sections labeled "3.4."
Ooops. Fixed.
> 2. The first of the two sections labeled "3.4" says:
>
> 3.4. A master repeatedly sends a NOTIFY request to a slave until either
> too many copies have been sent (a ``timeout''), an ICMP message
> indicating that the port is unreachable, or until a NOTIFY response is
> received from the slave with a matching query ID, QNAME, and IP source
> address.
>
> When the notify request is transmitted using TCP rather than UDP,
> requiring the master to send the NOTIFY request "repeatedly" is
> unnecessary and inappropriate.
Ah ha. True. I had not considered and did not mention the transport choice.
The older specs say to try UDP first unless you expect a large response or are
doing a zone transfer. I don't know what circumstances would lead a server
to use TCP for NOTIFY, but I cannot think of a reason to prohibit it. Fixed.
> 3. The DNS message field which is referred to as QDCOUNT in RFC1035 is
> called QCOUNT throughout the draft. Since the draft does not itself
> describe the layout of the message, but relies on its definition in
> RFC1035, it should use names consistent with that definition.
I count only one instance of QCOUNT, and I changed it to QDCOUNT.
> 4. Section 3.3 says:
>
> 3.3. NOTIFY is similar to QUERY in that it has a request message with
> the header QR flag ``set'' and a response message with QR ``clear''.
>
> Here ``set'' and ``clear'' are the wrong way around.
Yikes. Fixed.
> 5. The section labeled "Security Considerations" says:
>
> 1. That a previous SOA query can optionally cause a master to NOTIFY a
> false slave.
>
> This apparently refers to the optional feature where a master would
> notify servers that had recently performed SOA queries. This
> behaviour was specified in an earlier draft, but it is not mentioned
> in the current version, so this particular security issue no longer
> applies.
Right you are. Fixed.
> Andreas Gustafsson, gson@araneus.fi
Thank you very much. After working on one of these documents for a long time,
I am no longer able to catch stupid errors like the above. I really do
appreciate your help.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Fri, 8 Mar 1996 01:51:35 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: notify-07
X-To: internet-drafts@cnri.reston.va.us, namedroppers@internic.net
DNSIND Working Group Paul Vixie (ISC)
INTERNET-DRAFT March, 1996
<draft-ietf-dnsind-notify-07.txt>
Updates: RFC 1035
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This draft describes the NOTIFY opcode for DNS, by which a master
server advises a set of slave servers that the master's data has been
changed and that a query should be initiated to discover the new
data.
1 - Rationale and Scope
1.1. Slow propagation of new and changed data in a DNS zone can be due
to a zone's relatively long refresh times. Longer refresh times are
beneficial in that they reduce load on the master servers, but that
benefit comes at the cost of long intervals of incoherence among
authority servers whenever the zone is updated.
Expires October 1996 [Page 1]
INTERNET-DRAFT DNS NOTIFY February 1996
1.2. The DNS NOTIFY transaction allows master servers to inform slave
servers when the zone has changed -- an interrupt as opposed to poll
model -- which it is hoped will reduce propagation delay while not
unduly increasing the masters' load. This specification only allows
slaves to be notified of SOA RR changes, but the architechture of NOTIFY
is intended to be extensible to other RR types.
1.3. This document intentionally gives more definition to the roles of
``Master,'' ``Slave'' and ``Stealth'' servers, their enumeration in NS
RRs, and the SOA MNAME field. In that sense, this document can be
considered an addendum to [RFC1035].
2 - Definitions and Invariants
2.1. The following definitions are used in this document:
Slave an authoritative server which uses zone transfer to
retrieve the zone. All slave servers are named in
the NS RRs for the zone.
Master any authoritative server configured to be the source
of zone transfer for one or more slave servers.
Primary Master master server at the root of the zone transfer
dependency graph. The primary master is named in the
zone's SOA MNAME field and optionally by an NS RR.
There is by definition only one primary master server
per zone.
Stealth like a slave server except not listed in an NS RR for
the zone. A stealth server, unless explicitly
configured to do otherwise, will set the AA bit in
responses and be capable of acting as a master. A
stealth server will only be known by other servers if
they are given static configuration data indicating
its existence.
Notify Set set of servers to be notified of changes to some
zone. Default is all servers named in the NS RRset,
except for any server also named in the SOA MNAME.
Some implementations will permit the name server
administrator to override this set or add elements to
it (such as, for example, stealth servers).
Expires October 1996 [Page 2]
INTERNET-DRAFT DNS NOTIFY February 1996
2.2. The zone's servers must be organized into a dependency graph such
that there is a primary master, and all other servers must use AXFR or
IXFR either from the primary master or from some slave which is also a
master. No loops are permitted in the AXFR dependency graph.
3 - NOTIFY Message
3.1. When a master has updated one or more RRs in which slave servers
may be interested, the master may send the changed RR's name, class,
type, and optionally, new RDATA(s), to each known slave server using a
best efforts protocol based on the NOTIFY opcode.
3.2. NOTIFY uses the DNS Message Format, although it uses only a subset
of the available fields. Fields not otherwise described herein are to
be filled with binary zero (0), and implementations must ignore all
messages for which this is not the case.
3.3. NOTIFY is similar to QUERY in that it has a request message with
the header QR flag ``clear'' and a response message with QR ``set''.
The response message contains no useful information, but its reception
by the master is an indication that the slave has received the NOTIFY
and that the master can remove the slave from any retry queue for this
NOTIFY event.
3.4. The transport protocol used for a NOTIFY transaction will be UDP
unless the master has reason to believe that TCP is necessary; for
example, if a firewall has been installed between master and slave, and
only TCP has been allowed; or, if the changed RR is too large to fit in
a UDP/DNS datagram.
3.5. If TCP is used, both master and slave must continue to offer name
service during the transaction, even when the TCP transaction is not
making progress. The NOTIFY request is sent once, and a ``timeout'' is
said to have occurred if no NOTIFY response is received within a
reasonable interval.
3.6. If UDP is used, a master periodically sends a NOTIFY request to a
slave until either too many copies have been sent (a ``timeout''), an
ICMP message indicating that the port is unreachable, or until a NOTIFY
response is received from the slave with a matching query ID, QNAME, IP
source address, and UDP source port number.
Expires October 1996 [Page 3]
INTERNET-DRAFT DNS NOTIFY February 1996
Note:
The interval between transmissions, and the total number of
retransmissions, should be operational parameters specifiable by the
name server administrator, perhaps on a per-zone basis. Reasonable
defaults are a 60 second interval (or timeout if using TCP), and a
maximum of 5 retransmissions (for UDP). It is considered reasonable
to use additive or exponential backoff for the retry interval.
3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, ADCOUNT>=0.
If ANCOUNT>0, then the answer section represents an unsecure hint at the
new RRset for this <QNAME,QCLASS,QTYPE>. A slave receiving such a hint
is free to treat equivilence of this answer section with its local data
as a ``no further work needs to be done'' indication. If ANCOUNT=0, or
ANCOUNT>0 and the answer section differs from the slave's local data,
then the slave should query its known masters to retrieve the new data.
3.8. In no case shall the answer section of a NOTIFY request be used to
update a slave's local data, or to indicate that a zone transfer needs
to be undertaken, or to change the slave's zone refresh timers. Only a
``data present; data same'' condition can lead a slave to act
differently if ANCOUNT>0 than it would if ANCOUNT=0.
3.9. This version of the NOTIFY specification makes no use of the
authority or additional data sections, and so conforming implementations
should set AUCOUNT=0 and ADCOUNT=0 when transmitting requests. Since a
future revision of this specification may define a backwards compatible
use for either or both of these sections, current implementations must
ignore these sections, but not the entire message, if AUCOUNT>0 and/or
ADCOUNT>0.
3.10. If a slave receives a NOTIFY request from a host that is not a
known master for the zone containing the QNAME, it should ignore the
request and produce an error message in its operations log.
Note:
This implies that slaves of a multihomed master must either know
their master by the ``closest'' of the master's interface addresses,
or must know all of the master's interface addresses. Otherwise, a
valid NOTIFY request might come from an address that is not on the
slave's state list of masters for the zone, which would be an error.
3.11. The only defined NOTIFY event at this time is that the SOA RR has
changed. Upon completion of a NOTIFY transaction for QTYPE=SOA, the
slave should behave as though the zone given in the QNAME had reached
its REFRESH interval (see [RFC1035]), i.e., it should query its masters
Expires October 1996 [Page 4]
INTERNET-DRAFT DNS NOTIFY February 1996
for the SOA of the zone given in the NOTIFY QNAME, and check the answer
to see if the SOA SERIAL has been incremented since the last time the
zone was fetched. If so, a zone transfer (either AXFR or IXFR) should
be initiated.
Note:
Because a deep server dependency graph may have multiple paths from
the primary master to any given slave, it is possible that a slave
will receive a NOTIFY from one of its known masters even though the
rest of its known masters have not yet updated their copies of the
zone. Therefore, when issuing a QUERY for the zone's SOA, the query
should be directed at the known master who was the source of the
NOTIFY event, and not at any of the other known masters. This
represents a departure from [RFC1035], which specifies that upon
expiry of the SOA REFRESH interval, all known masters should be
queried in turn.
4 - Details and Examples
4.1. Retaining query state information across host reboots is optional,
but it is reasonable to simply execute an SOA NOTIFY transaction on each
authority zone when a server first starts.
4.2. Each slave is likely to receive several copies of the same NOTIFY
request: One from the primary master, and one from each other slave as
that slave transfers the new zone and notifies its potential peers. The
NOTIFY protocol supports this multiplicity by requiring that NOTIFY be
sent by a slave/master only AFTER it has updated the SOA RR or has
determined that no update is necessary, which in practice means after a
successful zone transfer. Thus, barring delivery reordering, the last
NOTIFY any slave receives will be the one indicating the latest change.
Since a slave always requests SOAs and AXFR/IXFRs only from its known
masters, it will have an opportunity to retry its QUERY for the SOA
after each of its masters have completed each zone update.
4.3. If a master server seeks to avoid causing a large number of
simultaneous outbound zone transfers, it may delay for an arbitrary
length of time before sending a NOTIFY message to any given slave. It
is expected that the time will be chosen at random, so that each slave
will begin its transfer at a unique time. The delay shall not in any
case be longer than the SOA REFRESH time.
Expires October 1996 [Page 5]
INTERNET-DRAFT DNS NOTIFY February 1996
Note:
This delay should be a parameter that each primary master name server
can specify, perhaps on a per-zone basis. Random delays of between
30 and 60 seconds would seem adequate if the servers share a LAN and
the zones are of moderate size.
4.4. A slave which receives a valid NOTIFY should defer action on any
subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
completed the transaction begun by the first NOTIFY. This duplicate
rejection is necessary to avoid having multiple notifications lead to
pummeling the master server.
4.5 - Zone has Updated on Primary Master
Primary master sends a NOTIFY request to all servers named in Notify
Set. The NOTIFY request has the following characteristics:
query ID: (new)
op: NOTIFY (4)
resp: NOERROR
flags: AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_SOA
4.6 - Zone has Updated on a Slave that is also a Master
As above in 4.5, except that this server's Notify Set may be different
from the Primary Master's due to optional static specification of local
stealth servers.
Expires October 1996 [Page 6]
INTERNET-DRAFT DNS NOTIFY February 1996
4.7 - Slave Receives a NOTIFY Request from a Master
When a slave server receives a NOTIFY request from one of its locally
designated masters for the zone enclosing the given QNAME, with
QTYPE=SOA and QR=0, it should enter the state it would if the zone's
refresh timer had expired. It will also send a NOTIFY response back to
the NOTIFY request's source, with the following characteristics:
query ID: (same)
op: NOTIFY (4)
resp: NOERROR
flags: QR AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_SOA
This is intended to be identical to the NOTIFY request, except that the
QR bit is also set. The query ID of the response must be the same as
was received in the request.
4.8 - Master Receives a NOTIFY Response from Slave
When a master server receives a NOTIFY response, it deletes this query
from the retry queue, thus completing the ``notification process'' of
``this'' RRset change to ``that'' server.
5 - Security Considerations
We believe that the NOTIFY operation's only security considerations are:
1. That a NOTIFY request with a forged IP/UDP source address can cause a
slave to send spurious SOA queries to its masters, leading to a
benign denial of service attack if the forged requests are sent very
often.
2. That TCP spoofing could be used against a slave server given NOTIFY
as a means of synchronizing an SOA query and UDP/DNS spoofing as a
means of forcing a zone transfer.
Expires October 1996 [Page 7]
INTERNET-DRAFT DNS NOTIFY February 1996
6 - References
[RFC1035]
P. Mockapetris, "Domain Names - Implementation and Specification",
RFC 1035, USC/Information Sciences Institute, November 1987.
[IXFR]
M. Ohta, "Incremental Zone Transfer", Internet Draft, February 1996,
<draft-ietf-dnsind-ixfr-06.txt>.
7 - Author's Address
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
+1 415 747 0204
<paul@vix.com>
Expires October 1996 [Page 8]
=========================================================================
Date: Fri, 8 Mar 1996 08:29:02 -0500
Reply-To: "Greg A. Woods" <woods@most.weird.com>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: "Greg A. Woods" <woods@MOST.WEIRD.COM>
Organization: Planix, Inc.; Toronto, Ontario; Canada
Subject: Re: the packet size problem
X-To: Paul A Vixie <paul@VIX.COM>
In-Reply-To: Paul A. Vixie's message of "Thu, March 7,
1996 23:54:00 -0800" regarding "Re: the packet size problem" id
<VIXIE.96Mar7235358@wisdom.vix.com>
[ On Thu, March 7, 1996 at 23:54:00 (-0800), Paul A. Vixie wrote: ]
> Subject: Re: the packet size problem
>
> T/TCP doesn't do what we need, since it still relies on keeping the connection
> up between transactions and if BIND could do that, I'd be using TCP more often.
> (The problem is the number of flows, and therefore file descriptors, needed at
> any given time.)
Drat. Of course. Damn. What about taking the saving grace of T/TCP as
it is and paying the extra 3 packets (they are rather small!) to
re-connect for each transaction? I think this was initially what the
HTTP folks did to convince themselves that anything was better than
individual TCP connections for each transaction.
Of course I've never been a fan of UDP and like protocols.... ;-)
--
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
=========================================================================
Date: Sat, 9 Mar 1996 00:56:06 +1100
Reply-To: Robert Elz <kre@MUNNARI.OZ.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Robert Elz <kre@MUNNARI.OZ.AU>
Subject: Re: the packet size problem
X-To: Paul A Vixie <paul@VIX.COM>
In-Reply-To: Your message of "Thu, 07 Mar 1996 23:54:00 -0800."
<VIXIE.96Mar7235358@wisdom.vix.com>
Date: Thu, 7 Mar 1996 23:54:00 -0800
From: Paul A Vixie <paul@VIX.COM>
Message-ID: <VIXIE.96Mar7235358@wisdom.vix.com>
T/TCP doesn't do what we need, since it still relies on keeping the connection
up between transactions and if BIND could do that, I'd be using TCP more often.
(The problem is the number of flows, and therefore file descriptors, needed at
any given time.)
I agree with the conclusion, but not the reason. T/TCP is
designed around socket(), sendto(), close() semantics, there's
no need to keep fd's open between transactions (just during them).
The real problem with T/TCP is that the server needs to keep a cache
of everyone to whom it has talked in order to be any kind of win
over straight TCP (perhaps over TCP pushed to its design limits,
rather than TCP as often implemented). For any realistic large
DNS server, that cache would become huge. T/TCP allows entries
to be flushed (its all soft state), but at the cost of falling
back to regular TCP semantics for the next transaction.
The nature of DNS queries is likely to mean (that unless the
server can afford a truly giant connection cache) all queries
would have TCP semantics.
This was discussed a little during the T/TCP BOF - thoughts there
were that perhaps a protocol that is designed around synchronised
clocks (which T/TCP is explicitly designed to not require) migt
be a better choice - especially as dnssec requires synchronised
clocks anyway.
I don't think that the DNS should go about designing a new
transport protocol of its own (MORE bits, etc) all experience has
shown that this results in nothing better than what exists, but
with lots more maintenance headaches. Since the DNS can function,
though perhaps sub-optimally, with the UDP/TCP transport choice
that now exists, I would suggest requesting from the Transport
area a new, properly designed, transport protocol that the DNS
can add to its list of choices - then implementations that want
to improve effeciency can install that new transport.
There's been quite a lot of work done (research done) in this
area apparently, so this need not necessarily take a long time
to have done - I would not expect any longer than designing the
same thing in a DNS group. Deployment may be more difficult,
as building something out of UDP in the DNS code would be easier
to have installed, but unless we really get forced into a corner
I think we should be willing to accept this. I suspect that the
DNS people have better things to do that transport protocol
design.
I also don't consider in unacceptable to require that a DNS
implementation (including resolvers) that wants to support either
security, or IPng (or even more, both) should have a larger
than absolute minimum reassembly buffer. Simply saying "you
must suport reassembly up to 4K datagrams" (or some number)
in order to act as a DNS server or resolver would not be
unreasonable to me. Then simply send fragments (IPv6) or
permit fragmentation (IPv4) - however bad fragmentation is,
its really not likely to be much worse than a DNS designed
transport protocol.
kre
ps: anything that allows the DNS to construct longer messages out
of several shorter datagrams is a "transport protocol" for the
purposes of the above message.
=========================================================================
Date: Fri, 8 Mar 1996 09:42:06 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: the packet size problem
X-To: Robert Elz <kre@munnari.oz.au>
In-Reply-To: Your message of "Sat, 09 Mar 1996 00:56:06 +1100."
<1703.826293366@munnari.OZ.AU>
> The real problem with T/TCP is that the server needs to keep a cache
> of everyone to whom it has talked in order to be any kind of win
> over straight TCP (perhaps over TCP pushed to its design limits,
> rather than TCP as often implemented). For any realistic large
> DNS server, that cache would become huge. T/TCP allows entries
> to be flushed (its all soft state), but at the cost of falling
> back to regular TCP semantics for the next transaction.
>
> The nature of DNS queries is likely to mean (that unless the
> server can afford a truly giant connection cache) all queries
> would have TCP semantics.
Which is what I meant by saying that T/TCP ran into the "too many flows"
problem.
> [...] Since the DNS can function,
> though perhaps sub-optimally, with the UDP/TCP transport choice
> that now exists, I would suggest requesting from the Transport
> area a new, properly designed, transport protocol that the DNS
> can add to its list of choices - then implementations that want
> to improve effeciency can install that new transport.
A blasty datagram each-side-sends-once protocol with selective ACK would
solve HTTP's problems as well. The protocol spec for it is probably about
15 pages of text and 2000 lines of source code. I don't want to take it on.
I don't know how to request that the Transport area take it on. Please send
help and hints.
> There's been quite a lot of work done (research done) in this
> area apparently, so this need not necessarily take a long time
> to have done - I would not expect any longer than designing the
> same thing in a DNS group. Deployment may be more difficult,
> as building something out of UDP in the DNS code would be easier
> to have installed, but unless we really get forced into a corner
> I think we should be willing to accept this. I suspect that the
> DNS people have better things to do that transport protocol
> design.
Doing a minimal multipacket transaction protocol based on UDP is something
we do not need vendor approval for. BIND, or any other implementation of
a multipacket DNS protocol, could just ship new user-mode binaries and the
kernel (whether NT, Unix, or whatever) would never have to know what we
were up to. This makes short-cycle deployment a lot more realistic.
> I also don't consider in unacceptable to require that a DNS
> implementation (including resolvers) that wants to support either
> security, or IPng (or even more, both) should have a larger
> than absolute minimum reassembly buffer. Simply saying "you
> must suport reassembly up to 4K datagrams" (or some number)
> in order to act as a DNS server or resolver would not be
> unreasonable to me. Then simply send fragments (IPv6) or
> permit fragmentation (IPv4) - however bad fragmentation is,
> its really not likely to be much worse than a DNS designed
> transport protocol.
We have already agreed in the context of other proposals that it is OK to
ask all authority servers for a given zone to update before that zone can
use some new zone-level feature like security or updates or whatever. We
have also agreed, all of us including KRE, that anything which requires
all caching/recursion/forwarding servers to change before any zone can use
a new zone-level feature, is unacceptable.
MTUD runs into the too-many-flows problem.
ICMP isn't reliable, thus sending an overlarge response and running into a
distant reassembly buffer problem is not distinguishable from a timeout or
lost packet, whereas the server's reactions need to be distinguished.
Perhaps the right thing for the Transport area to do is to come up with a
specification for how to do reliable lightweight transactions on top of UDP.
Then we get the short cycle deployment without DNS having to invent a
transport. I think this "right thing" would be best for HTTP, too.
=========================================================================
Date: Fri, 8 Mar 1996 10:06:47 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: resend: diffs from dynDNS-07 to dynDNS-08,
per DNSIND LA IETF meeting
X-To: namedroppers@internic.net
my apologies if this appears to be a duplicate. some people, notably
our esteemed chair, did not get this the first time i sent it. there
_IS_ a controversial change in here, read it or weep.
To: namedroppers@internic.net
Subject: diffs from dynDNS-07 to dnsDNS-08, per DNSIND meeting at LA IETF
Date: Thu, 07 Mar 1996 18:48:41 -0800
From: Paul A Vixie <vixie@wisdom.home.vix.com>
4. added section 1.2 (renumbering 1.3), 7.19, 7.20, 7.21 and 7.22 per
conversation with PVM re: glue RR updates and zone cut clarifications.
3. added a NOTZONE error code and used it from within prerequisites processing
and update prescan sections. several section numbers changed.
2. changed the Reserved Section's name to "Additional Data Section" to be
compatible with current Secure DNS Updates draft.
1. added a sentence to the end of section 2.5.4 to make it compatible with
the surrounding text.
*** update.ms 1996/02/22 21:45:19 1.9
--- update.ms 1996/03/08 02:30:52
***************
*** 18,20 ****
.nr DI +3m
! .ds LF Expires September 1996
.ds CF
--- 19,21 ----
.nr DI +3m
! .ds LF Expires October 1996
.ds CF
***************
*** 22,24 ****
.ds LH INTERNET-DRAFT
! .ds RH February 1996
.ds CH DNS UPDATE
--- 23,25 ----
.ds LH INTERNET-DRAFT
! .ds RH March 1996
.ds CH DNS UPDATE
***************
*** 31,35 ****
INTERNET-DRAFT Susan Thomson (Bellcore)
! <draft-ietf-dnsind-dynDNS-07.txt> Yakov Rekhter (Cisco)
Jim Bound (DEC)
! February 1996
.fi
--- 32,36 ----
INTERNET-DRAFT Susan Thomson (Bellcore)
! <draft-ietf-dnsind-dynDNS-08.txt> Yakov Rekhter (Cisco)
Jim Bound (DEC)
! March 1996
.fi
***************
*** 136,138 ****
.RE
! .Sh "1.2 - New Assigned Numbers"
.DS
--- 137,144 ----
.RE
! .Sh "1.2 - Glue RRs"
! .LP
! For the purpose of determining whether a domain name used in the UPDATE
! protocol is contained within a specified zone, a domain name is ``in'' a zone
! if it is owned by that zone's domain name. See section 7.19 for details.
! .Sh "1.3 - New Assigned Numbers"
.DS
***************
*** 143,144 ****
--- 149,151 ----
RCODE = NOTAUTH (TBD: 9?)
+ RCODE = NOTZONE (TBD: 10?)
Opcode = UPDATE (5)
***************
*** 164,166 ****
+---------------------+
! | Reserved | reserved for future use
+---------------------+
--- 171,173 ----
+---------------------+
! | Additional Data | additional data
+---------------------+
***************
*** 172,175 ****
invariants (in terms of zone content) required for this update. The Update
! section contains the edits to be made, and the Reserved section has no defined
! use in this specification.
.Sh "2.1 - Transport Issues"
--- 179,182 ----
invariants (in terms of zone content) required for this update. The Update
! section contains the edits to be made, and the Additional Data section has
! no defined use in this specification.
.Sh "2.1 - Transport Issues"
***************
*** 204,206 ****
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
! | XXCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
--- 211,213 ----
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
! | ADCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
***************
*** 286,287 ****
--- 293,300 ----
T}
+ NOTZONE|10?|T{
+ .nf
+ A name used in the Prerequisite or
+ Update Section is not within the
+ zone denoted by the Zone Section.
+ T}
.TE
***************
*** 293,296 ****
The number of RRs in the Update Section.
! .IP XXCOUNT
! The number of RRs in the Reserved Section.
.RE
--- 306,309 ----
The number of RRs in the Update Section.
! .IP ADCOUNT
! The number of RRs in the Additional Data Section.
.RE
***************
*** 317,319 ****
UPDATE uses this section to denote the zone of the records being updated.
! All records to be updated will be in the same zone, and therefore the Zone
Section is allowed to contain exactly one record. The ZNAME is the zone
--- 330,332 ----
UPDATE uses this section to denote the zone of the records being updated.
! All records to be updated must be in the same zone, and therefore the Zone
Section is allowed to contain exactly one record. The ZNAME is the zone
***************
*** 441,444 ****
and will otherwise be ignored by the primary master. CLASS must be
! specified as NONE to distinguish this from an RR addition.
! .Sh "2.6 - Reserved Section"
.LP
--- 454,458 ----
and will otherwise be ignored by the primary master. CLASS must be
! specified as NONE to distinguish this from an RR addition. If no such RRs
! exist, then this Update RR will be silently ignored by the primary master.
! .Sh "2.6 - Additional Data Section"
.LP
***************
*** 476,478 ****
Next, the Prerequisite Section is checked to see that all prerequisites are
! satisfied by the current state of the zone.
.LP
--- 490,494 ----
Next, the Prerequisite Section is checked to see that all prerequisites are
! satisfied by the current state of the zone. Using the definitions expressed
! in Section 1.2, if any RR's NAME is not within the zone specified in the
! Zone Section, signal NOTZONE to requestor.
.LP
***************
*** 519,520 ****
--- 535,538 ----
return (FORMERR)
+ if (zone_of(rr.name) != ZNAME)
+ return (NOTZONE);
if (rr.class == ANY)
***************
*** 574,578 ****
.Sh "3.4.1 - Prescan"
! The Update Section is parsed into RRs and each RR's CLASS is checked to see
! if it is ANY, NONE, or the same as the Zone Class, else signal a FORMERR to
! the requestor.
.br
--- 592,597 ----
.Sh "3.4.1 - Prescan"
! The Update Section is parsed into RRs and each RR's CLASS is checked to see if
! it is ANY, NONE, or the same as the Zone Class, else signal a FORMERR to the
! requestor. Using the definitions in Section 1.2, each RR's NAME must be in
! the zone specified by the Zone Section, else signal NOTZONE to the requestor.
.br
***************
*** 591,592 ****
--- 610,613 ----
[rr] for rr in updates
+ if (zone_of(rr.name) != ZNAME)
+ return (NOTZONE);
if (rr.class == zclass)
***************
*** 749,756 ****
sections, or placing zeros (0) in the these ``count'' fields and not
! including any part of the original update. The XXCOUNT will be set to zero
! (0) the Reserved Section will be made empty in responses, no matter what was
! present in the request. The QR bit is set to one (1), and the response is
! sent back to the requestor. If the requestor used UDP, then the response
! will be sent to the requestor's source UDP port. If the requestor used TCP,
! then the response will be sent back on the requestor's open TCP connection.
.\"............................................................................
--- 770,778 ----
sections, or placing zeros (0) in the these ``count'' fields and not
! including any part of the original update. The ADCOUNT will be set to zero
! (0) the Additional Data Section will be made empty in responses, no matter
! what was present in the request. The QR bit is set to one (1), and the
! response is sent back to the requestor. If the requestor used UDP, then the
! response will be sent to the requestor's source UDP port. If the requestor
! used TCP, then the response will be sent back on the requestor's open TCP
! connection.
.\"............................................................................
***************
*** 794,796 ****
Update Section:|(see previous text)
! Reserved Section:|(empty)
.TE
--- 816,818 ----
Update Section:|(see previous text)
! Additional Data Section:|(empty)
.TE
***************
*** 862,864 ****
master server, it must allocate a new ID and prepare to enter the role of
! ``forwarding server'', which is a requestor with respect to the forward server.
.LP
--- 884,886 ----
master server, it must allocate a new ID and prepare to enter the role of
! ``forwarding server,'' which is a requestor with respect to the forward server.
.LP
***************
*** 894,896 ****
.bp
! .Sh "7 - Design and Implementation Notes"
.LP
--- 916,918 ----
.bp
! .Sh "7 - Design, Implementation, Operation, and Protocol Notes"
.LP
***************
*** 910,915 ****
.LP
! 7.3. The Reserved Zone might be used if some of the RRs later needed for
! Secure DNS Update are not actually zone updates, but rather ancillary keys or
! signatures not intended to be stored in the zone (as an update would be),
! yet necessary for validating the update operation.
.LP
--- 932,937 ----
.LP
! 7.3. The Additional Data Section might be used if some of the RRs later
! needed for Secure DNS Update are not actually zone updates, but rather
! ancillary keys or signatures not intended to be stored in the zone (as an
! update would be), yet necessary for validating the update operation.
.LP
***************
*** 971,975 ****
.LP
! 7.13. The Reserved Section in requests will be made empty by requestors,
! passed through unchanged by forwarders and ignored by primary master servers.
! The Reserved Section in responses will be made empty by primary master
servers, ignored by forwarders, and ignored by requestors. This is intended
--- 993,997 ----
.LP
! 7.13. The Additional Data Section will be made empty by requestors, passed
! through unchanged by forwarders and ignored by primary master servers. The
! Additional Data Section in responses will be made empty by primary master
servers, ignored by forwarders, and ignored by requestors. This is intended
***************
*** 1004,1005 ****
--- 1026,1057 ----
state.
+ .LP
+ 7.18. In a deep AXFR dependency graph, it has not historically been an error
+ for slaves to depend mutually upon each other. This configuration has been
+ used to enable a zone to flow from the primary master to all slaves even
+ though not all slaves have continuous connectivity to the primary master.
+ UPDATE's use of the AXFR dependency graph for forwarding prohibits this kind
+ of dependency loop, since UPDATE forwarding has no loop detection analagous
+ to the SOA SERIAL pretest used by AXFR.
+ .LP
+ 7.19. For UPDATE's purposes, a zone is said to own all names at or below the
+ zone's root. This allows an UPDATE message to add or delete names below a
+ zone cut so as to create and maintain ``glue'' records needed for delegation
+ when a name server is within the zone being delegated.
+ .LP
+ 7.20. Previously existing names which are occluded by a new zone cut are still
+ considered part of the parent zone, for the purposes of zone transfers, even
+ though queries for such names will be referred to the new subzone's servers.
+ If a zone cut is removed, all parent zone names that were occluded by it will
+ again become visible to queries. (This is a clarification of RFC 1034.)
+ .LP
+ 7.21. If a node contains any name server delegations (NS RRs), this node is
+ said to be owned by the child zone, and the parent will answer only with a
+ nonauthoritative referral to the child zone's servers if queried for a name
+ at or below the child zone's root, except in the case of an QTYPE=NS query
+ at the zone cut itself, for which the parent zone's servers would answer
+ authoritatively. (This is a clarification of RFC 1034.)
+ .LP
+ 7.22. If a server is authoritative for both a zone and its child, then queries
+ for names at the zone cut between them will be answered authoritatively using
+ only data from the child zone. (This is a clarification of RFC 1034.)
.\"............................................................................
=========================================================================
Date: Sat, 9 Mar 1996 06:18:47 +1100
Reply-To: Robert Elz <kre@MUNNARI.OZ.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Robert Elz <kre@MUNNARI.OZ.AU>
Subject: Re: the packet size problem
X-To: Paul A Vixie <paul@vix.com>
In-Reply-To: Your message of "Fri, 08 Mar 1996 09:42:06 -0800."
<9603081742.AA14091@wisdom.home.vix.com>
Date: Fri, 08 Mar 1996 09:42:06 -0800
From: Paul A Vixie <paul@vix.com>
Message-ID: <9603081742.AA14091@wisdom.home.vix.com>
The protocol spec for it is probably about
15 pages of text and 2000 lines of source code.
Don't bet on it, transport protocol design is a very tricky
issue to get right, which is why I strongly suggest that DNS groups
do not even think about getting involved.
I don't know how to request that the Transport area take it on.
We suggest it to the transport directorate, and the end to end list
probably.
We have already agreed in the context of other proposals that it is OK to
ask all authority servers for a given zone to update before that zone can
use some new zone-level feature like security or updates or whatever. We
have also agreed, all of us including KRE, that anything which requires
all caching/recursion/forwarding servers to change before any zone can use
a new zone-level feature, is unacceptable.
Yes, however at the transport level this amounts to never change
anything, as there will always be old caching servers around that
understand none of what is planned, no matter what it is (MORE bits,
or anything else). The answer in this case simply has to be simply
use TCP and pay the price.
Perhaps the right thing for the Transport area to do is to come up with a
specification for how to do reliable lightweight transactions on top of UDP.
If transport can be convinced to work on this, they'll define it
over an unreliable datagram layer. Whether you think of IP or UDP
as that unreliable datagram layer doesn't matter a lot. It may be
that for the DNS, taking a real protocol, and doing a specific
implementation of it, might be the way to go - provided you can live
with it not being implemented on old implementations, and can
gracefully fall back (most suggest new kernel level transport
protocols have the property that they fall over to standard TCP if
not implemented at the peer site).
kre
=========================================================================
Date: Sat, 9 Mar 1996 06:26:37 +1100
Reply-To: Robert Elz <kre@MUNNARI.OZ.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Robert Elz <kre@MUNNARI.OZ.AU>
Subject: Re: resend: diffs from dynDNS-07 to dynDNS-08,
per DNSIND LA IETF meeting
X-To: Paul A Vixie <paul@VIX.COM>
X-cc: namedroppers@internic.net
In-Reply-To: Your message of "Fri, 08 Mar 1996 10:06:47 -0800."
<9603081806.AA14242@wisdom.home.vix.com>
I'm still not sure you have the glue problem correct.
There are other cases glue is needed, beyond servers in
sub-domains of the zone being delegated.
The obvious case is (truly very rare, but possible) cross
domain servers, all the servers for one domain are in another, and
the servers for the other domain are in the first.
eg: for a.b the servers are all inside the x.y domain, and for x.y
all the servers are in the a.b domain. Glue in the delegations
(for at least one of them) is required.
What's really necessary here is to simply say that it is
legal to update glue associated with the zone that is named
in the update message, whatever the name of the associated
glue (this includes adding new glue of course).
In BIND, this is probably a non trivial implementation issue, as
BIND totally destroys the notion of glue, and mixes all of the
data in the zone into the cache however it seems to fit best.
But that's implementation, rather than protocol, glue should be
seen as being associated with the zone for which it is required,
it should be legal to update any glue that has been associated
with the zone. Of course, as BIND (now) does, it should still be
legal for the server to simply refuse to load irrelevant glue.
kre
=========================================================================
Date: Fri, 8 Mar 1996 11:36:00 PST
Reply-To: Randy Bush <randy@PSG.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Randy Bush <randy@PSG.COM>
Subject: dnsind 96.03.06
X-To: namedroppers <namedroppers@internic.net>
X-cc: Frank Kastenholz <kasten+iesg@ftp.com>,
Susan Thomson <set@thumper.bellcore.com>,
IETF Minutes <minutes@cnri.reston.va.us>
DNS IXFR, Notify, and Dynamic Update WG
IETF 35, Thu, Mar 7, 1996
Administrivia
Pontification by the chair: WG has exceeded time limit in charter, turned
left and right in search of truth. Time is running out. IXFR draft has
already gone to IESG, some folks now want to change it to be aligned with
dynDNS and notify drafts. Proposal: ask IESG to delay reviewing IXFR draft,
WG will progress dynDNS and notify drafts to where they can be submitted to
the IESG, bringing all three drafts into alignment (or not), by 4/15/96.
AD then held WG's feet to the fire, stating that the WG needs to finish
current, chartered drafts before entertaining new topics.
Drafts for discussion during WG meeting:
M Ohta
draft-ietf-dnsind-ixfr-06.txt (Standards track)
P Vixie
draft-ietf-dnsind-dynDNS-07.txt (Standards track)
draft-ietf-dnsind-notify-06.txt (Standards track)
R Elz
draft-ietf-dnsind-serial-01.txt (Informational track)
draft-ietf-dnsind-clarify-00.txt (Standards track)
draft-ietf-dnsind-2ndry-00.txt (Best Common Practice track)
M Patton
draft-ietf-dnsind-expires-00.txt (Standards track)
+ draft-ietf-dnsind-ixfr-06.txt
Draft was not discussed, since it has already been submitted to IESG.
+ draft-ietf-dnsind-dynDNS-07.txt
New semantics require that opcode be examined first in order to correctly
decode remainder of the packet; older RFCs do net specifically state this;
goal is to find a new wire format that supports the new semantics yet
retains backwards compatibility; e.g. Network General Sniffer does not look
at opcode before decoding contents of DNS packets.
Changes to draft for next version (-08):
- add rcode for zone error (from discussion on mailing list)
- forwarding loops: possibilities exist for loops in forwarding updates;
language will be added to draft to recognize this and warn DNS
administrators. Some discussion about whether the DNS admin can do this
easily, to be continued on the list. A suggestion was made to use an
additional RR field to prevent looping. New ideas are to be discussed on
the list, before 4/1/96.
Interaction with DHCP requires the ability to expire individual RRs, with
expiration time tied to DHCP lease time, therefore, need to pass expiration
time in dynanimic update. WG chair noted that the request had been heard,
and would be discussed on the list, WG will attempt to resolve it by 4/15/96
deadline if possible. A DHCP imlementor stated that he can live without
this ability, but really needs to see completion of dynamic update
specification.
It was noted that the class field is overloaded in the current draft,
i.e. the proposed format is not purely 103x.
It was noted that there has been a change in granularity; what apears to the
user as a single transaction has become two transactions, raising the
possibility of an intervening transaction and potential conflicts. Seemed
to be consensus that this is not the case.
There were questions about updates to glue records; there was general
agreement that issues exist, in particular there are possible problems with
secure DNS; need to solve these by 4/15/96.
+ draft-ietf-dnsind-notify-06.txt
Changes have been suggested on namedroppers, Vixie wants to make the changes
and post the next version.
+ draft-ietf-dnsind-serial-01.txt
Minor editorial changes have been suggested. There were no comments from the
WG, consensus from the WG is to go forward with the draft.
+ draft-ietf-dnsind-clarify-00.txt
Discussion of problems related to getting an answer from a different address
than was used in the query. It was noted that the server cannot identify
when a query was sent to a {multi,any}cast address, therefore when a client
sends a query to a {multi,any}cast address, the client should accept reply
from any address. Servers should reply from an address that clients can use
for subsequent, follow-on queries.
Difficulties interpreting TTLs on RRsets were discussed. It was stated that
all RRs in an RRset should have the same TTL; it was noted that this could
be effectively achieved by using the minimum TTL of the RRs in the RRset.
Some details need to be elaborated in the draft. Difficulties can arise
when RRsets with different TTLs are merged; WG sentiment is to not merge
RRsets from different sources and to specify rules for choosing between old
and new RRset data.
Vixie has list of clarifiactions that need to be incorporated into the
draft; this work will continue on the mailing list.
+ draft-ietf-dnsind-2ndry-00.txt
No substantial discussion in the WG, draft was punted to Bush for progress
as a BCP.
+ draft-ietf-dnsind-expires-00.txt
Suggestion to use a bitmap to allow simultaneous expiration of multiple RRs.
Counter-suggestion was made to change the type field allow qtypes, including
"any" in an expire record; general agreement that counter- suggestion is
preferable.
It was then noted that expiration of entire RRset as a unit is not
sufficient, need the ability to expire individual RRs, it's preferable to
have the expiration data in each RR. This can be done with creation of a
new, extended query (new qtype), then need a new zone-xfer protocol to
handle this; DHCP implementor stated he can deal with difficulties caused by
not providing RR-specific expiration, again he just wants dynDNS spec to be
done. There was agreement to not hold up the current draft, and deal with
this issue later.
The question was raised, does SOA serial number change when a record goes
away? It was decided that this is a contentious issue, therefore the draft
is put on hold until the three required drafts are completed; then to be
discussed on the list.
The chair stated his intention to aggressively discourage discussion on list
of the Elz and Patton drafts until required drafts are submitted to IESG.
+ discussion of AXFR wire format, BIND's perversion of it, the problems
caused thereby, to get some ideas about how to proceed.
Older versions of BIND don't handle multiple RRs in AXFR properly, may dump
core. Want to include as many as 16K RRs in a single message in the
interest of efficiency (compression). DiG makes assumption that if answer
count is not 0, it must be 1; similar problems exist throughout the BIND
code, Vixie has fixed many of these and continues to do so. Vixie is
pleased with improved performance of new AXFR ("LONGAXFR"), but is worried
about effects on older server implementations. "Insane" proposal to
implement new qAXFR allowing multiple RRs. Consensus was to provide a
4.9.3p? that will not dump core, wait a few months, then release 4.9.4 that
causes older servers to break. It was noted that this may not be such a
wide-spread issue, since it will only happen when secondarys are not updated
before primaries. Next version of BIND will support LONGAXFR by default,
with option to use older" AXFR.
Discussion of CERT Advisory warning of gethostbyaddr being fed an arbitrary
string with newline. There was consensus that appropriate protection needs
to be in gethostby{name,addr}. Existing sendmails need to be relinked (or
upgraded to current version)
+ Frank Kastneholz (AD) asked for indications of future directions for
DNS work. Answers from the WG:
o Marker RR needs work.
o Indirect A records, to renumber a large set of hosts, changing only a
few records.
o DNS for autonomous systems.
o DNS equivalent of host requirements spec
o Extended queries
o Breaking the packet size barrier.
o Investigate how DNS will scale for the next 10 years
o Multiparty update of domains
o Something like what drums is doing for mail
o Clarify usage of CNAME records
Thanks to Ken Lindahl for the minutes!
=========================================================================
Date: Sat, 9 Mar 1996 04:50:10 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: resend: diffs from dynDNS-07 to dynDNS-08,
X-To: kre@MUNNARI.OZ.AU
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <1919.826313197@munnari.OZ.AU>; from "Robert Elz" at Mar 9,
96 6:26 am
> I'm still not sure you have the glue problem correct.
> There are other cases glue is needed, beyond servers in
> sub-domains of the zone being delegated.
Agreed.
> The obvious case is (truly very rare, but possible) cross
> domain servers, all the servers for one domain are in another, and
> the servers for the other domain are in the first.
>
> eg: for a.b the servers are all inside the x.y domain, and for x.y
> all the servers are in the a.b domain. Glue in the delegations
> (for at least one of them) is required.
A little more realistic case is when all servers of a.b below a.b
and a.x below a.x are down, while some cross domain servers are
alive.
> What's really necessary here is to simply say that it is
> legal to update glue associated with the zone that is named
> in the update message, whatever the name of the associated
> glue (this includes adding new glue of course).
That's what is required by RFC 103[45].
Another subtle issue is that glues might better be associated
to delegation points of a zone, not to the top node of the zone,
though, it is impossible to describe it with the zone file
format in RFC 103[45].
That is, if we want to change glue A for aaa.com, glue A for bbb.com
with the same NS name should better be unaffected.
> In BIND, this is probably a non trivial implementation issue, as
> BIND totally destroys the notion of glue, and mixes all of the
> data in the zone into the cache however it seems to fit best.
Yes, and it is a security hole.
Masataka Ohta
=========================================================================
Date: Fri, 8 Mar 1996 15:41:02 -0500
Reply-To: Alexander Dupuy <dupuy@SMARTS.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Alexander Dupuy <dupuy@SMARTS.COM>
Subject: Re: the packet size problem
X-To: kre@MUNNARI.OZ.AU
> I don't think that the DNS should go about designing a new
> transport protocol of its own (MORE bits, etc) all experience has
> shown that this results in nothing better than what exists, but
> with lots more maintenance headaches.
> ps: anything that allows the DNS to construct longer messages out
> of several shorter datagrams is a "transport protocol" for the
> purposes of the above message.
Using MORE with TCP (the original MORE proposal didn't mention using it for
UDP) isn't a "transport protocol" even by your definition. It's just a way to
allow replies consisting of multiple DNS messages (limited to 64k) for
non-AXFR (non-IXFR) queries. While one wouldn't normally expect the reply to
an ordinary query to exceed 64k it's not inconceivable with some of the new
large RR types (and signature information added by DNSSEC).
Using MORE with UDP to indicate that there are multiple replies is a
"transport protocol" by your definition, and I agree with you that having DNS
implement a "transport protocol" is a bad idea, since any MORE proposal that
deals correctly with missing or out-of-order datagrams will be fairly complex
and will probably perform no better than just sending large datagrams.
> I also don't consider in unacceptable to require that a DNS
> implementation (including resolvers) that wants to support either
> security, or IPng (or even more, both) should have a larger
> than absolute minimum reassembly buffer. Simply saying "you
> must suport reassembly up to 4K datagrams" (or some number)
> in order to act as a DNS server or resolver would not be
> unreasonable to me. Then simply send fragments (IPv6) or
> permit fragmentation (IPv4) - however bad fragmentation is,
> its really not likely to be much worse than a DNS designed
> transport protocol.
There is one problem with the "just send large datagrams" approach; the DNS
server doesn't necessarily know whether a client "wants to support either
security, or IPng" if it gets a QTYPE=ANY query for a domain name with many
RRs. Just sending a large datagram which is too large for the reassembly
buffer of a client will cause the query to fail, whereas previously, a
truncated datagram would be returned, and the client would (hopefully) retry
the query using TCP.
One solution to this problem would be to give the MORE bit different semantics
in datagram (UDP) and stream (TCP) queries (it would be better to use a
different bit, but as Paul pointed out, DNSSEC used up the other two). In
stream-protocol DNS, MORE would only be set in replies, and would indicate a
multi-message response with additional messages to follow. In datagram-
protocol DNS, MORE would only be set in queries, and would indicate that
larger (4k or 8k for UDP - this number would have to be specified in the RFC)
datagrams could be accepted and should be sent by the server.
With this interpretation of the MORE bit for UDP queries, DNS implementations
could safely send large replies to implementations which could receive them,
while implementations with small reassembly buffers could still receive
truncated replies and then retry using TCP. In this way, large datagrams can
be sent with interoperability, but DNS doesn't have to reimplement IP
reassembly algorithm itself.
Applying the interoperability test to the new MORE semantics:
new server, old client, UDP
MORE not set in query, small datagram returned
old server, new client, UDP
MORE not set in query, small datagram returned
MORE set in query, small datagram returned
("illegal" MORE set in reply, indication that server doesn't grok MORE)
new server, new client, UDP
MORE not set in query, small datagram returned
MORE set in query, large datagram returned
new server, old client, TCP
MORE not set in reply, single-message reply accepted
MORE (and TC) set in first message of reply, first message accepted
following messages dropped (as duplicate responses?)
old server, new client, TCP
MORE not set in reply, single-message reply accepted
MORE not set, TC set in reply, truncated single-message reply accepted
new server, new client, TCP
MORE not set in reply, single-message reply accepted
MORE (and TC) set in first message of reply, first message accepted
MORE set in following messages of reply, following messages accepted
MORE not set in last message of reply, last message accepted
@alex
--
inet: dupuy@smarts.com
Member of the League for Programming Freedom -- write to lpf@uunet.uu.net
GCS d?@ H s++: !g p? !au a w v US+++$ C++$ P+ 3 L E++ N+(!N) K- W M V- po- Y+
t+ !5 j R G? tv-- b++ !D B- e>* u+(**)@ h--- f+ r++ n+ y+*
=========================================================================
Date: Sat, 9 Mar 1996 22:20:14 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: the packet size problem
In-Reply-To: kre@MUNNARI.OZ.AU's message of 8 Mar 1996 11:35:54 -0800
> The protocol spec for it is probably about
> 15 pages of text and 2000 lines of source code.
>
> Don't bet on it, transport protocol design is a very tricky
> issue to get right, which is why I strongly suggest that DNS groups
> do not even think about getting involved.
"Trust me." But on the other hand, I already said that I don't have
time to work on it, and if Transport is so darn far along, clearly we
should make use of the expertise that's already in motion.
> I don't know how to request that the Transport area take it on.
>
> We suggest it to the transport directorate, and the end to end list
> probably.
I like the "we" part of that statement. Who are they? Who are "we"?
(Hint: as an IAB member you could probably get more accomplished by
replacing "we" with "KRE" :-).)
> Yes, however at the transport level this amounts to never change
> anything, as there will always be old caching servers around that
> understand none of what is planned, no matter what it is (MORE bits,
> or anything else). The answer in this case simply has to be simply
> use TCP and pay the price.
I wish now that I had thought about this before I posted :-|. You're
right, of course.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Sat, 9 Mar 1996 22:36:03 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: dnsind 96.03.06
In-Reply-To: randy@PSG.COM's message of 8 Mar 1996 11:59:36 -0800
These are excellent notes, possibly the best of any I've seen from DNSIND.
Congrats to the note taker and editor. A few expansions are in order:
>+ draft-ietf-dnsind-dynDNS-07.txt
>
>New semantics require that opcode be examined first in order to correctly
>decode remainder of the packet; older RFCs do net specifically state this;
>goal is to find a new wire format that supports the new semantics yet
>retains backwards compatibility; e.g. Network General Sniffer does not look
>at opcode before decoding contents of DNS packets.
This should be in the past tense, since dynDNS-06 resolved all of the above
and that was a month or more before the meeting where the above was discussed.
>Interaction with DHCP requires the ability to expire individual RRs, with
>expiration time tied to DHCP lease time, therefore, need to pass expiration
>time in dynanimic update. WG chair noted that the request had been heard,
>and would be discussed on the list, WG will attempt to resolve it by 4/15/96
>deadline if possible. A DHCP imlementor stated that he can live without
>this ability, but really needs to see completion of dynamic update
>specification.
I could formalize my notes on EQUERY which has an RR encapsulation format which
would address Yakov's worries wrt DHCP lease times and RR-level expirations.
However, I do not believe that we have any hope of getting WG consensus before
our feet are moved all the way into the fire by the AD. Therefore I move we
let the current UPDATE proposal go to IESG as soon as we finish talking about
glue. It's inconvenient and even suboptimal to have the DHCP server and client
do their own DNS garbage collection, but raising this requirement when we are
already nine months late is just plain embarrassing. Since DHCP can get by
with UPDATE as specified, our most responsible action would be go forward with
it and handle this as part of my EDNS proposal to come later in the year.
>It was noted that the class field is overloaded in the current draft,
>i.e. the proposed format is not purely 103x.
To clarify: I never said that dynDNS-06,07[,08] were pure RFC 1035. What I
said was that they were backward compatible and would not break correct
implementations of the prior specification. Very different statements.
dynDNS-05 would have broken correct implementations of the previous specs.
>+ discussion of AXFR wire format, BIND's perversion of it, the problems
> caused thereby, to get some ideas about how to proceed.
>
>Older versions of BIND don't handle multiple RRs in AXFR properly, may dump
>core. Want to include as many as 16K RRs in a single message in the
>interest of efficiency (compression).
16K bytes, not RRs. This is because a compression pointer has a 14 bit offset
which makes any names appearing after the first 16KB of a DNS message unreach-
able by compression pointers. This isn't a huge problem since most names have
already been entered by the time a message is 16KB long. 64KB is the actual
maximum and I will at some point do some measurements to see if 16KB is hurting
us. The fixed header size has been well amortized by the 16KB point, so I
suspect that 16KB is not hurting us.
> DiG makes assumption that if answer
>count is not 0, it must be 1; similar problems exist throughout the BIND
>code, Vixie has fixed many of these and continues to do so. Vixie is
>pleased with improved performance of new AXFR ("LONGAXFR"), but is worried
>about effects on older server implementations.
Actually, "options long-axfr" is what a BIND 4.9.4-T1A administrator will need
to use to _prevent_ the new, more efficient format, from being used.
> "Insane" proposal to
>implement new qAXFR allowing multiple RRs. Consensus was to provide a
>4.9.3p? that will not dump core, wait a few months, then release 4.9.4 that
>causes older servers to break. It was noted that this may not be such a
>wide-spread issue, since it will only happen when secondarys are not updated
>before primaries. Next version of BIND will support LONGAXFR by default,
>with option to use older" AXFR.
Again, this is backwards, "options long-axfr" is not the default and its
specification in the named.boot file will cause the older, less efficient
but 4.9.3-P1 compatible AXFR to be generated.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Sat, 9 Mar 1996 23:37:30 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: resend: diffs from dynDNS-07 to dynDNS-08,
In-Reply-To: kre@MUNNARI.OZ.AU's message of 8 Mar 1996 11:47:27 -0800
[KRE]
> I'm still not sure you have the glue problem correct.
> There are other cases glue is needed, beyond servers in
> sub-domains of the zone being delegated.
>
> The obvious case is (truly very rare, but possible) cross
> domain servers, all the servers for one domain are in another, and
> the servers for the other domain are in the first.
>
> eg: for a.b the servers are all inside the x.y domain, and for x.y
> all the servers are in the a.b domain. Glue in the delegations
> (for at least one of them) is required.
Actually that's not something we worry about, since the "b", "y", or "."
servers have to have glue for these zones, so the cross-zone problem is
solvable with some extra queries -- and I think that's the way it ought
to work, since remotely held glue tends to be wrong.
As we discussed in person at the IETF terminal room on Friday morning,
the problem only occurs when a subdomain of one (N>1)th level domain
uses name servers in some subdomain of some different (N>1)th level domain,
and vice versa. Thus,
given:
HOME.VIX.COM. IN NS ACETES.PA.DEC.COM.
PA.DEC.COM. IN NS GW.HOME.VIX.COM.
and no
other servers for either zone, both zones would be unreachable. However,
if either zone has other servers which are reachable downward from ".",
or if one server needs the other but the reverse is not true, the badness
does not occur and we have nothing other than a little inefficiency to
worry about.
In actual practice, the inefficiency of doing the extra queries to get glue
has never approached within two lower orders of magnitude of the inefficiency
of using stale or incorrect glue and sending hundreds of thousands of queries
to an NS whose corresponding A RR has been polluted by bad glue.
Also, in actual practice, BIND doesn't support the mutual-subzone case right
now, so anybody who is trying to use it is losing horribly.
I guess you can tell that I want to file off this corner case and forget about
it. The case provided for in dynDNS-08 is where a subzone's servers are in
the, or some other, subzone. This is a valid, commonly occuring case, and if
we don't provide for it then these zones will not be reachable, no way, no
how.
>What's really necessary here is to simply say that it is
>legal to update glue associated with the zone that is named
>in the update message, whatever the name of the associated
>glue (this includes adding new glue of course).
My first thought about the update.vs.glue problem was to put all glue into
the additional data section of the UPDATE, letting the server pick and choose
what glue it cared to maintain. I mentioned this thought to PVM and he
suggested that for the case where the subzone's server is in the subzone,
the glue is in fact formally part of the parent, and that it should be as
updateable as the rest of the parent.
I think we might be able to compromise by altering the document so that glue
which is not owned by the zone's root can be included in the additional data
section of the UPDATE, but that the primary master is not required to pay any
attention to it. This solves your problem in that this obscure corner case
is not left totally out of the spec, and it solves my problem in that the
only things allowed in the Update Section will be updates to the zone named
in the Zone Section. Can you live with this? Can anybody else not live with
it? (Why not?)
>In BIND, this is probably a non trivial implementation issue, as
>BIND totally destroys the notion of glue, and mixes all of the
>data in the zone into the cache however it seems to fit best.
Not exactly true. Out of zone glue is dropped on incoming zone transfers,
never sent on outgoing zone transfers, and held as nonauthoritative cached
data (d_zone == 0) after it is acquired by a sysquery().
>But that's implementation, rather than protocol, glue should be
>seen as being associated with the zone for which it is required,
>it should be legal to update any glue that has been associated
>with the zone. Of course, as BIND (now) does, it should still be
>legal for the server to simply refuse to load irrelevant glue.
>
>kre
That's your proposal. My counterproposal is above. Are we there yet?
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Sun, 10 Mar 1996 17:35:23 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: the "options long-axfr" dilemma will have a different answer
X-To: namedroppers@internic.net
Wrt previous discussion about 4.9.3-P1 and earlier servers dumping core if
presented with a 4.9.4-T1A AXFR. My first guess, which the LA IETF DNSIND
folks said sounded OK, was a single global option called "long-axfr" which
would cause a new style server to revert to the older, inefficent format.
Mark Andrews suggested that a per-zone flag would be better, since servers
like UUNET or DECWRL with 10,000 zones would effectively never be able to
upgrade their AXFR format, and they probably need it more than most.
This caused me to rethink the issue and I realized that it's very simple to
just maintain a list of servers which should be fed the old format. When
4.9.4-T1A and later receive an AXFR, they will respond with the new or old
format based on the source address' presence on this list.
The default will be the new format, per previous discussion.
=========================================================================
Date: Sun, 10 Mar 1996 22:47:23 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: resend: diffs from dynDNS-07 to dynDNS-08,
In-Reply-To: Your message of "Mon, 11 Mar 1996 14:51:42 +0200."
<199603110551.OAA05906@necom830.hpcl.titech.ac.jp>
[ KRE, this one is definitely one you should read. --vix ]
[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]
> It's impossibility, not inefficiency.
> [...]
> You misunderstand the problem.
That must be so, and it must still be so. Please be patient with me and
answer the question I've put below.
> The pollution problem is unrelated to the cross reference issue.
>
> If "com", "a.com", "x.com" and "y.com" are separate zones and
> both "x.com" and "y.com" have an NS "ns.a.com", incollect glue
> A of "ns.a.com" for "x.com" pollutes glue A of "ns.a.com"
> for "y.com".
So, given:
; zone "."
com. IN NS zig.zag.com.
zig.zag.com. IN A 10.0.0.53 ; "in zone" by dynDNS-08 definition
; zone "com"
a.com. IN NS foo.bar.a.com.
foo.bar.a.com. IN A 10.0.0.71 ; "in zone" by dynDNS-08 definition
x.com. IN NS ns.a.com.
y.com. IN NS ns.a.com.
ns.a.com. IN A 128.45.1.1 ; "in zone" by dynDNS-08 definition
...I don't see any unreachable zones. The much more interesting case puts
the servers for x.com and y.com into some subdomain of EDU:
; zone "."
com. IN NS zig.zag.com.
zig.zag.com. IN A 10.0.0.53 ; "in zone" by dynDNS-08 definition
edu. IN NS dun.dee.edu.
dun.dee.edu. IN A 16.1.0.17 ; "in zone" by dynDNS-08 definition
; zone "com"
x.com. IN NS ns.a.edu. ; note lack of glue
y.com. IN NS ns.a.edu. ; note lack of glue
; zone "edu"
a.edu. IN NS foo.bar.a.edu.
foo.bar.a.edu. IN A 10.0.0.71 ; "in zone" by dynDNS-08 definition
; zone "a.edu"
ns.a.edu. IN A 128.45.1.1 ; "in zone" by dynDNS-08 definition
...and this demonstrates the case KRE explained to me in person, if not
necessarily the one he put into his namedroppers message Friday morning.
Note that there are still no unreachable zones, although servers will be
expected to implement query-restart to find the out of zone glue. This
is what I meant by "inefficient".
But I have not seen an unreachable zone when glue conforms to dynDNS-08's
rules. I appreciate the effort you're putting into explaining this to me,
and I can only suggest that in your next attempt, you include the exact
collection of RR's (with zone designations, as I did above) that give rise
to your concern.
> I think, with secured dynamic update, KRE wants to delegate the right
> to update NSes for foo.bar.au and their glue As by the administrator
> of foo.bar.au themselves.
That's all exactly true, since I remember KRE saying those exact words to
me in the LA IETF terminal room shortly before they pulled the plug on the
network connection, so it must have been at 11:30AM or so pacific time.
I don't think this is a good, or necessary practice. Secure or insecure,
data which is maintained in more than one place will be wrong, over time,
in at least one of the other places.
The _right_ way to solve secure out-of-zone glue is with additional data,
but to include the signatures of the out-of-zone in the additional data
section. This will absolutely prevent stale glue from occuring. And the
master servers of the zone whose glue includes out of zone A RR's can, as
I've demonstrated above, always reach the secure authority servers of the
"other zone" in order to retrieve signed glue RRs for its own additional
data.
I am becoming more certain by the hour that allowing "updates" of zone glue
rather than offers of the additional data of zone glue, would be a mistake.
>> Also, in actual practice, BIND doesn't support the mutual-subzone case right
>> now, so anybody who is trying to use it is losing horribly.
>
> That's a problem of BIND, not DNS.
> Masataka Ohta
It is the world's problem, until we can upgrade the world's BIND servers.
But the reason I mentioned it is that we are NOT, by observation, living
in a world that has mutual subzone configurations in it, since if anybody
is trying to do it, it is not working for them. Therefore this is not a
feature we have to make sure we support in the next protocol revisions.
=========================================================================
Date: Mon, 11 Mar 1996 14:51:42 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: resend: diffs from dynDNS-07 to dynDNS-08,
X-To: paul@VIX.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <VIXIE.96Mar9233728@wisdom.vix.com>; from "Paul A Vixie" at Mar
9, 96 11:37 pm
Paul;
> In actual practice, the inefficiency of doing the extra queries to get glue
It's impossibility, not inefficiency.
> has never approached within two lower orders of magnitude of the inefficiency
> of using stale or incorrect glue and sending hundreds of thousands of queries
> to an NS whose corresponding A RR has been polluted by bad glue.
You misunderstand the problem.
The pollution problem is unrelated to the cross reference
issue.
If "com", "a.com", "x.com" and "y.com" are separate zones and
both "x.com" and "y.com" have an NS "ns.a.com", incollect glue
A of "ns.a.com" for "x.com" pollutes glue A of "ns.a.com"
for "y.com".
I think, with secured dynamic update, KRE wants to delegate the right
to update NSes for foo.bar.au and their glue As by the administrator
of foo.bar.au themselves.
> Also, in actual practice, BIND doesn't support the mutual-subzone case right
> now, so anybody who is trying to use it is losing horribly.
That's a problem of BIND, not DNS.
Masataka Ohta
=========================================================================
Date: Mon, 11 Mar 1996 16:53:35 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: resend: diffs from dynDNS-07 to dynDNS-08,
X-To: paul@VIX.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <9603110647.AA15991@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 10, 96 10:47 pm
Paul;
> [ KRE, this one is definitely one you should read. --vix ]
>
> [Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]
> > It's impossibility, not inefficiency.
> > [...]
> > You misunderstand the problem.
>
> That must be so, and it must still be so. Please be patient with me and
> answer the question I've put below.
I already explained you glue related issue several times, when I
explained why zone name is necessary for dynamic update. The latter
was finally understood by you that was why ADDNEW and other dirty
things are removed.
Hopefully, this is the last one for other glue related issues.
> > The pollution problem is unrelated to the cross reference issue.
> >
> > If "com", "a.com", "x.com" and "y.com" are separate zones and
> > both "x.com" and "y.com" have an NS "ns.a.com", incollect glue
> > A of "ns.a.com" for "x.com" pollutes glue A of "ns.a.com"
> > for "y.com".
>
> So, given:
>
> ; zone "."
> com. IN NS zig.zag.com.
> zig.zag.com. IN A 10.0.0.53 ; "in zone" by dynDNS-08 definition
>
> ; zone "com"
> a.com. IN NS foo.bar.a.com.
> foo.bar.a.com. IN A 10.0.0.71 ; "in zone" by dynDNS-08 definition
> x.com. IN NS ns.a.com.
> y.com. IN NS ns.a.com.
> ns.a.com. IN A 128.45.1.1 ; "in zone" by dynDNS-08 definition
>
> ...I don't see any unreachable zones.
No, which is why pollution issues are unrelated cross reference
issues.
What if, an administrator of "x.com" asked an administrator of
"com" to add (or replace) a glue A of "131.112.32.132" to ns.a.com,
which is an IP address of a bad guy?
Imagine, if someone access "131.112.32.132" as a name server of "y.com.".
Even with proper security, it will result in a severe denial of
service attack.
> The much more interesting case puts
> the servers for x.com and y.com into some subdomain of EDU:
>
> ; zone "."
> com. IN NS zig.zag.com.
> zig.zag.com. IN A 10.0.0.53 ; "in zone" by dynDNS-08 definition
> edu. IN NS dun.dee.edu.
> dun.dee.edu. IN A 16.1.0.17 ; "in zone" by dynDNS-08 definition
> ...and this demonstrates the case KRE explained to me in person, if not
I'm afraid
< com. IN NS dun.dee.edu.
< dun.dee.edu. IN A 16.1.0.17 ; "out of zone" by dynDNS-08 definition
< edu. IN NS zig.zag.com.
< zig.zag.com. IN A 10.0.0.53 ; "out of zone" by dynDNS-08 definition
is the cross referential unreachable case, KRE and I are talking
about, which is why we say "unreachable".
> and I can only suggest that in your next attempt, you include the exact
> collection of RR's (with zone designations, as I did above) that give rise
> to your concern.
I did so already for the cross referential case, at Stockholm with
"cisco.com" and "ibm.com" as examples.
> > I think, with secured dynamic update, KRE wants to delegate the right
> > to update NSes for foo.bar.au and their glue As by the administrator
> > of foo.bar.au themselves.
>
> That's all exactly true, since I remember KRE saying those exact words to
> me in the LA IETF terminal room shortly before they pulled the plug on the
> network connection, so it must have been at 11:30AM or so pacific time.
> I don't think this is a good, or necessary practice.
Paul, to use glue records is the current specification and the
current practice.
They are maintained in several places.
> Secure or insecure,
> data which is maintained in more than one place will be wrong, over time,
> in at least one of the other places.
Exactly!
That's exactly why the wrong maintainance of glue records in one place
MUST NOT affect the maintainance of the glue records in other places.
> The _right_ way to solve secure out-of-zone glue is with additional data,
> but to include the signatures of the out-of-zone in the additional data
> section. This will absolutely prevent stale glue from occuring.
Paul, in the additional section, you can attach glue A's only to
a root of a zone.
But, to separate the maintainance of glues for different child
zones, we MUST attach glues to the zone's delegation points, not
the zone's root.
> > That's a problem of BIND, not DNS.
> It is the world's problem, until we can upgrade the world's BIND servers.
Agreed. But, still, not DNS.
> But the reason I mentioned it is that we are NOT, by observation, living
> in a world that has mutual subzone configurations in it, since if anybody
> is trying to do it, it is not working for them.
"com." and "edu." was doing so. "au." and "jp." maybe in the future.
Masataka Ohta
=========================================================================
Date: Mon, 11 Mar 1996 17:25:27 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: the packet size problem
X-To: paul@VIX.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <9603081742.AA14091@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 8, 96 9:42 am
> > The real problem with T/TCP is that the server needs to keep a cache
> > of everyone to whom it has talked in order to be any kind of win
> > over straight TCP (perhaps over TCP pushed to its design limits,
> > rather than TCP as often implemented). For any realistic large
> > DNS server, that cache would become huge. T/TCP allows entries
> > to be flushed (its all soft state), but at the cost of falling
> > back to regular TCP semantics for the next transaction.
> >
> > The nature of DNS queries is likely to mean (that unless the
> > server can afford a truly giant connection cache) all queries
> > would have TCP semantics.
>
> Which is what I meant by saying that T/TCP ran into the "too many flows"
> problem.
If amount of states in cache is a problem, anything which needs long
term state can't work, I'm afraid.
The best solution would be something which sends a burst of packets
at once before cache expiration. It is also good that, if all the
data packets have arrived, it can be known to the receiver.
That is, fragmented UDP seems to be the best solution.
Masataka Ohta
=========================================================================
Date: Mon, 11 Mar 1996 00:57:29 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: resend: diffs from dynDNS-07 to dynDNS-08,
X-To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: Your message of "Mon, 11 Mar 1996 16:53:35 +0200."
<199603110753.QAA06261@necom830.hpcl.titech.ac.jp>
> > > You misunderstand the problem.
> >
> > That must be so, and it must still be so. Please be patient with me and
> > answer the question I've put below.
>
> I already explained you glue related issue several times, when I
> explained why zone name is necessary for dynamic update. The latter
> was finally understood by you that was why ADDNEW and other dirty
> things are removed.
That wasn't the reason why I removed ADDNEW, as you know.
> > ...I don't see any unreachable zones.
>
> No, which is why pollution issues are unrelated cross reference
> issues.
>
> What if, an administrator of "x.com" asked an administrator of
> "com" to add (or replace) a glue A of "131.112.32.132" to ns.a.com,
> which is an IP address of a bad guy?
I expect the administrators of X.COM and COM to have some kind of authenticated
protocol, whether it's PGP mail, or DNS Security. We know that X.COM's admin
trusts the admin of COM once authentication has taken place. The question is,
what does COM's server do with a dynamic update from A.COM trying to update
information about B.COM's A RRs (which are glue for A.COM in this example)?
In the current situation, this glue tends to be added right in, to the
detriment of all if it's wrong or is the address of a bad guy. In a better
system (which requires no protocol changes or new technology), out of zone
glue would be verified by the COM server administrator before being added
to COM's glue. This could be done with a simple query. Bootstrapping is not
an important case since the information is given out of band and is
authenticated.
Some day domains will be added and deleted from COM via DNS Secure Update,
and the protocols and technology will be completely different, yet the basic
algorythm followed by the people involved will be the same as it (should be,
and could be, but is not) now.
> Imagine, if someone access "131.112.32.132" as a name server of "y.com.".
>
> Even with proper security, it will result in a severe denial of
> service attack.
If InterNIC verified out of zone glue, which they are already in a position
to do, then the record would never be added. I admit that this is a problem
otherwise, since without a primary tag in COM's delegation, there's no way to
know whose competing-but-different zone key is "correct." Signature
verification only occurs outward from "." if I understand Eastlake/Kaufmann
correctly.
In KRE's ideal world, the zone glue would be part of the zone even if it was
not owned by the zone, and it would only be given out with delegations from
this server, about this subzone. The DNS caching model doesn't give much
help to forwarding and recursive servers in this picture, though, unless they
only use this glue to do their own immediate query of the so-named servers
to get the "real list." This is infinite regress, since the so-named servers
can themselves be "bad". The only hope we have of getting authoritative glue
is to get it from someone whose key, or whose IP address, we can find reason
to trust along the transitive signature web, or from our own static config-
uration data.
In other words you're trying to solve the wrong problem and failing to solve
the actual problem.
> I'm afraid
>
> < com. IN NS dun.dee.edu.
> < dun.dee.edu. IN A 16.1.0.17 ; "out of zone" by dynDNS-08 definition
> < edu. IN NS zig.zag.com.
> < zig.zag.com. IN A 10.0.0.53 ; "out of zone" by dynDNS-08 definition
>
> is the cross referential unreachable case, KRE and I are talking
> about, which is why we say "unreachable".
> > Secure or insecure,
> > data which is maintained in more than one place will be wrong, over time,
> > in at least one of the other places.
>
> Exactly!
>
> That's exactly why the wrong maintainance of glue records in one place
> MUST NOT affect the maintainance of the glue records in other places.
I have a better idea. Let's just maintain them in one place, and treat as an
error the obscure mutual dependency you and KRE are worried about.
> > The _right_ way to solve secure out-of-zone glue is with additional data,
> > but to include the signatures of the out-of-zone in the additional data
> > section. This will absolutely prevent stale glue from occuring.
>
> Paul, in the additional section, you can attach glue A's only to
> a root of a zone.
>
> But, to separate the maintainance of glues for different child
> zones, we MUST attach glues to the zone's delegation points, not
> the zone's root.
I don't understand this. Any NS RR added by the Update section would have
either an owned-by A RR also added in the Update section, or a not-owned-by
A RR floating out in the Additional Data section. If you want to use
different A RRs with the same name and cause each of these variant A RRs
to adhere only to the root of the zone, or some child but not other children,
then there are certain classes of transaction which will not be able to be
done atomically. Violating the <NAME,CLASS,TYPE> -> <RDATA,*> identity in
this way is already an error. Why worry about it?
> > > That's a problem of BIND, not DNS.
>
> > It is the world's problem, until we can upgrade the world's BIND servers.
>
> Agreed. But, still, not DNS.
I don't believe I said it was DNS, I said we couldn't do it.
> > But the reason I mentioned it is that we are NOT, by observation, living
> > in a world that has mutual subzone configurations in it, since if anybody
> > is trying to do it, it is not working for them.
>
> "com." and "edu." was doing so. "au." and "jp." maybe in the future.
>
> Masataka Ohta
COM and EDU are maintained by the same servers. The glue is all there.
AU and JP had better be very careful if they want to interoperate with
older implementations which are still, and will always, be in the field.
It is important to realize that the desirable ability of keeping zone glue
with a zone and not polluting one's cache with it or answering with it other
than as needed for delegation, is not the same as granting a license to use
any old RDATA you want on an A RR whose name belongs to some zone you do not
own. You are expected to keep this data consistent, and implementations
ought to do everything they can to automate the process of keeping this data
consistent. If your out-of-zone glue A RRs are different from the A RRs
given out by that zone's authority servers, then your A RRs are _wrong_ by
definition. If this becomes a problem in practice, it means you need to
choose a different set of slave servers, whose names are better maintained.
Adding DNS Security won't change that model -- all it will do is require some
kind of out-of-band key exchange so that you will be able to verify the out-
of-zone glue and the servers you get your authoritative copy from. No matter
what technology or protocol is used, out-of-zone glue will belong to the
zone administrator who owns its name. I see this mutual dependency support
argument as symptomatic of an incorrect world view, wherein it would be
possible to use A RRs named under some other zone, and be authoritative for
their values.
=========================================================================
Date: Tue, 12 Mar 1996 13:58:50 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: resend: diffs from dynDNS-07 to dynDNS-08,
X-To: paul@VIX.COM
In-Reply-To: <9603110857.AA15308@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 11, 96 12:57 am
Paul;
> > I already explained you glue related issue several times, when I
> > explained why zone name is necessary for dynamic update. The latter
> > was finally understood by you that was why ADDNEW and other dirty
> > things are removed.
>
> That wasn't the reason why I removed ADDNEW, as you know.
I thought one of the reasons was that the addition of the zone name
section makes the number of sections 5.
> > > ...I don't see any unreachable zones.
> >
> > No, which is why pollution issues are unrelated cross reference
> > issues.
> >
> > What if, an administrator of "x.com" asked an administrator of
> > "com" to add (or replace) a glue A of "131.112.32.132" to ns.a.com,
> > which is an IP address of a bad guy?
>
> I expect the administrators of X.COM and COM to have some kind of authenticated
> protocol, whether it's PGP mail, or DNS Security. We know that X.COM's admin
> trusts the admin of COM once authentication has taken place. The question is,
> what does COM's server do with a dynamic update from A.COM trying to update
> information about B.COM's A RRs (which are glue for A.COM in this example)?
No.
The question is, how does COM's server distinguish a dynamic update
from A.COM trying to update information about A.COM's glue A RRs
between another dynamic update from B.COM trying to update information
about B.COM's glue A RRs, when they share an NS.
> In the current situation, this glue tends to be added right in, to the
> detriment of all if it's wrong or is the address of a bad guy.
Yes.
> In a better
> system (which requires no protocol changes or new technology), out of zone
> glue would be verified by the COM server administrator before being added
> to COM's glue.
In a better system (which requires no protocol changes, new technology,
new query, new restriction, new administrative burden), glue information
should be and could be (but is not with the current BIND) bound to
referral NS RRs.
It's just a issue of a correct implementation.
> Some day domains will be added and deleted from COM via DNS Secure Update,
> and the protocols and technology will be completely different, yet the basic
> algorythm followed by the people involved will be the same as it (should be,
> and could be, but is not) now.
Agreed (see above).
> Signature
> verification only occurs outward from "." if I understand Eastlake/Kaufmann
> correctly.
Last time I checked thier draft, it was broken on glue-related subtle
issues and I informed them of them (several times). I don't know they
are fixed now.
> In KRE's ideal world, the zone glue would be part of the zone even if it was
> not owned by the zone, and it would only be given out with delegations from
> this server, about this subzone.
Yes.
> The DNS caching model doesn't give much
> help to forwarding and recursive servers in this picture, though, unless they
> only use this glue to do their own immediate query of the so-named servers
> to get the "real list."
BIND caching model does not.
But, according to RFC 1035,
NS records cause both the usual additional section processing to locate
a type A record, and, when used in a referral, a special search of the
^^^^^^^^^^^^^^^^^^^^^^^
zone in which they reside for glue information.
^^^^
the referral information should be cached zone by zone.
Admittedly, without optional SOA in the authority section, it is
not easy to know which zone glue As belong. But, it's not necessary
to do so.
Just make cached NS RRs have a pointer to the glue A cache and the
RFC 1035 requirement is satisfied.
Now, with dynamic update, we can't expect glues in a zone consistent
anymore, so that the referral information should be cached NS by NS.
Quite surprisingly, the implementation technique above already
satisfies the new requirement.
> The only hope we have of getting authoritative glue
> is to get it from someone whose key, or whose IP address, we can find reason
> to trust along the transitive signature web, or from our own static config-
> uration data.
Do you think it difficult to fix BIND caching model? I think
it needs less than 500 lines of code.
Shall I volunteer?
> In other words you're trying to solve the wrong problem and failing to solve
> the actual problem.
Do you now understand that the problem is in BIND?
> > > Secure or insecure,
> > > data which is maintained in more than one place will be wrong, over time,
> > > in at least one of the other places.
> >
> > Exactly!
> >
> > That's exactly why the wrong maintainance of glue records in one place
> > MUST NOT affect the maintainance of the glue records in other places.
>
> I have a better idea. Let's just maintain them in one place, and treat as an
> error the obscure mutual dependency you and KRE are worried about.
Glues are glues. By nature, they CAN NOT be maintained in one place.
Accept the reality, the current specification.
> Violating the <NAME,CLASS,TYPE> -> <RDATA,*> identity in
> this way is already an error. Why worry about it?
Again from RFC 1035,
NS records cause both the usual additional section processing to locate
a type A record, and, when used in a referral, a special search of the
^^^^^^^^^^^^^^^^^^^^^^^
zone in which they reside for glue information.
^^^^
there is NO such identity.
> > > > That's a problem of BIND, not DNS.
> >
> > > It is the world's problem, until we can upgrade the world's BIND servers.
> >
> > Agreed. But, still, not DNS.
>
> I don't believe I said it was DNS, I said we couldn't do it.
So, why can't we fix bind?
> > "com." and "edu." was doing so. "au." and "jp." maybe in the future.
^^^
> COM and EDU are maintained by the same servers. The glue is all there.
I wrote "was". Moreover, according to your "in zone" definition,
glues can not be there.
> It is important to realize that the desirable ability of keeping zone glue
> with a zone and not polluting one's cache with it or answering with it other
> than as needed for delegation, is not the same as granting a license to use
> any old RDATA you want on an A RR whose name belongs to some zone you do not
> own.
Of course.
> You are expected to keep this data consistent, and implementations
> ought to do everything they can to automate the process of keeping this data
> consistent. If your out-of-zone glue A RRs are different from the A RRs
> given out by that zone's authority servers, then your A RRs are _wrong_ by
> definition. If this becomes a problem in practice, it means you need to
> choose a different set of slave servers, whose names are better maintained.
Paul, do you remember that you were doing that _wrong_ thing until
just recently on a nameserver of vix.com?
When I pointed it out to you, you have even claimed that it necessary.
> Adding DNS Security won't change that model -- all it will do is require some
> kind of out-of-band key exchange so that you will be able to verify the out-
> of-zone glue and the servers you get your authoritative copy from. No matter
> what technology or protocol is used, out-of-zone glue will belong to the
> zone administrator who owns its name.
With cryptographic technology, it is easy and desirable for the
administrators of "au." to delegate the right to modify referral
NS and glue A information of "foo.bar.au." to leaf administrators.
> I see this mutual dependency support
> argument as symptomatic of an incorrect world view, wherein it would be
> possible to use A RRs named under some other zone, and be authoritative for
> their values.
It is just a small problem of BIND failing to implement RFC 1035
semantics.
Masataka Ohta
=========================================================================
Date: Tue, 12 Mar 1996 07:35:28 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: resend: diffs from dynDNS-07 to dynDNS-08,
In-Reply-To: Your message of "Tue, 12 Mar 1996 13:58:50 +0200."
<199603120459.NAA08821@necom830.hpcl.titech.ac.jp>
> The question is, how does COM's server distinguish a dynamic update
> from A.COM trying to update information about A.COM's glue A RRs
> between another dynamic update from B.COM trying to update information
> about B.COM's glue A RRs, when they share an NS.
As I explained in my last message on this thread, there is no operational
reason why these records should ever be different. So your concern has to
be interpreted as a security question. If A.COM and B.COM are competitors
and want to do each other evil, then binding A.COM's B.COM glue to A.COM
will _not_ prevent that evil since COM's delegation of A.COM will still
contain bad glue for B.COM. Clients don't have to listen, especially if
as you point out below we add the optional SOA that tells is which zone
the glue is glue for. But clients _will_ listen, so the fix of allowing
per-zone glue is only a fix on paper, not in real life.
Perhaps COM's server should limit the domain of A.COM's glue to A.COM,
rather than COM. I can't imagine the InterNIC delegating update authority
for COM to anybody other than the folks they'll be sharing it with, and
this is one of the reasons. The Secure Updates draft I saw indicates that
update access control will be on a finer grain than the whole zone.
> In a better system (which requires no protocol changes, new technology,
> new query, new restriction, new administrative burden), glue information
> should be and could be (but is not with the current BIND) bound to
> referral NS RRs.
>
> It's just a issue of a correct implementation.
I'd like to forget about the installed base, too. We can't.
>>The DNS caching model doesn't give much
>>help to forwarding and recursive servers in this picture, though, unless they
>>only use this glue to do their own immediate query of the so-named servers
>>to get the "real list."
>
> BIND caching model does not.
>
> But, according to RFC 1035,
>
> NS records cause both the usual additional section processing to locate
> a type A record, and, when used in a referral, a special search of the
> ^^^^^^^^^^^^^^^^^^^^^^^
> zone in which they reside for glue information.
> ^^^^
>
> ... the referral information should be cached zone by zone.
We interpret those words very differently, you and I. To search the zone
where they reside, one must know the glue needed to reach that glue. I read
that to specifically make illegal your mutual dependency, which is the exact
opposite of your conclusion. "The zone where they reside" uses a pronoun and
I read it to refer to the A record whereas you read it to refer to the NS.
> Do you think it difficult to fix BIND caching model? I think
> it needs less than 500 lines of code.
>
> Shall I volunteer?
Anybody can add code to the current code base. Noone, not even I, can add
code to the installed base.
> Do you now understand that the problem is in BIND?
I think the definition of the problem turns on a pronoun.
I also think that I've been on the hot seat for 10,000 zone servers for a
long time, and BIND will not permit variant nonauthoritative often-wrong
glue until someone pries the RCS repository from my cold, dead fingers.
If PVM comes forward and says that the pronoun refers to the A RR, I will
point to existing practice and long experience to tell him that he was wrong.
Perhaps if it had been your primary name server that carried a network-0
address in most caching servers on the internet for more than a year, rather
than two of mine, you would understand my position better than you seem to.
Data which is maintained in more than one place will be wrong in at least one
of those places. Not "might be" or "can be" but _will_ be.
>>I have a better idea. Let's just maintain them in one place, and treat as an
>>error the obscure mutual dependency you and KRE are worried about.
>
> Glues are glues. By nature, they CAN NOT be maintained in one place.
Yes they can, because they currently are.
> Accept the reality, the current specification.
I accept the world as it exists. To quote Padlipski, the map is not the
territory.
> > Violating the <NAME,CLASS,TYPE> -> <RDATA,*> identity in
> > this way is already an error. Why worry about it?
>
> Again from RFC 1035,
>
> NS records cause both the usual additional section processing to locate
> a type A record, and, when used in a referral, a special search of the
> ^^^^^^^^^^^^^^^^^^^^^^^
> zone in which they reside for glue information.
> ^^^^
>
> there is NO such identity.
No matter how the pronoun thing comes out, that identity holds. An RRset has
an identity; its name and its RRs are strictly bound together.
> > I don't believe I said it was DNS, I said we couldn't do it.
>
> So, why can't we fix bind?
If you know how to fix BIND 4.8, 4.8.1, and 4.8.3, please tell me.
More servers run those versions than run anything newer.
> > COM and EDU are maintained by the same servers. The glue is all there.
>
> I wrote "was". Moreover, according to your "in zone" definition,
> glues can not be there.
The InterNIC asked my permission to remove the out of zone glue check for
the case where the NS RRs and A RRs were in different zones on the same set
of authority servers. I agreed.
>> You are expected to keep this data consistent, and implementations
>> ought to do everything they can to automate the process of keeping this data
>> consistent. If your out-of-zone glue A RRs are different from the A RRs
>> given out by that zone's authority servers, then your A RRs are _wrong_ by
>> definition. If this becomes a problem in practice, it means you need to
>> choose a different set of slave servers, whose names are better maintained.
>
> Paul, do you remember that you were doing that _wrong_ thing until
> just recently on a nameserver of vix.com?
Refresh my memory.
> When I pointed it out to you, you have even claimed that it necessary.
I don't run code which would permit the wrongness I'm talking about,
so we must be talking about different wrongnesses.
> With cryptographic technology, it is easy and desirable for the
> administrators of "au." to delegate the right to modify referral
> NS and glue A information of "foo.bar.au." to leaf administrators.
Yes. In which case the AU zone would have the subzone glue. What of it?
> > I see this mutual dependency support
> > argument as symptomatic of an incorrect world view, wherein it would be
> > possible to use A RRs named under some other zone, and be authoritative for
> > their values.
>
> It is just a small problem of BIND failing to implement RFC 1035
> semantics.
> Masataka Ohta
BIND implements RFC 1035 according to the way I interpreted the pronoun.
If and only if PVM says I read it wrong, you will quite correctly be able
to accuse BIND of doing something different from what RFC 1035 says.
=========================================================================
Date: Tue, 12 Mar 1996 12:27:37 -0500
Reply-To: Tom Limoncelli <tal@BIG.ATT.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Tom Limoncelli <tal@BIG.ATT.COM>
Subject: PTR records in subnetted class B domains
Question for y'all:
135.180.*.* is a class B. Suppose it is used as many "8-bit host" address:
135.180.1.*
135.180.2.*
135.180.3.*
135.180.4.*
etc.
Is the DNS data for the 180.135.in-addr.arpa zone supposed to include
all the PTR records for the entire class B or should it include
delegation records to deeper zones (1.180.135.in-addr.arpa,
2.180.135.in-addr.arpa, 3.180.135.in-addr.arpa, etc.)
Thanks in advance,
--tal
--
Tom Limoncelli -- tal@big.att.com (work) -- tal@plts.org (play)
"glowing with light"
=========================================================================
Date: Tue, 12 Mar 1996 13:31:57 -0500
Reply-To: carson@lehman.com
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Carson Gaspar <carson@LEHMAN.COM>
Subject: Re: PTR records in subnetted class B domains
X-To: Tom Limoncelli <tal@BIG.ATT.COM>
In-Reply-To: <9603121727.AA10541@lexicon.info.att.com>
>>>>> "Tom" == Tom Limoncelli <tal@BIG.ATT.COM> writes:
Tom> Question for y'all: 135.180.*.* is a class B. Suppose it is used
Tom> as many "8-bit host" address: 135.180.1.* 135.180.2.* 135.180.3.*
Tom> 135.180.4.* etc.
Tom> Is the DNS data for the 180.135.in-addr.arpa zone supposed to
Tom> include all the PTR records for the entire class B or should it
Tom> include delegation records to deeper zones
Tom> (1.180.135.in-addr.arpa, 2.180.135.in-addr.arpa,
Tom> 3.180.135.in-addr.arpa, etc.)
It should be irrelevant, except for administrative and load
issues. Unless they are different administrative domains, or you want
to do zone transfers of only part of the addresses, it shouldn't
matter.
--
Carson Gaspar -- carson@cs.columbia.edu carson@lehman.com
http://www.cs.columbia.edu/~carson/home.html
<This is the boring business .sig - no outre sayings here>
=========================================================================
Date: Tue, 12 Mar 1996 10:39:41 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: UPDATE vs. out of zone glue, and notes about dynDNS-09
X-To: namedroppers@internic.net
I've just spoken to KRE by telephone, and he can live with the wording I put
into the draft yesterday, which goes as follows (diffs against dynDNS-08).
I'm waiting for some copyedits from a buddy over at TGV before I release
dynDNS-09. For the record, the only thing I'm adding in -09 is out of zone
glue, can be offered in the additional data section and which the primary
master server does not need to use unless its implementor wants to.
I am _not_ going to put anything in for RR expiration at this time.
If this were CIDRD, I'd ask for a hum. As it is, I'll just ask that everyone
speak now or keep the peace until after PS. I am only expecting one comment
from within DNSIND during IESG Last Call, and that will be from Ohta-san, and
I already know what he's going to say. If anybody else has something they want
changed, I havn't heard it, and I would like to hear it sooner rather than
later.
***************
*** 178,185 ****
! The Header section specifies that this message is an UPDATE, and
! describes the size of the other sections. The Zone section names the
! zone that is to be updated by this message. The Prerequisite section
specifies the starting invariants (in terms of zone content) required
! for this update. The Update section contains the edits to be made, and
! the Additional Data section has no defined use in this specification.
--- 178,186 ----
! The Header Section specifies that this message is an UPDATE, and
! describes the size of the other sections. The Zone Section names the
! zone that is to be updated by this message. The Prerequisite Section
specifies the starting invariants (in terms of zone content) required
! for this update. The Update Section contains the edits to be made, and
! the Additional Data Section contains data which may be necessary to
! complete, but is not part of, this update.
***************
*** 512,517 ****
! This section is reserved for use by future extensions to this protocol.
! It will be ignored by servers, and made empty by requestors which
! implement only the protocol described by this document.
!
--- 512,517 ----
! This section contains RRs which are related to the update itself, or to
! new RRs being added by the update. For example, out of zone glue (A RRs
! referred to by new NS RRs) should be presented here. The server can use
! or ignore out of zone glue, at the discretion of the server implementor.
***************
*** 977,987 ****
response message is generated by copying the ID and Opcode fields from
! the request, and either copying the ZOCOUNT, PRCOUNT, and UPCOUNT fields
! and associated sections, or placing zeros (0) in the these ``count''
! fields and not including any part of the original update. The ADCOUNT
! will be set to zero (0) the Additional Data Section will be made empty
! in responses, no matter what was present in the request. The QR bit is
! set to one (1), and the response is sent back to the requestor. If the
! requestor used UDP, then the response will be sent to the requestor's
! source UDP port. If the requestor used TCP, then the response will be
! sent back on the requestor's open TCP connection.
--- 977,986 ----
response message is generated by copying the ID and Opcode fields from
! the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT, and
! ADCOUNT fields and associated sections, or placing zeros (0) in the
! these ``count'' fields and not including any part of the original
! update. The QR bit is set to one (1), and the response is sent back to
! the requestor. If the requestor used UDP, then the response will be
! sent to the requestor's source UDP port. If the requestor used TCP,
! then the response will be sent back on the requestor's open TCP
! connection.
***************
*** 1189,1191 ****
! 7.3. The Additional Data Section might be used if some of the RRs later
needed for Secure DNS Update are not actually zone updates, but rather
--- 1189,1198 ----
! 7.3. The Additional Data Section can be used to supply a server with out
! of zone glue that will be needed in referrals. For example, if adding a
! new NS RR to HOME.VIX.COM specifying a nameserver called NS.AU.OZ, the A
! RR for NS.AU.OZ can be included in the Additional Data Section. Servers
! can use this information or ignore it, at the discretion of the
! implementor.
!
! 7.4. The Additional Data Section might be used if some of the RRs later
needed for Secure DNS Update are not actually zone updates, but rather
(and i pushed the rest of the 7.x subsection numbers down, until...)
***************
*** 1262,1270 ****
- 7.13. The Additional Data Section will be made empty by requestors,
- passed through unchanged by forwarders and ignored by primary master
- servers. The Additional Data Section in responses will be made empty by
- primary master servers, ignored by forwarders, and ignored by
- requestors. This is intended to make it possible for future requestor
- specifications to use this section as a way to determine that a response
- was generated according to a future primary master server specification.
--- 1269,1270 ----
(...the old 7.13 was deleted.)
=========================================================================
Date: Wed, 13 Mar 1996 05:43:01 +1100
Reply-To: Robert Elz <kre@MUNNARI.OZ.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Robert Elz <kre@MUNNARI.OZ.AU>
Subject: Re: PTR records in subnetted class B domains
X-To: Tom Limoncelli <tal@BIG.ATT.COM>
In-Reply-To: Your message of "Tue, 12 Mar 1996 12:27:37 CDT."
<9603121727.AA10541@lexicon.info.att.com>
Date: Tue, 12 Mar 1996 12:27:37 -0500
From: Tom Limoncelli <tal@BIG.ATT.COM>
Message-ID: <9603121727.AA10541@lexicon.info.att.com>
Is the DNS data for the 180.135.in-addr.arpa zone supposed to include
all the PTR records for the entire class B or should it include
delegation records to deeper zones
Whatever is best for the zone, you can have everything in one
zone, everything delegated, or some in the parent zone and
some delegated. There is no one right way. The same applies
to "regular" (hostname) domains as well of course.
kre
=========================================================================
Date: Tue, 12 Mar 1996 10:12:27 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: zones that tick
X-To: namedroppers@internic.net
While I can appreciate the needs of the DNSSEC group, who want insecure data
to not be queryable at all when its signature has expired, and also with the
DHC group, who would like DNS data to expire automatically when a DHCP lease
expires, I have to wonder: has anybody given any thought to the effects of
these "expirations" on the SOA.SERIAL <-> Zone Content mapping?
It seems to me that if an authoritative server answers differently after time
T than it answered before time T, then any SOA.SERIALs made visible after time
T (or, for optimization, after the first different answer following time T)
must be different from the last SOA.SERIAL made visible before time T.
Following from that, it therefore seems to me that what we want is _not_ an
expiration time in each RR, but rather, a deferred UPDATE that does not become
active until time T, but when activated, can delete (or perhaps add?) RR's.
I still don't want to do this before the April 15 cutoff. But if and when
something does happen, I want you all to know that I regard expiration as a
special case of update, rather than as an attribute of an RR.
(Yes, we could do it as an RR attribute, but then we have to have zones
increment their serial numbers while they are sitting there, untouched but
still ticking. This makes me uncomfortable. I don't like things that tick.)
=========================================================================
Date: Wed, 13 Mar 1996 07:17:35 +1100
Reply-To: Robert Elz <kre@MUNNARI.OZ.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Robert Elz <kre@MUNNARI.OZ.AU>
Subject: Re: zones that tick
X-To: Paul A Vixie <paul@VIX.COM>
In-Reply-To: Your message of "Tue, 12 Mar 1996 10:12:27 -0800."
<9603121812.AA18982@wisdom.home.vix.com>
Date: Tue, 12 Mar 1996 10:12:27 -0800
From: Paul A Vixie <paul@VIX.COM>
Message-ID: <9603121812.AA18982@wisdom.home.vix.com>
It seems to me that if an authoritative server answers differently after time
T than it answered before time T, then any SOA.SERIALs made visible after time
T (or, for optimization, after the first different answer following time T)
must be different from the last SOA.SERIAL made visible before time T.
We had this discussion briefly in the meeting. I disagree.
The only possible use for such a requirement would be if it were
to be reasonable for a server (random caching server) to go
fetch the SOA for a zone from which it has data in its cache,
and if that hasn't changed, simply update the TTL on all the
records from this zone that are in its cache.
Apart from being almost impossible to implement, even if that
were to be desireable, I really don't think this is something
that should even be hinted as being possible.
The serial number need only change if something in the zone has
changed, such as to require a secondary server to perform a
new zone transfer (incremental or full).
The semantics applied to the information that's in the zone,
whether they apply that RRs appear, disappear, or mutate in
some specified way (maybe a bit turns on in a WKS record every
day at 09:00 and turns off again every day at 17:00, or
something) should not matter - as long as the semantics are
specified, and all authoritative servers implement it.
The normal operation of any such rule (none of which currently
exist) is not a change to the zone, and consequently no
serial number update is required (of course, serial numbers
can be updated any time, a reason isn't essential).
Following from that, it therefore seems to me that what we want is _not_ an
expiration time in each RR, but rather, a deferred UPDATE that does not become
active until time T, but when activated, can delete (or perhaps add?) RR's.
I (currently) think either way would work, provided that the
deferred update can, somehow, be transmitted to secondary servers
along with zone transfers (that clearly applies to an expiry
time added into each RR as well).
I still don't want to do this before the April 15 cutoff.
Certainly not, this stuff is not vital (useful in general, and
perhaps important to DHCP, but not vital to dynamic update).
I would generally defer much further discussion of this, at
least till the other drafts are done (which, with luck, will be
before April 15).
kre
=========================================================================
Date: Tue, 12 Mar 1996 14:50:02 -0800
Reply-To: Paul Wren <Paul.Wren@SOFTWARE.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul Wren <Paul.Wren@SOFTWARE.COM>
Subject: Question regarding PTR record management in DNS
X-To: namedroppers@internic.net
I have a question to which I could not find a definitive answer in any of
the RFC1034/5, DNS&Bind book, or any other resource:
Leaving aside for a moment questions of search efficiency which can be
solved separately, would it be possible for a domain name server to deduce
all of the information currently provided by the inaddr-arpa zone, merely by
searching it's "forward" zone tree to look up the IP address(es)?
If not, why not?
If so, it could solve a lot of the CIDR-related delegation nightmare
currently surrounding the inaddr-arpa domain...
Thanks in advance for your lucid commentary and incisive answers.
Constructive flaming also welcome... :-)
-- Paul@software.com
=========================================================================
Date: Tue, 12 Mar 1996 16:45:31 -0800
Reply-To: Paul Wren <Paul.Wren@SOFTWARE.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul Wren <Paul.Wren@SOFTWARE.COM>
Subject: Re: zones that tick
X-To: namedroppers@internic.net
At 07:17 AM 3/13/96 +1100, kre@MUNNARI.OZ.AU wrote:
< in response to P.Vixie message about "zones that tick" >
...
>The only possible use for such a requirement would be if it were
>to be reasonable for a server (random caching server) to go
>fetch the SOA for a zone from which it has data in its cache,
>and if that hasn't changed, simply update the TTL on all the
>records from this zone that are in its cache.
>
>Apart from being almost impossible to implement, even if that
>were to be desireable, I really don't think this is something
>that should even be hinted as being possible.
Too late. RFC1034 suggests this as experimental. And it doesn't seem
impossible to implement. Could you expand on why it would be impossible?
>The serial number need only change if something in the zone has
>changed, such as to require a secondary server to perform a
>new zone transfer (incremental or full).
But isn't a disappearing RR a "change" to the zone?
Actually, I don't see the problem with "zones that tick" but not having
P.Vixie's experience I'd take his word for that...but I certainly can see
his point that expired records _have_ changed the zone, so the serial number
should be updated.
=========================================================================
Date: Tue, 12 Mar 1996 18:22:55 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: zones that tick
In-Reply-To: Your message of "Tue, 12 Mar 1996 15:37:05 EST."
<Pine.SUN.3.91.960312153317.18045F-100000@cybercash.com>
> > expires, I have to wonder: has anybody given any thought to the effects of
> > these "expirations" on the SOA.SERIAL <-> Zone Content mapping?
>
> I thought the consensus of the WG meeting in LA was that no change was
> needed.
the consensus was that EXP wasn't needed.
>>It seems to me that if an authoritative server answers differently after time
>>T than it answered before time T, then any SOA.SERIALs made visible after tim
>>T (or, for optimization, after the first different answer following time T)
>>must be different from the last SOA.SERIAL made visible before time T.
>
> But, from the information given just before time T, you can tell exactly
> what answer it is going to give just after time T. So there really
> hasn't been any change. In particular, a secondary has no need to do a
> new zone transfer. So why change the serial?
someone using the mythical EQUERY that returned RR expiration info would be
able to predict the end of the old RR. someone using QUERY, assuming that
BIND turns ADDAUTH back on, would see
ANCOUNT>0
SERIAL=N
--
ANCOUNT=0
SERIAL=N
which is not what serial numbers are all about, regardless of the need or
lack of need to transfer the zone again.
if the only visibility of the expiring RR was via EQUERY, no automatic
serial number change needs to be made. but this isn't going to be the
average case for a long, long time.
=========================================================================
Date: Wed, 13 Mar 1996 11:44:53 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: zones that tick
X-To: paul@VIX.COM
In-Reply-To: <9603121812.AA18982@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 12, 96 10:12 am
> While I can appreciate the needs of the DNSSEC group, who want insecure data
> to not be queryable at all when its signature has expired,
Wrong.
Such functionality of nameservers gives no real security,
because, if a nameserver is compromised, it is easy to set
the clock to a wrong value.
It's a resolver implementation issue.
Though a resolver part of a recursive server may return anything,
including various error condistions, it has nothing to do with
the name server functionality of the recursive server such as
zone transfer.
That is, zone data content does not have to be affected.
> and also with the
> DHC group, who would like DNS data to expire automatically when a DHCP lease
> expires, I have to wonder: has anybody given any thought to the effects of
> these "expirations" on the SOA.SERIAL <-> Zone Content mapping?
You don't have to worry about DHCP, either.
With DHCPRELEASE message, it is possible to return assigned values
before it's expiration. The returned value can be used again.
CRL is a standard technique to do so with security and even without
security, we need something like CRL. If such mechanism exist,
EXPIRE RR is NOT necessary.
But, as the mechanism is not so handy, I think a reasonable
implementation of DHCP should live with relatively short zone
expiration periods.
Masataka Ohta
=========================================================================
Date: Wed, 13 Mar 1996 09:11:40 +1100
Reply-To: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Subject: Re: PTR records in subnetted class B domains
X-To: Tom Limoncelli <tal@big.att.com>
In-Reply-To: Your message of "Tue, 12 Mar 1996 12:27:37 CDT."
<9603121727.AA10541@lexicon.info.att.com>
> Question for y'all:
>
> 135.180.*.* is a class B. Suppose it is used as many "8-bit host" address:
> 135.180.1.*
> 135.180.2.*
> 135.180.3.*
> 135.180.4.*
> etc.
>
> Is the DNS data for the 180.135.in-addr.arpa zone supposed to include
> all the PTR records for the entire class B or should it include
> delegation records to deeper zones (1.180.135.in-addr.arpa,
> 2.180.135.in-addr.arpa, 3.180.135.in-addr.arpa, etc.)
>
> Thanks in advance,
> --tal
>
> --
> Tom Limoncelli -- tal@big.att.com (work) -- tal@plts.org (play)
> "glowing with light"
>
Entirly up to you. You may mix and match.
Mark
--
Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au
UUCP: ....!uunet!syd.dms.csiro.au!marka
=========================================================================
Date: Tue, 12 Mar 1996 20:19:20 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: zones that tick
In-Reply-To: Your message of "Wed, 13 Mar 1996 11:44:53 +0200."
<199603130245.LAA11075@necom830.hpcl.titech.ac.jp>
>> While I can appreciate the needs of the DNSSEC group, who want insecure data
>> to not be queryable at all when its signature has expired,
>
> Wrong.
Such tact. If I didn't know you so well, I'd be offended.
> Such functionality of nameservers gives no real security,
> because, if a nameserver is compromised, it is easy to set
> the clock to a wrong value.
I didn't say they wanted it for security. I said only that they wanted it,
and if you don't agree with this I suggest you read the DNSSEC-09 draft.
Perhaps I read it wrong, and was misdirected when I asked about this, and
in fact the signed RRset remains even after the covering SIG has expired.
>> and also with the
>> DHC group, who would like DNS data to expire automatically when a DHCP lease
>> expires, I have to wonder: has anybody given any thought to the effects of
>> these "expirations" on the SOA.SERIAL <-> Zone Content mapping?
>
> You don't have to worry about DHCP, either.
>
> With DHCPRELEASE message, it is possible to return assigned values
> before it's expiration. The returned value can be used again.
All true. Apparently you missed the LA DHC meetings, where someone brought
up what they considered an example of an average case, where the DHCP client
was turned off before it could release anything to anybody. The lease will
eventually expire and the DHCP server will do the appropriate DNS update to
make the PTR RR disappear. However, the DHCP client was responsible for
adding the A RR, and unless Yakov thinks of something very clever for his
DHCP/DYNDNS proposal, the A RR will remain until some third party does some
sort of garbage collection.
_This_ was the reason RR-level expiration times became suddenly important.
You can argue with Yakov, not me because I won't go into it further, as to
whether this represents an error in DHCP, or in DYNDNS, or in his interaction
draft.
> But, as the mechanism is not so handy, I think a reasonable
> implementation of DHCP should live with relatively short zone
> expiration periods.
> Masataka Ohta
I suppose that using a separate zone for each dynamically assignable hostname
is one way to get expiration in the short term. Perhaps you should suggest
that to Yakov, whose DHCP/DYNDNS Interaction draft needs to speak to this.
=========================================================================
Date: Wed, 13 Mar 1996 15:36:08 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: forwarding loops in UPDATE
X-To: paul@VIX.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <VIXIE.96Mar7012229@wisdom.vix.com>; from "Paul A Vixie" at Mar
7, 96 1:22 am
Paul;
It seems to me that you have a strange idea on how operational
issues are.
Operational issues are caused because real world operators do
everything regardless of whether it is not recommended,
forbidden, or, even impossible. They do so with all the good
or bad intention.
> Ohta-san's next suggestion was to remove the forwarding capability, since he
> does not see merit in my firewall argument (wherein the primary master server
> is separated from update clients by a firewall, but slave servers are able
> to reach to both horizons and therefore forward from one to the other). I
> still think we need to address the firewall case.
Paul, real world operators use firewalls.
If you allow secondaries relay update request, they will develop
a proxy server within a firewall which only relays non-dynamic
request to the primary.
On the other hand, if they think someone outside firewall may
dynamically update DNS data, they will open a hole in the
firewall.
That is, relaying feature only makes firewall issues complex.
> My next cheap solution was to compare only the message content. Ohta-san and
> I realized at about the same instant that this could result in false positives
> in the loop detection. (It turns out that BIND does this for queries already,
> but that's no excuse.)
The loop for normal query is NOT a problem because it traverses tree
which is assured to be loop free. A/IXFR query, also, won't cause
looping because of SOA serial.
The looping become a problem only when the "forwarders" feature is
used to form a loop. As an administrator, I did experienced it once.
It took several monthes to notice that there are many (but not too
many even for 10Mbps Ethernet) DNS packets floating around and
it took a few month to recongnize what actually happened.
> My own thinking is that we can get away with just warning server administrators
> that an AXFR dependency graph with loops in it will have catastrophic failure
> modes for UPDATE even though they were totally acceptable for QUERY(AXFR).
We can't.
> The looping AXFR graph is never necessary for correct server operation, and
> has almost always been inadvertent and an error when I've encountered it in
> real life.
The looping AXFR graph is the real world practice but caused no problem.
Finally, there is a fatal technical flaw in your non-solution.
> The reason for assigning a new ID is that the <ID,sourceaddr,sourceport> is
> how a server determines that it has received a duplicate request, and the
> <sourceaddr,sourceport> will be different when the packet is forwarded, thus
> requiring a new ID to be generated so as to prevent inadvertant duplicate
> <ID,addr,port> tuples. So, no help there.
That is, the IP address of the original requester is LOST.
Of course, it is not so secure to believe IP addresses outside
of a firewall. But, even without it, how can you check security
AFTER you check prerequisite?
Yes, real security does work. But, with it, we don't need firewalls.
Masataka Ohta
=========================================================================
Date: Wed, 13 Mar 1996 15:54:29 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: dynDNS-08
X-To: paul@VIX.COM
In-Reply-To: <9603080249.AA13460@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 7, 96 6:49 pm
Paul;
I'd like to suggest following modifications:
> 4 - Requestor Behaviour
>
> 4.1. From a requestor's point of view, any authoritative server for the
> zone can appear to be able to process update requests, even though only
> the primary master server is actually able to modify the zone's master
> file. Requestors are expected to know the name of the zone they intend
> to update and to know or be able to determine the name servers for that
> zone.
>
> 4.2. If update ordering is desired, the requestor will need to know the
> value of the existing SOA RR. Requestors who update the SOA RR must
> update the SOA SERIAL field in a positive direction (as defined by
> [KRE1996]) and to preserve the other SOA fields unless the requestor's
> explicit intent is to change them. The SOA SERIAL field must never be
> set to zero (0).
It seems to me that, secondaries are not assured to have the
current most SOA or the current most version of the zone,
which means continuous failures of update.
So, I, again, would like to suggest to remove the forwarding feature.
> 5 - Duplicate Detection, Ordering and Mutual Exclusion
>
> 5.1. For correct operation, mechanisms may be needed to ensure
> idempotence, order UPDATE requests and provide mutual exclusion. This
> is due to DNS's use of UDP, a datagram protocol which does not ensure
> reliable delivery. An UPDATE message or response might be delivered
> zero times, one time, or multiple times. Datagram duplication is of
> particular interest since it covers the case of the so-called ``replay
> attack'' where a correct request is duplicated maliciously by an
> intruder.
The explanaiton is wrong. TCP connection may also be lost and
re-established in which case some packets may be lost (zero times
delivery) or believed to be lost and sent again (multiple times
delivery).
That is, An UPDATE message or response might be delivered zero times,
one time, or multiple times.
> 5.3. A requestor can ensure transaction idempotence by explicitly
> deleting some ``marker RR'' (rather than deleting the RRset of which it
> is a part) and then adding a new ``marker RR'' with a different RDATA
> field. The Prerequisite Section should specify that the original
> ``marker RR'' must be present in order for this UPDATE message to be
> accepted by the server.
>
> 5.4. If the request is duplicated by a network error, all duplicate
> requests will fail since only the first will find the original ``marker
> RR'' present and having its known previous value.
Header ID field is already there to prevent duplicated request.
If a multitransaction request with marker RR fails, the requester
think the reason is because of other updates and reissues the
request.
That is, unless the requests are idempotent ones from the beginning,
there always a possibility of duplicated request.
> 7 - Design, Implementation, Operation, and Protocol Notes
Finally, an explanation should be added on how to assure
multitransaction atomic dynamic update with arbitrary any
prerequisite.
That is:
1) query a marker RR to some server
2) check prerequisite with normal query to the same server
3) send update request with a prerequisite of the marker RR
acquired at 1).
At 2), things like partial matches like
MX * foo.bar.
where * is an arbitrary number, or logical OR condition like
necom830 A 131.112.32.132
OR
necom830 A 131.112.32.132
exists can be checked as a prerequisite.
A decision on whether the current prerequisite section
is still necessary or not is up to you.
Masataka Ohta
=========================================================================
Date: Wed, 13 Mar 1996 00:02:24 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: forwarding loops in UPDATE
X-To: namedroppers@internic.net
In-Reply-To: Your message of "Wed, 13 Mar 1996 15:36:08 +0200."
<199603130636.PAA11571@necom830.hpcl.titech.ac.jp>
> It seems to me that you have a strange idea on how operational issues are.
That's a fair assessment. We are destined to agree to disagree about some
things, and operational issues are high on that list. So be it.
> If you allow secondaries relay update request, they will develop
> a proxy server within a firewall which only relays non-dynamic
> request to the primary.
>
> On the other hand, if they think someone outside firewall may
> dynamically update DNS data, they will open a hole in the
> firewall.
>
> That is, relaying feature only makes firewall issues complex.
Anyone who implements UPDATE and allows updates to be forwarded from outside
their enterprise network is insane. UPDATE has no security at all right now,
other than the likelihood that implementors will maintain a static list of
UPDATE source addresses. Name server administrators who put anything on that
static list that isn't as protected by a firewall as the primary master is,
will deserve everything bad that happens to them, which will be quite a lot.
In particular I do not expect anyone to put on that static list the address
of any external server. The canonical "IETF Terminal Room DHCP" example fails
utterly in the face of real world limitations. Remote updates will not be
feasable until DNS Secure Updates are available and ready. This does not
invalidate the need for forwarding; at best, my goal right now is to get some
experience implementing and testing forwarding so that DNS Secure Updates can
depend on it (forwarding). More below.
> The loop for normal query is NOT a problem because it traverses tree
> which is assured to be loop free. A/IXFR query, also, won't cause
> looping because of SOA serial.
>
> The looping become a problem only when the "forwarders" feature is
> used to form a loop. As an administrator, I did experienced it once.
Me, too, except I've experienced it (caused it, actually) more than once :-).
> It took several monthes to notice that there are many (but not too
> many even for 10Mbps Ethernet) DNS packets floating around and
> it took a few month to recongnize what actually happened.
Same here, in one case.
>> My own thinking is that we can get away with just warning server
>> administrators that an AXFR dependency graph with loops in it will have
>> catastrophic failure modes for UPDATE even though they were totally
>> acceptable for QUERY(AXFR).
>
> We can't.
We (you and I) disagree.
> > The looping AXFR graph is never necessary for correct server operation, and
> > has almost always been inadvertent and an error when I've encountered it in
> > real life.
>
> The looping AXFR graph is the real world practice but caused no problem.
But is it necessary for correct operation? Am I adding a constraint that will
break, by removing the only valid data path in, some valid configuration?
> Finally, there is a fatal technical flaw in your non-solution.
>
>> The reason for assigning a new ID is that the <ID,sourceaddr,sourceport> is
>> how a server determines that it has received a duplicate request, and the
>> <sourceaddr,sourceport> will be different when the packet is forwarded, thus
>> requiring a new ID to be generated so as to prevent inadvertant duplicate
>> <ID,addr,port> tuples. So, no help there.
>
> That is, the IP address of the original requester is LOST.
Yes. So? We could add some kind of spiffy RSA-signed certificate to the
additional data section so that primary masters would know that the ultimate
source of the update was someone or something it should trust, but if we did
that, we'd be reinventing (poorly, I'm sure) DNS Secure Updates. Donald is
much better qualified than I am to think about that kind of thing, and I am
content to let him dole out yet another solution to DNS's problems.
Meanwhile, it remains that source address checking is worse in most cases than
not having any security at all, since it provides the illusion of security
whereas having no security at all leads to a more appropriate level of worry.
Source address checking is at best "advisory" and will keep people from
updating a primary master server by accident, in some cases, but that's all
it will do. Someone deterimined to update your data will do so by faking
their source address, if your firewall gives them an opportunity by letting
their packets through.
> Of course, it is not so secure to believe IP addresses outside
> of a firewall. But, even without it, how can you check security
> AFTER you check prerequisite?
You can check security earlier, or not at all. I thought the document made
that clear.
I will add text to the Security Considerations section of the document, to
make it clearer than it already is, that updates from outside the enterprise
network are an unmistakably bad idea.
=========================================================================
Date: Wed, 13 Mar 1996 17:32:40 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: resend: diffs from dynDNS-07 to dynDNS-08,
X-To: paul@VIX.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <9603121535.AA16379@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 12, 96 7:35 am
Paul;
> > The question is, how does COM's server distinguish a dynamic update
> > from A.COM trying to update information about A.COM's glue A RRs
> > between another dynamic update from B.COM trying to update information
> > about B.COM's glue A RRs, when they share an NS.
>
> As I explained in my last message on this thread, there is no operational
> reason why these records should ever be different.
I'm afraid you expect too much for administrators.
> So your concern has to
> be interpreted as a security question. If A.COM and B.COM are competitors
> and want to do each other evil, then binding A.COM's B.COM glue to A.COM
> will _not_ prevent that evil since COM's delegation of A.COM will still
> contain bad glue for B.COM. Clients don't have to listen, especially if
> as you point out below we add the optional SOA that tells is which zone
> the glue is glue for. But clients _will_ listen, so the fix of allowing
> per-zone glue is only a fix on paper, not in real life.
The solution is NOT per-zone glue, but per NS glue, though both
satisfies RFC 1035 requirements of per-zone cache.
> Perhaps COM's server should limit the domain of A.COM's glue to A.COM,
> rather than COM.
Exactly.
> I can't imagine the InterNIC delegating update authority
> for COM to anybody other than the folks they'll be sharing it with, and
> this is one of the reasons.
In zone "COM.", updating referral NS for "A.COM." and its glue MAY
be delegated to the administrator of "A.COM.", isn't it?
Then, with first come first served policy, or, anything
mechanically enforcable ones, to create a new zone, whose
reply securely contains the cryptographical key for the
further update of "A.COM", the maintainance of "COM" is
almost automated.
Otherwise, if a large provider changes its prefix, what happnes
to the administrators of "COM"?
> The Secure Updates draft I saw indicates that
> update access control will be on a finer grain than the whole zone.
That's why finer grain control of glue is necessary.
> > In a better system (which requires no protocol changes, new technology,
> > new query, new restriction, new administrative burden), glue information
> > should be and could be (but is not with the current BIND) bound to
> > referral NS RRs.
> >
> > It's just a issue of a correct implementation.
>
> I'd like to forget about the installed base, too. We can't.
What is the problem of the current install base?
IMHO, they continue to be a BIND little less secure than the
improved ones.
> > NS records cause both the usual additional section processing to locate
> > a type A record, and, when used in a referral, a special search of the
> > ^^^^^^^^^^^^^^^^^^^^^^^
> > zone in which they reside for glue information.
> > ^^^^
> >
> > ... the referral information should be cached zone by zone.
>
> We interpret those words very differently, you and I. To search the zone
> where they reside, one must know the glue needed to reach that glue. I read
> that to specifically make illegal your mutual dependency, which is the exact
> opposite of your conclusion. "The zone where they reside" uses a pronoun and
> I read it to refer to the A record whereas you read it to refer to the NS.
Do you want to say "they" refers "a type A record", a singular noun?
^
But, anyway, both referral NS and glue A resides in the zone as an
unauthoritative data of the zone.
Moreover, as the zone boundaries are cut above the root, neither
referral NS and glue A, as a node, does not "reside" in the zone.
> > Do you think it difficult to fix BIND caching model? I think
> > it needs less than 500 lines of code.
> >
> > Shall I volunteer?
>
> Anybody can add code to the current code base. Noone, not even I, can add
> code to the installed base.
OK, I will improve the current code and the install base. Deal?
> > Do you now understand that the problem is in BIND?
>
> I think the definition of the problem turns on a pronoun.
See above. "they" is not "it". And, even if so...
> If PVM comes forward and says that the pronoun refers to the A RR, I will
> point to existing practice and long experience to tell him that he was wrong.
PVM has been right as long as the update granuity was a zone.
> Data which is maintained in more than one place will be wrong in at least one
> of those places. Not "might be" or "can be" but _will_ be.
That is THE operational problem.
> No matter how the pronoun thing comes out, that identity holds. An RRset has
> an identity; its name and its RRs are strictly bound together.
At the authoritative source, yes. For nonauthoritative case,
they are actually different in the real world operation.
> > So, why can't we fix bind?
>
> If you know how to fix BIND 4.8, 4.8.1, and 4.8.3, please tell me.
> More servers run those versions than run anything newer.
Why do you think you have to fix them?
> > > COM and EDU are maintained by the same servers. The glue is all there.
> The InterNIC asked my permission to remove the out of zone glue check for
> the case where the NS RRs and A RRs were in different zones on the same set
> of authority servers. I agreed.
.....
Do you want to say you have agreed to remove the out of zone glue
specification in the current draft?
Or, do you want to say you will ignore real world operational requests
not with implementation but with the specification?
> > With cryptographic technology, it is easy and desirable for the
> > administrators of "au." to delegate the right to modify referral
> > NS and glue A information of "foo.bar.au." to leaf administrators.
>
> Yes. In which case the AU zone would have the subzone glue. What of it?
Let's have subzone glue, which will be a gradual cure for bogus
RR problems.
Masataka Ohta
=========================================================================
Date: Wed, 13 Mar 1996 00:48:11 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: dynDNS-08
In-Reply-To: Your message of "Wed, 13 Mar 1996 15:54:29 +0200."
<199603130654.PAA11596@necom830.hpcl.titech.ac.jp>
> I'd like to suggest following modifications:
>
> > 4 - Requestor Behaviour
> >
> > 4.1. From a requestor's point of view, any authoritative server for the
> > zone can appear to be able to process update requests, even though only
> > the primary master server is actually able to modify the zone's master
> > file. Requestors are expected to know the name of the zone they intend
> > to update and to know or be able to determine the name servers for that
> > zone.
> >
> > 4.2. If update ordering is desired, the requestor will need to know the
> > value of the existing SOA RR. Requestors who update the SOA RR must
> > update the SOA SERIAL field in a positive direction (as defined by
> > [KRE1996]) and to preserve the other SOA fields unless the requestor's
> > explicit intent is to change them. The SOA SERIAL field must never be
> > set to zero (0).
>
> It seems to me that, secondaries are not assured to have the
> current most SOA or the current most version of the zone,
> which means continuous failures of update.
>
> So, I, again, would like to suggest to remove the forwarding feature.
Removing the forwarding feature would not to be much help to this problem.
If update ordering is required, a client has to have a way to get the current
SOA value. Since it doesn't know which NS RR represents the primary, and
since the primary may not even be reachable, finding the current SOA is going
to be pretty difficult. It doesn't matter if you're ultimately going to have
to use a forwarder -- the problem starts at the moment you need the current
SOA, since the protocol doesn't provide or require reliable access to it.
(EQUERY has a "want AA" bit, for this reason among several others.)
I will add something to section 7 explaining this problem, and it's a doozy.
But note that it doesn't have anything to do with forwarding.
> > 5 - Duplicate Detection, Ordering and Mutual Exclusion
> >
> > 5.1. For correct operation, mechanisms may be needed to ensure
> > idempotence, order UPDATE requests and provide mutual exclusion. This
> > is due to DNS's use of UDP, a datagram protocol which does not ensure
> > reliable delivery. An UPDATE message or response might be delivered
> > zero times, one time, or multiple times. Datagram duplication is of
> > particular interest since it covers the case of the so-called ``replay
> > attack'' where a correct request is duplicated maliciously by an
> > intruder.
>
> The explanaiton is wrong. TCP connection may also be lost and
> re-established in which case some packets may be lost (zero times
> delivery) or believed to be lost and sent again (multiple times
> delivery).
>
> That is, An UPDATE message or response might be delivered zero times,
> one time, or multiple times.
You're right. I hadn't considered the fact that we aren't doing a session
level three way handshake, which means the final TCP connection reset is
ambiguous in at least one direction. I will delete the sentence about UDP,
since even with TCP it is possible for the client to believe the update
failed even though the server has performed the update. Good eye.
> > 5.3. A requestor can ensure transaction idempotence by explicitly
> > deleting some ``marker RR'' (rather than deleting the RRset of which it
> > is a part) and then adding a new ``marker RR'' with a different RDATA
> > field. The Prerequisite Section should specify that the original
> > ``marker RR'' must be present in order for this UPDATE message to be
> > accepted by the server.
> >
> > 5.4. If the request is duplicated by a network error, all duplicate
> > requests will fail since only the first will find the original ``marker
> > RR'' present and having its known previous value.
>
> Header ID field is already there to prevent duplicated request.
No, since the source address qualifies the ID, and we lose that in forwarding.
(This is true in the query case, as well, and BIND finesses this by comparing
the whole packet against everything on its forwarding queue, which won't work
as a solution for UPDATE due to the reasons we discussed in the LA IETF
terminal room.)
> If a multitransaction request with marker RR fails, the requester
> think the reason is because of other updates and reissues the
> request.
>
> That is, unless the requests are idempotent ones from the beginning,
> there always a possibility of duplicated request.
Each transaction needs its own marker RR. If the totality of an update
operation needs more than one transaction, then the "multitransaction
request" will need its own "outer" marker RR.
> > 7 - Design, Implementation, Operation, and Protocol Notes
>
> Finally, an explanation should be added on how to assure
> multitransaction atomic dynamic update with arbitrary any
> prerequisite.
>
> That is:
>
> 1) query a marker RR to some server
>
> 2) check prerequisite with normal query to the same server
>
> 3) send update request with a prerequisite of the marker RR
> acquired at 1).
>
> At 2), things like partial matches like
>
> MX * foo.bar.
>
> where * is an arbitrary number, or logical OR condition like
>
> necom830 A 131.112.32.132
>
> OR
>
> necom830 A 131.112.32.132
>
> exists can be checked as a prerequisite.
I suspect that you intended the addresses in the last example to be different.
In any case I don't know of a reason to support "OR", or any other logical
operator. We are not, as I said earlier, trying to create a programming
language here.
I heard you mention at the LA IETF DNSIND meeting that you thought there ought
to be a standard for marker RR's. I don't agree, since the kind of locking
being done here is "advisory", where the application is only trying to protect
against simultaneous updates by another instance of itself on some other host,
or another instance of the same privately defined locking mechanism.
At 25 pages, I am weighing new text very carefully to make sure that the
document does not become so long that it's unreadable (that is, unreadable
for a different reason than it is unreadable now :-)). To fully describe
a multitransaction update would take another full page. I don't see the
need, since your formulation above is the simplest possible interpretation
of what the document already says, and it is perfectly correct. There are
other correct ways to use the UPDATE to achieve the same result.
> A decision on whether the current prerequisite section
> is still necessary or not is up to you.
> Masataka Ohta
A separate prerequisites section still represents my best attempt to shoehorn
all the features the WG called for into the DNS Message Format. Since it is
optional, I expect that those who think (as you apparently do) it is not
necessary will simply not use it. Others, including me, think that it is
necessary and it will therefore not be optional in the server implementation.
=========================================================================
Date: Wed, 13 Mar 1996 17:52:01 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: forwarding loops in UPDATE
X-To: paul@VIX.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <9603130802.AA20272@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 13, 96 12:02 am
Paul;
> > It seems to me that you have a strange idea on how operational issues are.
>
> That's a fair assessment. We are destined to agree to disagree about some
> things, and operational issues are high on that list. So be it.
...
> > > The looping AXFR graph is never necessary for correct server operation, and
> > > has almost always been inadvertent and an error when I've encountered it in
>
> > > real life.
> >
> > The looping AXFR graph is the real world practice but caused no problem.
>
> But is it necessary for correct operation?
What people expect for operators is comfortable operation, not
necessarily correct ones.
Though incorrect operation is often uncomfortable, correctness is
not the primary goal.
> Am I adding a constraint that will
> break, by removing the only valid data path in, some valid configuration?
Yes, of course.
There are no way to automatically detect the currently harmless
AXFR loop, which a lot of people are using.
> Meanwhile, it remains that source address checking is worse in most cases than
> not having any security at all, since it provides the illusion of security
> whereas having no security at all leads to a more appropriate level of worry.
> Source address checking is at best "advisory" and will keep people from
> updating a primary master server by accident, in some cases, but that's all
> it will do.
Source address behind a firewall is reasonably secure.
> Someone deterimined to update your data will do so by faking
> their source address, if your firewall gives them an opportunity by letting
> their packets through.
Do you want to say broken firewall is not a good protection?
If so, everyone should agree.
Masataka Ohta
=========================================================================
Date: Wed, 13 Mar 1996 01:55:29 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: <draft-ietf-dnsind-dynDNS-09.txt>
X-To: internet-drafts@cnri.reston.va.us
X-cc: namedroppers@internic.net
DNSIND Working Group Paul Vixie (Ed.) (ISC)
INTERNET-DRAFT Susan Thomson (Bellcore)
<draft-ietf-dnsind-dynDNS-09.txt> Yakov Rekhter (Cisco)
Jim Bound (DEC)
Amends: RFC 1035 March 1996
Dynamic Updates in the Domain Name System (DNS UPDATE)
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The Domain Name System was originally designed to support queries of
a statically configured database. While the data was expected to
change, the frequency of those changes was expected to be fairly low,
and all updates were made as external edits to a zone's Master File.
Using this specification of the UPDATE opcode, it is possible to add
or delete RRs or RRsets from a specified zone. Prerequisites are
specified separately from update operations, and can specify a
dependency upon either the previous existence or nonexistence of an
RRset, or the existence of a single RR.
UPDATE is atomic, i.e., all prerequisites must be satisfied or else
no update operations will take place. There are no data dependent
error conditions defined after the prerequisites have been met.
Expires October 1996 [Page 1]
INTERNET-DRAFT DNS UPDATE March 1996
1 - Definitions
This document intentionally gives more definition to the roles of
``Master,'' ``Slave,'' and ``Primary Master'' servers, and their
enumeration in NS RRs, and the SOA MNAME field. In that sense, the
following server type definitions can be considered an addendum to
[RFC1035], and are intended to be consistent with [NOTIFY]:
Slave an authoritative server that uses AXFR or IXFR to
retrieve the zone and is named in the zone's NS
RRset.
Master an authoritative server configured to be the source
of AXFR or IXFR data for one or more slave servers.
Primary Master master server at the root of the AXFR/IXFR dependency
graph. The primary master is named in the zone's SOA
MNAME field and optionally by an NS RR. There is by
definition only one primary master server per zone.
A domain name identifies a node within the domain name space tree
structure. Each node has a set (possibly empty) of Resource Records
(RRs). All RRs having the same NAME, CLASS and TYPE are called a
Resource Record Set (RRset).
The pseudocode used in this document is for example purposes only. If
it is found to disagree with the text, the text shall be considered
authoritative. If the text is found to be ambiguous, the pseudocode can
be used to help resolve the ambiguity.
1.1 - Comparison Rules
1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE, RDLENGTH
and RDATA fields are equal. Note that the time-to-live (TTL) field is
explicitly excluded from the comparison.
1.1.2. The rules for comparison of character strings in names are
specified in [RFC1035 2.3.3].
1.1.3. Wildcarding is disabled. That is, a wildcard (``*'') in an
update only matches a wildcard (``*'') in the zone, and vice versa.
1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in the
update, and will not otherwise be followed. All UPDATE operations are
done on the basis of canonical names.
Expires October 1996 [Page 2]
INTERNET-DRAFT DNS UPDATE March 1996
1.1.5. The following RR types cannot be appended to an RRset. If the
following comparison rules are met, then an attempt to add the new RR
will result in the replacement of the previous RR:
SOA compare only NAME, CLASS and TYPE -- it is not possible to
have more than one SOA per zone, even if any of the data
fields differ.
WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL -- only
one WKS RR is possible for this tuple, even if the services
masks differ.
CNAME compare only NAME, CLASS, and TYPE -- it is not possible to
have more than one CNAME RR, even if their data fields differ.
1.2 - Glue RRs
For the purpose of determining whether a domain name used in the UPDATE
protocol is contained within a specified zone, a domain name is ``in'' a
zone if it is owned by that zone's domain name. See section 7.19 for
details.
1.3 - New Assigned Numbers
CLASS = NONE (TBD: 254)
RCODE = YXDOMAIN (TBD: 6)
RCODE = YXRRSET (TBD: 7)
RCODE = NXRRSET (TBD: 8)
RCODE = NOTAUTH (TBD: 9)
RCODE = NOTZONE (TBD: 10?)
Opcode = UPDATE (5)
2 - Update Message Format
The DNS Message Format is defined by [RFC1035 4.1]. Some extensions are
necessary (for example, more error codes are possible under UPDATE than
under QUERY) and some fields must be overloaded (see description of
CLASS fields below).
The overall format of an UPDATE message is, following [ibid]:
Expires October 1996 [Page 3]
INTERNET-DRAFT DNS UPDATE March 1996
+---------------------+
| Header |
+---------------------+
| Zone | specifies the zone to be updated
+---------------------+
| Prerequisite | RRs or RRsets which must (not) preexist
+---------------------+
| Update | RRs or RRsets to be added or deleted
+---------------------+
| Additional Data | additional data
+---------------------+
The Header Section specifies that this message is an UPDATE, and
describes the size of the other sections. The Zone Section names the
zone that is to be updated by this message. The Prerequisite Section
specifies the starting invariants (in terms of zone content) required
for this update. The Update Section contains the edits to be made, and
the Additional Data Section contains data which may be necessary to
complete, but is not part of, this update.
2.1 - Transport Issues
An update transaction may be carried in a UDP datagram, if the request
fits, or in a TCP connection (at the discretion of the requestor). When
TCP is used, the message is in the format described in [RFC1035 4.2.2].
2.2 - Message Header
The header of the DNS Message Format is defined by [RFC 1035 4.1]. Not
all opcodes define the same set of flag bits, though as a practical
matter most of the bits defined for QUERY (in [ibid]) are identically
defined by the other opcodes. UPDATE uses only one flag bit (QR).
The DNS Message Format specifies record counts for its four sections
(Question, Answer, Authority, and Additional). UPDATE uses the same
fields, and the same section formats, but the naming and use of these
sections differs as shown in the following modified header, after
[RFC1035 4.1.1]:
Expires October 1996 [Page 4]
INTERNET-DRAFT DNS UPDATE March 1996
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode | Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
These fields are used as follows:
ID A 16-bit identifier assigned by the entity that generates any
kind of request. This identifier is copied in the
corresponding reply and can be used by the requestor to match
replies to outstanding requests, or by the server to detect
duplicated requests from some requestor.
QR A one bit field that specifies whether this message is a
request (0), or a response (1).
Opcode A four bit field that specifies the kind of request in this
message. This value is set by the originator of a request
and copied into the response. The Opcode value that
identifies an UPDATE message is five (5).
Z Reserved for future use. Should be zero (0) in all requests
and responses. A non-zero Z field should be ignored by
implementations of this specification.
Expires October 1996 [Page 5]
INTERNET-DRAFT DNS UPDATE March 1996
RCODE Response code - this four bit field is undefined in requests
and set in responses. The values and meanings of this field
within responses are as follows:
Mneumonic Value Description
------------------------------------------------------------
NOERROR 0 No error condition.
FORMERR 1 The name server was unable to interpret
the request due to a format error.
SERVFAIL 2 The name server encountered an internal
failure while processing this request,
for example an operating system error
or a forwarding timeout.
NXDOMAIN 3 Some name that ought to exist,
does not exist.
NOTIMP 4 The name server does not support
the specified Opcode.
REFUSED 5 The name server refuses to perform the
specified operation for policy or
security reasons.
YXDOMAIN 6? Some name that ought not to exist,
does exist.
YXRRSET 7? Some RRset that ought not to exist,
does exist.
NXRRSET 8? Some RRset that ought to exist,
does not exist.
NOTAUTH 9? The server is not authoritative for
the zone named in the Zone Section.
NOTZONE 10? A name used in the Prerequisite or
Update Section is not within the
zone denoted by the Zone Section.
ZOCOUNT The number of RRs in the Zone Section.
PRCOUNT The number of RRs in the Prerequisite Section.
UPCOUNT The number of RRs in the Update Section.
ADCOUNT The number of RRs in the Additional Data Section.
Expires October 1996 [Page 6]
INTERNET-DRAFT DNS UPDATE March 1996
2.3 - Zone Section
The Zone Section has the same format as that specified in [RFC1035
4.1.2], with the fields redefined as follows:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ ZNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
UPDATE uses this section to denote the zone of the records being
updated. All records to be updated must be in the same zone, and
therefore the Zone Section is allowed to contain exactly one record.
The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is the
zone's class.
2.4 - Prerequisite Section
This section contains a set of RRset prerequisites which must be
satisfied at the time the UPDATE packet is received by the primary
master server. The format of this section is as specified by [RFC1035
4.1.3]. There are five possible sets of semantics that can be expressed
here, summarized as follows and then explained below.
(1) RRset exists (value independent). At least one RR with a
specified NAME and TYPE (in the zone and class specified by the
Zone Section) must exist.
(2) RRset exists (value dependent). A set of RRs with a specified
NAME and TYPE exists and has the same members with the same
RDATAs as the RRset specified here in this Section.
(3) RRset does not exist. No RRs with a specified NAME and TYPE (in
the zone and class denoted by the Zone Section) can exist.
Expires October 1996 [Page 7]
INTERNET-DRAFT DNS UPDATE March 1996
(4) Name is in use. At least one RR with a specified NAME (in the
zone and class specified by the Zone Section) must exist. Note
that this prerequisite is NOT satisfied by empty nonterminals.
(5) Name is not in use. No RR of any type is owned by a specified
NAME. Note that this prerequisite IS satisfied by empty
nonterminals.
The syntax of these is as follows:
2.4.1 - RRset Exists (Value Independent)
At least one RR with a specified NAME and TYPE (in the zone and class
specified in the Zone Section) must exist.
For this prerequisite, a requestor adds to the section a single RR whose
NAME and TYPE are equal to that of the zone RRset whose existence is
required. RDLENGTH is zero and RDATA is therefore empty. CLASS must be
specified as ANY to differentiate this condition from that of an actual
RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TTL is specified
as zero (0).
2.4.2 - RRset Exists (Value Dependent)
A set of RRs with a specified NAME and TYPE exists and has the same
members with the same RDATAs as the RRset specified here in this
section. While RRset ordering is undefined and therefore not
significant to this comparison, the sets be identical in their extent.
For this prerequisite, a requestor adds to the section an entire RRset
whose preexistence is required. NAME and TYPE are that of the RRset
being denoted. CLASS is that of the zone. TTL must be specified as
zero (0) and is ignored when comparing RRsets for identity.
2.4.3 - RRset Does Not Exist
No RRs with a specified NAME and TYPE (in the zone and class denoted by
the Zone Section) can exist.
For this prerequisite, a requestor adds to the section a single RR whose
NAME and TYPE are equal to that of the RRset whose nonexistence is
required. The RDLENGTH of this record is zero (0), and RDATA field is
therefore empty. CLASS must be specified as NONE in order to
distinguish this condition from a valid RR whose RDLENGTH is naturally
zero (0) (for example, the NULL RR). TTL must be specified as zero (0).
Expires October 1996 [Page 8]
INTERNET-DRAFT DNS UPDATE March 1996
2.4.4 - Name Is In Use
Name is in use. At least one RR with a specified NAME (in the zone and
class specified by the Zone Section) must exist. Note that this
prerequisite is NOT satisfied by empty nonterminals.
For this prerequisite, a requestor adds to the section a single RR whose
NAME is equal to that of the name whose ownership of an RR is required.
RDLENGTH is zero and RDATA is therefore empty. CLASS must be specified
as ANY to differentiate this condition from that of an actual RR whose
RDLENGTH is naturally zero (0) (e.g., NULL). TYPE must be specified as
ANY to differentiate this case from that of an RRset existence test.
TTL is specified as zero (0).
2.4.5 - Name Is Not In Use
Name is not in use. No RR of any type is owned by a specified NAME.
Note that this prerequisite IS satisfied by empty nonterminals.
For this prerequisite, a requestor adds to the section a single RR whose
NAME is equal to that of the name whose nonownership of any RRs is
required. RDLENGTH is zero and RDATA is therefore empty. CLASS must be
specified as NONE. TYPE must be specified as ANY. TTL must be
specified as zero (0).
2.5 - Update Section
This section contains RRs to be added to or deleted from the zone. The
format of this section is as specified by [RFC1035 4.1.3]. There are
four possible sets of semantics, summarized below and with details to
follow.
(1) Add RRs to an RRset.
(2) Delete an RRset.
(3) Delete all RRsets from a name.
(4) Delete an RR from an RRset.
The syntax of these is as follows:
2.5.1 - Add To An RRset
RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH and
RDATA are those being added, and CLASS is the same as the zone class.
Any duplicate RRs will be silently ignored by the primary master.
Expires October 1996 [Page 9]
INTERNET-DRAFT DNS UPDATE March 1996
2.5.2 - Delete An RRset
One RR is added to the Update Section whose NAME and TYPE are those of
the RRset to be deleted. TTL must be specified as zero (0) and is
otherwise not used by the primary master. CLASS must be specified as
ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty. If
no such RRset exists, then this Update RR will be silently ignored by
the primary master.
2.5.3 - Delete All RRsets From A Name
One RR is added to the Update Section whose NAME is that of the name to
be cleansed of RRsets. TYPE must be specified as ANY. TTL must be
specified as zero (0) and is otherwise not used by the primary master.
CLASS must be specified as ANY. RDLENGTH must be zero (0) and RDATA
must therefore be empty. If no such RRsets exist, then this Update RR
will be silently ignored by the primary master.
2.5.4 - Delete An RR From An RRset
RRs to be deleted are added to the Update Section. The NAME, TYPE,
RDLENGTH and RDATA must match the RR being deleted. TTL must be
specified as zero (0) and will otherwise be ignored by the primary
master. CLASS must be specified as NONE to distinguish this from an RR
addition. If no such RRs exist, then this Update RR will be silently
ignored by the primary master.
2.6 - Additional Data Section
This section contains RRs which are related to the update itself, or to
new RRs being added by the update. For example, out of zone glue (A RRs
referred to by new NS RRs) should be presented here. The server can use
or ignore out of zone glue, at the discretion of the server implementor.
The format of this section is as specified by [RFC1035 4.1.3].
Expires October 1996 [Page 10]
INTERNET-DRAFT DNS UPDATE March 1996
3 - Server Behavior
A server, upon receiving an UPDATE request, will signal NOTIMP to the
requestor if the UPDATE opcode is not recognized or if it is recognized
but has not been implemented. Otherwise, processing continues as
follows.
3.1 - Process Zone Section
3.1.1. The Zone Section is checked to see that there is exactly one RR
therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
requestor. Next, the ZNAME and ZCLASS are checked to see if the zone so
named is one of this server's authority zones, else signal NOTAUTH to
the requestor. If the server is a zone slave, the request will be
forwarded toward the primary master.
3.1.2 - Pseudocode For Zone Section Processing
if (zcount != 1 || ztype != SOA)
return (FORMERR)
if (zone_type(zname, zclass) == SLAVE)
return forward()
if (zone_type(zname, zclass) == MASTER)
return update()
return (NOTAUTH)
Sections 3.2 through 3.8 describe the primary master's behaviour,
whereas Section 6 describes a forwarder's behaviour.
3.2 - Process Prerequisite Section
Next, the Prerequisite Section is checked to see that all prerequisites
are satisfied by the current state of the zone. Using the definitions
expressed in Section 1.2, if any RR's NAME is not within the zone
specified in the Zone Section, signal NOTZONE to the requestor.
3.2.1. For RRs in this section whose CLASS is ANY, test to see that TTL
and RDLENGTH are both zero (0), else signal FORMERR to the requestor.
If TYPE is ANY, test to see that there is at least one RR in the zone
whose NAME is the same as that of the Prerequisite RR, else signal
NXDOMAIN to the requestor. If TYPE is not ANY, test to see that there
is at least one RR in the zone whose NAME and TYPE are the same as that
of the Prerequisite RR, else signal NXRRSET to the requestor.
Expires October 1996 [Page 11]
INTERNET-DRAFT DNS UPDATE March 1996
3.2.2. For RRs in this section whose CLASS is NONE, test to see that the
TTL and RDLENGTH are both zero (0), else signal FORMERR to the
requestor. If the TYPE is ANY, test to see that there are no RRs in the
zone whose NAME is the same as that of the Prerequisite RR, else signal
YXDOMAIN to the requestor. If the TYPE is not ANY, test to see that
there are no RRs in the zone whose NAME and TYPE are the same as that of
the Prerequisite RR, else signal YXRRSET to the requestor.
3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
test to see that the TTL is zero (0), else signal FORMERR to the
requestor. Then, build an RRset for each unique <NAME,TYPE> and compare
each resulting RRset for set equality (same members, no more, no less)
with RRsets in the zone. If any Prerequisite RRset is not entirely and
exactly matched by a zone RRset, signal NXRRSET to the requestor. If
any RR in this section has a CLASS other than ZCLASS or NONE or ANY,
signal FORMERR to the requestor.
3.2.4 - Table Of Metavalues Used In Prerequisite Section
CLASS TYPE RDATA Meaning
------------------------------------------------------------
ANY ANY empty Name is in use
ANY rrset empty RRset exists (value independent)
NONE ANY empty Name is not in use
NONE rrset empty RRset does not exist
zone rrset rr RRset exists (value dependent)
Expires October 1996 [Page 12]
INTERNET-DRAFT DNS UPDATE March 1996
3.2.5 - Pseudocode for Prerequisite Section Processing
for rr in prerequisites
if (rr.ttl != 0)
return (FORMERR)
if (zone_of(rr.name) != ZNAME)
return (NOTZONE);
if (rr.class == ANY)
if (rr.rdlength != 0)
return (FORMERR)
if (rr.type == ANY)
if (!zone_name<rr.name>)
return (NXDOMAIN)
else
if (!zone_rrset<rr.name, rr.type>)
return (NXRRSET)
if (rr.class == NONE)
if (rr.rdlength != 0)
return (FORMERR)
if (rr.type == ANY)
if (zone_name<rr.name>)
return (YXDOMAIN)
else
if (zone_rrset<rr.name, rr.type>)
return (YXRRSET)
if (rr.class == zclass)
temp<rr.name, rr.type> += rr
else
return (FORMERR)
for rrset in temp
if (zone_rrset<rrset.name, rrset.type> != rrset)
return (NXDOMAIN)
3.3 - Check Requestor's Permissions
3.3.1. Next, the requestor's permission to update the RRs named in the
Update Section may be tested in an implementation dependent fashion or
using mechanisms specified in a subsequent Secure DNS Update protocol.
If the requestor does not have permission to perform these updates, the
server may write a warning message in its operations log, and may either
signal REFUSED to the requestor, or ignore the permission problem and
proceed with the update.
Expires October 1996 [Page 13]
INTERNET-DRAFT DNS UPDATE March 1996
3.3.2. While the exact processing is implementation defined, if these
verification activities are to be performed, this is the point in the
server's processing where such performance should take place, since if a
REFUSED condition is encountered after an update has been partially
applied, it will be necessary to undo the partial update and restore the
zone to its original state before answering the requestor.
3.3.3 - Pseudocode for Permission Checking
if (security policy exists)
if (this update is not permitted)
if (local option)
log a message about permission problem
if (local option)
return (REFUSED)
3.4 - Process Update Section
Next, the Update Section is processed as follows.
3.4.1 - Prescan
The Update Section is parsed into RRs and each RR's CLASS is checked to
see if it is ANY, NONE, or the same as the Zone Class, else signal a
FORMERR to the requestor. Using the definitions in Section 1.2, each
RR's NAME must be in the zone specified by the Zone Section, else signal
NOTZONE to the requestor.
3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
unrecognized type, then signal FORMERR to the requestor. For RRs whose
CLASS is ANY or NONE, check the TTL to see that it is zero (0), else
signal a FORMERR to the requestor. For any RR whose CLASS is ANY, check
the RDLENGTH to make sure that it is zero (0) (that is, the RDATA field
is empty), and that the TYPE is not AXFR, MAILA, MAILB, or any other
QUERY metatype besides ANY, or any unrecognized type, else signal
FORMERR to the requestor.
Expires October 1996 [Page 14]
INTERNET-DRAFT DNS UPDATE March 1996
3.4.1.3 - Pseudocode For Update Section Prescan
[rr] for rr in updates
if (zone_of(rr.name) != ZNAME)
return (NOTZONE);
if (rr.class == zclass)
if (rr.type & ANY|AXFR|MAILA|MAILB)
return (FORMERR)
elsif (rr.class == ANY)
if (rr.ttl != 0 || rr.rdlength != 0
|| rr.type & AXFR|MAILA|MAILB)
return (FORMERR)
elsif (rr.class == NONE)
if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
return (FORMERR)
else
return (FORMERR)
3.4.2 - Update
The Update Section is parsed into RRs and these RRs are processed in
order.
3.4.2.1. If any system failure (such as an out of memory condition, or a
hardware error in persistent storage) occurs during the processing of
this section, signal SERVFAIL to the requestor and undo all updates
applied to the zone during this transaction.
3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to the
zone. In case of duplicate RDATAs (which for SOA RRs is always the
case, and for WKS RRs is the case if the ADDRESS and PROTOCOL fields
both match), the Zone RR is replaced by Update RR. If the TYPE is SOA
and there is no Zone SOA RR, or the new SOA.SERIAL is lower (according
to [KRE1996]) than the current Zone SOA RR's SOA.SERIAL, the Update RR
is ignored. In the case of a CNAME Update RR and a non-CNAME Zone RRset
or vice versa, ignore the CNAME Update RR, otherwise replace the CNAME
Zone RR with the CNAME Update RR.
Expires October 1996 [Page 15]
INTERNET-DRAFT DNS UPDATE March 1996
3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY, all
Zone RRs with the same NAME are deleted, unless the NAME is the same as
ZNAME in which case only those RRs whose TYPE is other than SOA or NS
are deleted. For any Update RR whose CLASS is ANY and whose TYPE is not
ANY all Zone RRs with the same NAME and TYPE are deleted, unless the
NAME is the same as ZNAME in which case neither SOA or NS RRs will be
deleted.
3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose NAME,
TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted, unless
the NAME is the same as ZNAME and either the TYPE is SOA or the TYPE is
NS and the matching Zone RR is the only NS remaining in the RRset, in
which case this Update RR is ignored.
3.4.2.5. Signal NOERROR to the requestor.
3.4.2.6 - Table Of Metavalues Used In Update Section
CLASS TYPE RDATA Meaning
---------------------------------------------------------
ANY ANY empty Delete all RRsets from a name
ANY rrset empty Delete an RRset
NONE rrset rr Delete an RR from an RRset
zone rrset rr Add to an RRset
Expires October 1996 [Page 16]
INTERNET-DRAFT DNS UPDATE March 1996
3.4.2.7 - Pseudocode For Update Section Processing
[rr] for rr in updates
if (rr.class == zclass)
if (rr.type == CNAME)
if (zone_rrset<rr.name, ~CNAME>)
next [rr]
elsif (zone_rrset<rr.name, CNAME>)
next [rr]
if (rr.type == SOA)
if (!zone_rrset<rr.name, SOA> ||
zone_rr<rr.name, SOA>.serial > rr.soa.serial)
next [rr]
for zrr in zone_rrset<rr.name, rr.type>
if (rr.type == CNAME || rr.type == SOA ||
(rr.type == WKS && rr.proto == zrr.proto &&
rr.address == zrr.address) ||
rr.rdata == zrr.rdata)
zrr = rr
next [rr]
zone_rrset<rr.name, rr.type> += rr
elsif (rr.class == ANY)
if (rr.type == ANY)
if (rr.name == zname)
zone_rrset<rr.name, ~(SOA|NS)> = Nil
else
zone_rrset<rr.name, *> = Nil
elsif (rr.name == zname &&
(rr.type == SOA || rr.type == NS))
next [rr]
else
zone_rrset<rr.name, rr.type> = Nil
elsif (rr.class == NONE)
if (rr.type == SOA)
next [rr]
if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
next [rr]
zone_rr<rr.name, rr.type, rr.data> = Nil
return (NOERROR)
Expires October 1996 [Page 17]
INTERNET-DRAFT DNS UPDATE March 1996
3.5 - Stability
When a zone is modified by an UPDATE operation, the server must commit
the change to nonvolatile storage before sending a response to the
requestor or answering any queries or transfers for the modified zone.
It is reasonable for a server to store only the update records as long
as a system reboot or power failure will cause these update records to
be incorporated into the zone the next time the server is started. It
is also reasonable for the server to copy the entire modified zone to
nonvolatile storage after each update operation, though this would have
suboptimal performance for large zones.
3.6 - Zone Identity
If the zone's SOA SERIAL is changed by an update operation, that change
must be in a positive direction (using modulo 2**32 arithmetic as
specified by [KRE1996]). Attempts to replace an SOA with one whose
SERIAL is less than the current one will be silently ignored by the
primary master server.
If the zone's SOA's SERIAL is not changed as a result of an update
operation, then the server shall increment it automatically before the
SOA or any changed name or RR or RRset is included in any response or
transfer. The primary master server's implementor might choose to
autoincrement the SOA SERIAL if any of the following events occurs:
(1) Each update operation.
(2) A name, RR or RRset in the zone has changed and has subsequently
been visible to a DNS client since the unincremented SOA was
visible to a DNS client, and the SOA is about to become visible to
a DNS client.
(3) A configurable period of time has elapsed since the last update
operation. This period shall be less than or equal to one third of
the zone refresh time, and the default shall be the lesser of that
maximum and 300 seconds.
(4) A configurable number of updates has been applied since the last
SOA change. The default value for this configuration parameter
shall be one hundred (100).
It is imperative that the zone's contents and the SOA's SERIAL be
tightly synchronized. If the zone appears to change, the SOA must
appear to change as well.
Expires October 1996 [Page 18]
INTERNET-DRAFT DNS UPDATE March 1996
3.7 - Atomicity
During the processing of an UPDATE transaction, the server must ensure
atomicity with respect to other (concurrent) UPDATE or QUERY
transactions. No two transactions can be processed concurrently if
either depends on the final results of the other; in particular, a QUERY
should not be able to retrieve RRsets which have been partially modified
by a concurrent UPDATE, and an UPDATE should not be able to start from
prerequisites that might not still hold at the completion of some other
concurrent UPDATE. Finally, if two UPDATE transactions would modify the
same names, RRs or RRsets, then such UPDATE transactions must be
serialized.
3.8 - Response
At the end of UPDATE processing, a response code will be known. A
response message is generated by copying the ID and Opcode fields from
the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT, and
ADCOUNT fields and associated sections, or placing zeros (0) in the
these ``count'' fields and not including any part of the original
update. The QR bit is set to one (1), and the response is sent back to
the requestor. If the requestor used UDP, then the response will be
sent to the requestor's source UDP port. If the requestor used TCP,
then the response will be sent back on the requestor's open TCP
connection.
4 - Requestor Behaviour
4.1. From a requestor's point of view, any authoritative server for the
zone can appear to be able to process update requests, even though only
the primary master server is actually able to modify the zone's master
file. Requestors are expected to know the name of the zone they intend
to update and to know or be able to determine the name servers for that
zone.
4.2. If update ordering is desired, the requestor will need to know the
value of the existing SOA RR. Requestors who update the SOA RR must
update the SOA SERIAL field in a positive direction (as defined by
[KRE1996]) and to preserve the other SOA fields unless the requestor's
explicit intent is to change them. The SOA SERIAL field must never be
set to zero (0).
Expires October 1996 [Page 19]
INTERNET-DRAFT DNS UPDATE March 1996
4.3. If the requestor has reasonable cause to believe that all of a
zone's servers will be equally reachable, then it should arrange to try
the primary master server (as given by the SOA MNAME field if matched by
some NS NSDNAME) first to avoid unnecessary forwarding inside the slave
servers. (Note that the primary master will in some cases not be
reachable by all requestors, due to firewalls or network partitioning.)
4.4. Once the zone's name servers been found and possibly sorted so that
the ones more likely to be reachable and/or support the UPDATE opcode
are listed first, the requestor composes an UPDATE message of the
following form and sends it to the first name server on its list:
ID: (new)
Opcode: UPDATE
Zone zcount: 1
Zone zname: (zone name)
Zone zclass: (zone class)
Zone ztype: T_SOA
Prerequisite Section: (see previous text)
Update Section: (see previous text)
Additional Data Section: (empty)
4.5. If the requestor receives a response, and the response has an RCODE
other than SERVFAIL or NOTIMP, then the requestor returns an appropriate
response to its caller.
4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or if
no response is received within an implementation dependent timeout
period, or if an ICMP error is received indicating that the server's
port is unreachable, then the requestor will delete the unusable server
from its internal name server list and try the next one, repeating until
the name server list is empty. If the requestor runs out of servers to
try, an appropriate error will be returned to the requestor's caller.
5 - Duplicate Detection, Ordering and Mutual Exclusion
5.1. For correct operation, mechanisms may be needed to ensure
idempotence, order UPDATE requests and provide mutual exclusion. An
UPDATE message or response might be delivered zero times, one time, or
multiple times. Datagram duplication is of particular interest since it
covers the case of the so-called ``replay attack'' where a correct
request is duplicated maliciously by an intruder.
Expires October 1996 [Page 20]
INTERNET-DRAFT DNS UPDATE March 1996
5.2. Multiple UPDATE requests or responses in transit might be delivered
in any order, due to network topology changes or load balancing, or to
multipath forwarding graphs wherein several slave servers all forward to
the primary master. In some cases, it might be required that the
earlier update not be applied after the later update, where ``earlier''
and ``later'' are defined by an external time base visible to some set
of requestors, rather than by the order of request receipt at the
primary master.
5.3. A requestor can ensure transaction idempotence by explicitly
deleting some ``marker RR'' (rather than deleting the RRset of which it
is a part) and then adding a new ``marker RR'' with a different RDATA
field. The Prerequisite Section should specify that the original
``marker RR'' must be present in order for this UPDATE message to be
accepted by the server.
5.4. If the request is duplicated by a network error, all duplicate
requests will fail since only the first will find the original ``marker
RR'' present and having its known previous value. The decisions of
whether to use such a ``marker RR'' and what RR to use are left up to
the application programmer, though one obvious choice is the zone's SOA
RR as described below.
5.5. Requestors can ensure update ordering by externally synchronizing
their use of successive values of the ``marker RR.'' Mutual exclusion
can be addressed as a degenerate case, in that a single succession of
the ``marker RR'' is all that is needed.
5.6. A special case where update ordering and datagram duplication
intersect is when an RR validly changes to some new value and then back
to its previous value. Without a ``marker RR'' as described above, this
sequence of updates can leave the zone in an undefined state if
datagrams are duplicated.
5.7. To achieve an atomic multitransaction ``read-modify-write'' cycle,
a requestor could first retrieve the SOA RR, and build an UPDATE message
one of whose prerequisites was the old SOA RR. It would then specify
updates that would delete this SOA RR and add a new one with an
incremented SOA SERIAL, along with whatever actual prerequisites and
updates were the object of the transaction. If the transaction
succeeds, the requestor knows that the RRs being changed were not
otherwise altered by any other requestor.
Expires October 1996 [Page 21]
INTERNET-DRAFT DNS UPDATE March 1996
6 - Forwarding
When a zone slave forwards an UPDATE message upward toward the zone's
primary master server, it must allocate a new ID and prepare to enter
the role of ``forwarding server,'' which is a requestor with respect to
the forward server.
6.1. The set of forward servers will be same as the set of servers this
zone slave would use as the source of AXFR or IXFR data. So, while the
original requestor might have used the zone's NS RRset to locate its
update server, a forwarder always forwards toward its designated zone
master servers.
6.2. If the original requestor used TCP, then the TCP connection from
the requestor is still open and the forwarder must use TCP to forward
the message. If the original requestor used UDP, the forwarder may use
either UDP or TCP to forward the message, at the whim of the
implementor.
6.3. It is reasonable for forward servers to be forwarders themselves,
if the AXFR dependency graph being followed is a deep one involving
firewalls and multiple connectivity realms. In most cases the AXFR
dependency graph will be shallow and the forward server will be the
primary master server.
6.4. The forwarder will not respond to its requestor until it receives a
response from its forward server. UPDATE transactions involving
forwarders are therefore time synchronized with respect to the original
requestor and the primary master server.
6.5. When there are multiple possible sources of AXFR data and therefore
multiple possible forward servers, a forwarder will use the same
fallback strategy with respect to connectivity or timeout errors that it
would use when performing an AXFR. This is implementation dependent.
6.6. When a forwarder receives a response from a forward server, it
copies this response into a new response message, assigns its
requestor's ID to that message, and sends the response back to the
requestor.
Expires October 1996 [Page 22]
INTERNET-DRAFT DNS UPDATE March 1996
7 - Design, Implementation, Operation, and Protocol Notes
Some of the principles which guided the design of this UPDATE
specification are as follows. Note that these are not part of the
formal specification and any disagreement between this section and any
other section of this document should be resolved in favour of the other
section.
7.1. Using metavalues for CLASS is possible only because all RRs in the
packet are assumed to be in the same zone, and CLASS is an attribute of
a zone rather than of an RRset. (It is for this reason that the Zone
Section is not optional.)
7.2. Since there are no data-present or data-absent errors possible from
processing the Update Section, it is necessary to state data-present and
data-absent dependencies in the Prerequisite Section.
7.3. The Additional Data Section can be used to supply a server with out
of zone glue that will be needed in referrals. For example, if adding a
new NS RR to HOME.VIX.COM specifying a nameserver called NS.AU.OZ, the A
RR for NS.AU.OZ can be included in the Additional Data Section. Servers
can use this information or ignore it, at the discretion of the
implementor.
7.4. The Additional Data Section might be used if some of the RRs later
needed for Secure DNS Update are not actually zone updates, but rather
ancillary keys or signatures not intended to be stored in the zone (as
an update would be), yet necessary for validating the update operation.
7.5. It is expected that in the absence of Secure DNS Update, a server
will only accept updates if they come from a source address that has
been statically configured in the server's description of a primary
master zone. DHCP servers would be likely candidates for inclusion in
this statically configured list.
7.6. It is not possible to create a zone using this protocol, since
there is no provision for a slave server to be told who its master
servers are. It is expected that this protocol will be extended in the
future to cover this case. Therefore, at this time, the addition of SOA
RRs is unsupported. For similar reasons, deletion of SOA RRs is also
unsupported.
Expires October 1996 [Page 23]
INTERNET-DRAFT DNS UPDATE March 1996
7.7. The prerequisite for specifying that a name own at least one RR
differs semantically from QUERY, in that QUERY would return
<NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at this
name, while UPDATE's prerequisite condition [Section 2.4.4] would NOT be
satisfied.
7.8. It is possible for a UDP response to be lost in transit and for a
request to be retried due to a timeout condition. In this case an
UPDATE that was successful the first time it was received by the primary
master might ultimately appear to have failed when the response to a
duplicate request is finally received by the requestor. (This is
because the original prerequisites may no longer be satisfied after the
update has been applied.) For this reason, requestors who require an
accurate response code must use TCP.
7.9. Because a requestor who requires an accurate response code will
initiate their UPDATE transaction using TCP, a forwarder who receives a
request via TCP must forward it using TCP.
7.10. Deferral of SOA SERIAL autoincrements is made possible so that
serial numbers can be conserved and wraparound at 2**32 can be made an
infrequent occurance. Visible (to DNS clients) SOA SERIALs need to
differ if the zone differs. Note that the Authority Section SOA in a
QUERY response is a form of visibility, for the purposes of this
prerequisite.
7.11. A zone's SOA SERIAL should never be set to zero (0) due to
interoperability problems with some older but widely installed
implementations of DNS. When incrementing an SOA SERIAL, if the result
of the increment is zero (0) (as will be true when wrapping around
2**32), it is necessary to increment it again or set it to one (1). See
[KRE1996] for more detail on this subject.
7.12. Due to the TTL minimalization necessary when caching an RRset, it
is recommended that all TTLs in an RRset be set to the same value.
While the DNS Message Format permits variant TTLs to exist in the same
RRset, and this variance can exist inside a zone, such variance will
have counterintuitive results and its use is discouraged.
Expires October 1996 [Page 24]
INTERNET-DRAFT DNS UPDATE March 1996
7.13. Zone cut management presents some obscure corner cases to the add
and delete operations in the Update Section. It is possible to delete
an NS RR as long as it's not the last RR in the RRset. If deleting all
RRs from a name, SOA and NS RRs at the top of a zone are unaffected. If
deleting RRsets, it is not possible to delete either SOA or NS RRsets at
the top of a zone. An attempt to add an SOA will be treated as a
replace operation.
7.14. No semantic checking is required in the primary master server when
adding new RRs. Therefore a requestor can cause CNAME or NS or any
other kind of RR to be added even if their target name does not exist or
does not have the proper RRsets to make the original RR useful. Primary
master servers which implement this kind of checking should take great
care to avoid out-of-zone dependencies (whose veracity cannot be
authoritatively checked) or signals to the requestor during processing
of the Update Section after the prescan.
7.15. Nonterminal or wildcard CNAMEs are not well specified by RFC 1035
and their use will probably lead to unpredictable results. Their use is
discouraged.
7.16. Before adding a delegation to a zone, all RRsets at or below the
new zone cut should be removed, except for ``glue'' which are A RRs
below the zone cut which are targets of NS RRs at the zone cut.
7.17. A primary server implementation may choose to perform part of its
permission checking during the Update Section processing. This may be
needed if the permissions won't be known until the final form of an
RRset is known. In this case, a primary server can signal REFUSED to
the requestor as long as it also undoes all partial updates and restores
the zone to its original state.
7.18. In a deep AXFR dependency graph, it has not historically been an
error for slaves to depend mutually upon each other. This configuration
has been used to enable a zone to flow from the primary master to all
slaves even though not all slaves have continuous connectivity to the
primary master. UPDATE's use of the AXFR dependency graph for
forwarding prohibits this kind of dependency loop, since UPDATE
forwarding has no loop detection analagous to the SOA SERIAL pretest
used by AXFR.
7.19. For UPDATE's purposes, a zone is said to own all names at or below
the zone's root. This allows an UPDATE message to add or delete names
below a zone cut so as to create and maintain ``glue'' records needed
for delegation when a name server is within the zone being delegated.
Expires October 1996 [Page 25]
INTERNET-DRAFT DNS UPDATE March 1996
7.20. Previously existing names which are occluded by a new zone cut are
still considered part of the parent zone, for the purposes of zone
transfers, even though queries for such names will be referred to the
new subzone's servers. If a zone cut is removed, all parent zone names
that were occluded by it will again become visible to queries. (This is
a clarification of RFC 1034.)
7.21. If a node contains any name server delegations (NS RRs), this node
is said to be owned by the child zone, and the parent will answer only
with a nonauthoritative referral to the child zone's servers if queried
for a name at or below the child zone's root, except in the case of an
QTYPE=NS query at the zone cut itself, for which the parent zone's
servers would answer authoritatively. (This is a clarification of RFC
1034.)
7.22. If a server is authoritative for both a zone and its child, then
queries for names at the zone cut between them will be answered
authoritatively using only data from the child zone. (This is a
clarification of RFC 1034.)
7.23. Update ordering using the SOA RR is problematic since there is no
way to know which of a zone's NS RRs represents the primary master, and
the zone slaves can be out of date if their SOA.REFRESH timers have not
elapsed since the last time the zone was changed on the primary master.
We recommend that a zone needing ordered updates use only servers which
implement NOTIFY (see [NOTIFY]) and IXFR (see [IXFR]), and that a client
receiving a prerequisite error while attempting an ordered update simply
retry after a random delay period to allow the zone to settle.
8 - Security Considerations
In the absence of DNS Security, the protocol described by this document
makes it possible for anyone who can reach an authoritative name server
to alter the contents of a zone. This strongly indicates a need for out
of band access control such as static access control lists enforced by
the server combined with the strongest possible firewall techniques.
At the time of this writing, work is progressing (see [DNSSEC]) on the
general problem of DNS Security, and for Secure DNS Updates (see
[SECUPD]). No updates should be accepted from hosts outside an
enterprise network's security perimeter until and unless Secure DNS
Updates have been implemented. For the purpose of this recommendation,
a slave server acting as a forwarder, or the primary master itself, is
outside the security perimeter if it is allowed to exchange DNS messages
with hosts outside that perimeter.
Expires October 1996 [Page 26]
INTERNET-DRAFT DNS UPDATE March 1996
Acknowledgements
We would like to thank the IETF DNSIND working group for their input and
assistance, in particular, Rob Austein, Randy Bush, Donald Eastlake,
Masataka Ohta, Mark Andrews, and Robert Elz. Special thanks to Bill
Simpson and Ken Wallich for reviewing this document.
References
[RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specification,''
RFC 1035, USC/Information Sciences Institute, November 1987.
[IXFR]
M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February
1996, <draft-ietf-dnsind-ixfr-06.txt>.
[NOTIFY]
P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes (DNS
NOTIFY),'' Internet Draft, March 1996, <draft-ietf-dnsind-
notify-07.txt>.
[KRE1996]
R. Elz, ``Serial Number Arithmetic,'' Internet Draft, February 1996,
<draft-ietf-dnsind-serial-00.txt>.
[DNSSEC]
Donald E. Eastlake and Charles W. Kaufman, ``Domain Name System
Protocol Security Extensions,'' Internet Draft, January 1996, <draft-
ietf-dnssec-secext-09.txt>.
[SECUPD]
Donald E. Eastlake, ``Secure Domain Name System Dynamic Update,''
Internet Draft, February 1996, <draft-ietf-dnssec-update-00.txt>
Expires October 1996 [Page 27]
INTERNET-DRAFT DNS UPDATE March 1996
Authors' Addresses
Yakov Rekhter Susan Thomson
Cisco Systems Bellcore
170 West Tasman Drive 445 South Street
San Jose, CA 95134-1706 Morristown, NJ 07960
+1 914 528 0090 +1 201 829 4514
<yakov@cisco.com> <set@thumper.bellcore.com>
Jim Bound Paul Vixie
Digital Equipment Corp. Internet Software Consortium
110 Spitbrook Rd ZK3-3/U14 Star Route Box 159A
Nashua, NH 03062-2698 Woodside, CA 94062
+1 603 881 0400 +1 415 747 0204
<bound@zk3.dec.com> <paul@vix.com>
Expires October 1996 [Page 28]
=========================================================================
Date: Wed, 13 Mar 1996 01:58:31 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: update stuff
X-To: namedroppers@internic.net
I now know that Ohta-san thinks forwarding and prerequisites are unnecessary
(at best) or harmful (at worst). I have decided to press on in spite of this.
I believe I have satisfied every other objection to the current document. It
is again time, with draft 09, to speak now or forever hold your peace.
Or, as my four year old likes to say when we're on a trip, "are we there yet?"
=========================================================================
Date: Wed, 13 Mar 1996 02:02:47 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: diffs from update-08 to update-09 - warning: less readable this
time
X-To: namedroppers@internic.net
*** 1.10 1996/03/08 09:48:22
--- update.ms 1996/03/13 09:53:15
***************
*** 31,37 ****
DNSIND Working Group Paul Vixie (Ed.) (ISC)
INTERNET-DRAFT Susan Thomson (Bellcore)
! <draft-ietf-dnsind-dynDNS-08.txt> Yakov Rekhter (Cisco)
Jim Bound (DEC)
! March 1996
.fi
.sp 2
--- 31,37 ----
DNSIND Working Group Paul Vixie (Ed.) (ISC)
INTERNET-DRAFT Susan Thomson (Bellcore)
! <draft-ietf-dnsind-dynDNS-09.txt> Yakov Rekhter (Cisco)
Jim Bound (DEC)
! Amends: RFC 1035 March 1996
.fi
.sp 2
***************
*** 143,151 ****
.Sh "1.3 - New Assigned Numbers"
.DS
! CLASS = NONE (TBD: 254?)
! RCODE = YXDOMAIN (TBD: 6?)
! RCODE = YXRRSET (TBD: 7?)
! RCODE = NXRRSET (TBD: 8?)
! RCODE = NOTAUTH (TBD: 9?)
RCODE = NOTZONE (TBD: 10?)
Opcode = UPDATE (5)
--- 143,151 ----
.Sh "1.3 - New Assigned Numbers"
.DS
! CLASS = NONE (TBD: 254)
! RCODE = YXDOMAIN (TBD: 6)
! RCODE = YXRRSET (TBD: 7)
! RCODE = NXRRSET (TBD: 8)
! RCODE = NOTAUTH (TBD: 9)
RCODE = NOTZONE (TBD: 10?)
Opcode = UPDATE (5)
***************
*** 174,183 ****
.DE
.LP
! The Header section specifies that this message is an UPDATE, and describes
! the size of the other sections. The Zone section names the zone that is to
! be updated by this message. The Prerequisite section specifies the starting
invariants (in terms of zone content) required for this update. The Update
! section contains the edits to be made, and the Additional Data section has
! no defined use in this specification.
.Sh "2.1 - Transport Issues"
.LP
--- 174,184 ----
.DE
.LP
! The Header Section specifies that this message is an UPDATE, and describes
! the size of the other sections. The Zone Section names the zone that is to
! be updated by this message. The Prerequisite Section specifies the starting
invariants (in terms of zone content) required for this update. The Update
! Section contains the edits to be made, and the Additional Data Section
! contains data which may be necessary to complete, but is not part of, this
! update.
.Sh "2.1 - Transport Issues"
.LP
***************
*** 335,341 ****
.LP
This section contains a set of RRset prerequisites which must be satisfied
! at the time the UPDATE packet is received by the primary master server.
! There are five possible sets of semantics that can be expressed here,
! summarized as follows and then explained below.
.RS
.IP (1) \w'(1)'u+2m
--- 336,343 ----
.LP
This section contains a set of RRset prerequisites which must be satisfied
! at the time the UPDATE packet is received by the primary master server. The
! format of this section is as specified by [RFC1035 4.1.3]. There are five
! possible sets of semantics that can be expressed here, summarized as follows
! and then explained below.
.RS
.IP (1) \w'(1)'u+2m
***************
*** 344,352 ****
.IP (2)
RRset exists (value dependent). A set of RRs with a specified NAME and TYPE
! exists and has the same members with the same RDATA sections as the RRset
! specified here in this Section.
.IP (3)
RRset does not exist. No RRs with a specified NAME and TYPE (in the zone
and class denoted by the Zone Section) can exist.
.IP (4)
Name is in use. At least one RR with a specified NAME (in the zone and class
--- 346,356 ----
.IP (2)
RRset exists (value dependent). A set of RRs with a specified NAME and TYPE
! exists and has the same members with the same RDATAs as the RRset specified
! here in this Section.
.IP (3)
RRset does not exist. No RRs with a specified NAME and TYPE (in the zone
and class denoted by the Zone Section) can exist.
.IP (4)
Name is in use. At least one RR with a specified NAME (in the zone and class
***************
*** 366,378 ****
For this prerequisite, a requestor adds to the section a single RR whose
NAME and TYPE are equal to that of the zone RRset whose existence is
! required. The RDLENGTH is zero and the RDATA section is therefore empty.
! CLASS must be specified as ANY to differentiate this condition from that of
! an actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TTL is
! specified as zero (0).
.Sh "2.4.2 - RRset Exists (Value Dependent)"
.LP
A set of RRs with a specified NAME and TYPE exists and has the same members
! with the same RDATA sections as the RRset specified here in this section.
! While RRset ordering is undefined and therefore not significant to this
comparison, the sets be identical in their extent.
.LP
--- 370,382 ----
For this prerequisite, a requestor adds to the section a single RR whose
NAME and TYPE are equal to that of the zone RRset whose existence is
! required. RDLENGTH is zero and RDATA is therefore empty. CLASS must be
! specified as ANY to differentiate this condition from that of an actual RR
! whose RDLENGTH is naturally zero (0) (e.g., NULL). TTL is specified as zero
! (0).
.Sh "2.4.2 - RRset Exists (Value Dependent)"
.LP
A set of RRs with a specified NAME and TYPE exists and has the same members
! with the same RDATAs as the RRset specified here in this section. While
! RRset ordering is undefined and therefore not significant to this
comparison, the sets be identical in their extent.
.LP
***************
*** 399,408 ****
.LP
For this prerequisite, a requestor adds to the section a single RR whose NAME
! is equal to that of the name whose ownership of an RR is required. The
! RDLENGTH is zero and the RDATA section is therefore empty. CLASS must be
! specified as ANY to differentiate this condition from that of an actual RR
! whose RDLENGTH is naturally zero (0) (e.g., NULL). TYPE must be specified
! as ANY to differentiate this case from that of an RRset existence test. TTL
! is specified as zero (0).
.Sh "2.4.5 - Name Is Not In Use"
.LP
--- 403,412 ----
.LP
For this prerequisite, a requestor adds to the section a single RR whose NAME
! is equal to that of the name whose ownership of an RR is required. RDLENGTH
! is zero and RDATA is therefore empty. CLASS must be specified as ANY to
! differentiate this condition from that of an actual RR whose RDLENGTH is
! naturally zero (0) (e.g., NULL). TYPE must be specified as ANY to
! differentiate this case from that of an RRset existence test. TTL is
! specified as zero (0).
.Sh "2.4.5 - Name Is Not In Use"
.LP
***************
*** 411,423 ****
.LP
For this prerequisite, a requestor adds to the section a single RR whose NAME
! is equal to that of the name whose nonownership of any RRs is required. The
! RDLENGTH is zero and the RDATA section is therefore empty. CLASS must be
! specified as NONE. TYPE must be specified as ANY. TTL must be specified as
! zero (0).
.Sh "2.5 - Update Section"
.LP
This section contains RRs to be added to or deleted from the zone. The
! encoding is similar to that used by the Prerequisite Section. There are
! four possible sets of semantics, summarized below and with details to follow.
.DS
(1) Add RRs to an RRset.
--- 415,426 ----
.LP
For this prerequisite, a requestor adds to the section a single RR whose NAME
! is equal to that of the name whose nonownership of any RRs is required.
! RDLENGTH is zero and RDATA is therefore empty. CLASS must be specified as
! NONE. TYPE must be specified as ANY. TTL must be specified as zero (0).
.Sh "2.5 - Update Section"
.LP
This section contains RRs to be added to or deleted from the zone. The
! format of this section is as specified by [RFC1035 4.1.3]. There are four
! possible sets of semantics, summarized below and with details to follow.
.DS
(1) Add RRs to an RRset.
***************
*** 457,463 ****
.Sh "2.6 - Additional Data Section"
.LP
! This section is reserved for use by future extensions to this protocol. It
! will be ignored by servers, and made empty by requestors which implement
! only the protocol described by this document.
.\"............................................................................
.bp
--- 460,468 ----
.Sh "2.6 - Additional Data Section"
.LP
! This section contains RRs which are related to the update itself, or to new
! RRs being added by the update. For example, out of zone glue (A RRs referred
! to by new NS RRs) should be presented here. The server can use or ignore
! out of zone glue, at the discretion of the server implementor. The format
! of this section is as specified by [RFC1035 4.1.3].
.\"............................................................................
.bp
***************
*** 470,476 ****
.LP
3.1.1. The Zone Section is checked to see that there is exactly one RR
! therein and that the RR's ZTYPE is SOA, else signal FORMERR to requestor.
Next, the ZNAME and ZCLASS are checked to see if the zone so named is one of
! this server's authority zones, else signal NOTAUTH to requestor. If the
server is a zone slave, the request will be forwarded toward the primary
master.
--- 475,481 ----
.LP
3.1.1. The Zone Section is checked to see that there is exactly one RR
! therein and that the RR's ZTYPE is SOA, else signal FORMERR to the requestor.
Next, the ZNAME and ZCLASS are checked to see if the zone so named is one of
! this server's authority zones, else signal NOTAUTH to the requestor. If the
server is a zone slave, the request will be forwarded toward the primary
master.
***************
*** 492,520 ****
satisfied by the current state of the zone. Using the definitions expressed
in Section 1.2, if any RR's NAME is not within the zone specified in the
! Zone Section, signal NOTZONE to requestor.
.LP
3.2.1. For RRs in this section whose CLASS is ANY, test to see that TTL and
! RDLENGTH are both zero (0) else signal FORMERR to requestor. If TYPE is ANY,
! test to see that there is at least one RR in the zone whose NAME is the same
! as that of the Prerequisite RR, else signal NXDOMAIN to the requestor. If
! TYPE is not ANY, test to see that there is at least one RR in the zone whose
! NAME and TYPE are the same as that of the Prerequisite RR, else signal
! NXRRSET to requestor.
.LP
3.2.2. For RRs in this section whose CLASS is NONE, test to see that the TTL
! and RDLENGTH are both zero (0) else signal FORMERR to requestor. If the
TYPE is ANY, test to see that there are no RRs in the zone whose NAME is the
! same as that of the Prerequisite RR, else signal YXDOMAIN to requestor. If
! the TYPE is not ANY, test to see that there are no RRs in the zone whose
NAME and TYPE are the same as that of the Prerequisite RR, else signal
! YXRRSET to requestor.
.LP
3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS, test
! to see that the TTL is zero (0) else signal FORMERR to requestor. Then,
build an RRset for each unique <NAME,TYPE> and compare each resulting RRset
for set equality (same members, no more, no less) with RRsets in the zone.
If any Prerequisite RRset is not entirely and exactly matched by a zone
! RRset, signal NXRRSET to requestor. If any RR in this section has a CLASS
! other than ZCLASS or NONE or ANY, signal FORMERR to requestor.
.Sh "3.2.4 - Table Of Metavalues Used In Prerequisite Section"
.TS
--- 497,525 ----
satisfied by the current state of the zone. Using the definitions expressed
in Section 1.2, if any RR's NAME is not within the zone specified in the
! Zone Section, signal NOTZONE to the requestor.
.LP
3.2.1. For RRs in this section whose CLASS is ANY, test to see that TTL and
! RDLENGTH are both zero (0), else signal FORMERR to the requestor. If TYPE is
! ANY, test to see that there is at least one RR in the zone whose NAME is the
! same as that of the Prerequisite RR, else signal NXDOMAIN to the requestor.
! If TYPE is not ANY, test to see that there is at least one RR in the zone
! whose NAME and TYPE are the same as that of the Prerequisite RR, else signal
! NXRRSET to the requestor.
.LP
3.2.2. For RRs in this section whose CLASS is NONE, test to see that the TTL
! and RDLENGTH are both zero (0), else signal FORMERR to the requestor. If the
TYPE is ANY, test to see that there are no RRs in the zone whose NAME is the
! same as that of the Prerequisite RR, else signal YXDOMAIN to the requestor.
! If the TYPE is not ANY, test to see that there are no RRs in the zone whose
NAME and TYPE are the same as that of the Prerequisite RR, else signal
! YXRRSET to the requestor.
.LP
3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS, test
! to see that the TTL is zero (0), else signal FORMERR to the requestor. Then,
build an RRset for each unique <NAME,TYPE> and compare each resulting RRset
for set equality (same members, no more, no less) with RRsets in the zone.
If any Prerequisite RRset is not entirely and exactly matched by a zone
! RRset, signal NXRRSET to the requestor. If any RR in this section has a
! CLASS other than ZCLASS or NONE or ANY, signal FORMERR to the requestor.
.Sh "3.2.4 - Table Of Metavalues Used In Prerequisite Section"
.TS
***************
*** 571,575 ****
requestor does not have permission to perform these updates, the server may
write a warning message in its operations log, and may either signal REFUSED
! to requestor, or ignore the permission problem and proceed with the update.
.LP
3.3.2. While the exact processing is implementation defined, if these
--- 576,581 ----
requestor does not have permission to perform these updates, the server may
write a warning message in its operations log, and may either signal REFUSED
! to the requestor, or ignore the permission problem and proceed with the
! update.
.LP
3.3.2. While the exact processing is implementation defined, if these
***************
*** 592,595 ****
--- 598,602 ----
Next, the Update Section is processed as follows.
.Sh "3.4.1 - Prescan"
+ .LP
The Update Section is parsed into RRs and each RR's CLASS is checked to see if
it is ANY, NONE, or the same as the Zone Class, else signal a FORMERR to the
***************
*** 626,629 ****
--- 633,637 ----
.DE
.Sh "3.4.2 - Update"
+ .LP
The Update Section is parsed into RRs and these RRs are processed in order.
.LP
***************
*** 768,780 ****
At the end of UPDATE processing, a response code will be known. A response
message is generated by copying the ID and Opcode fields from the request,
! and either copying the ZOCOUNT, PRCOUNT, and UPCOUNT fields and associated
! sections, or placing zeros (0) in the these ``count'' fields and not
! including any part of the original update. The ADCOUNT will be set to zero
! (0) the Additional Data Section will be made empty in responses, no matter
! what was present in the request. The QR bit is set to one (1), and the
! response is sent back to the requestor. If the requestor used UDP, then the
! response will be sent to the requestor's source UDP port. If the requestor
! used TCP, then the response will be sent back on the requestor's open TCP
! connection.
.\"............................................................................
.Sh "4 - Requestor Behaviour"
--- 776,786 ----
At the end of UPDATE processing, a response code will be known. A response
message is generated by copying the ID and Opcode fields from the request,
! and either copying the ZOCOUNT, PRCOUNT, UPCOUNT, and ADCOUNT fields and
! associated sections, or placing zeros (0) in the these ``count'' fields and
! not including any part of the original update. The QR bit is set to one
! (1), and the response is sent back to the requestor. If the requestor used
! UDP, then the response will be sent to the requestor's source UDP port. If
! the requestor used TCP, then the response will be sent back on the
! requestor's open TCP connection.
.\"............................................................................
.Sh "4 - Requestor Behaviour"
***************
*** 835,844 ****
.LP
5.1. For correct operation, mechanisms may be needed to ensure idempotence,
! order UPDATE requests and provide mutual exclusion. This is due to DNS's
! use of UDP, a datagram protocol which does not ensure reliable delivery. An
! UPDATE message or response might be delivered zero times, one time, or
! multiple times. Datagram duplication is of particular interest since it
! covers the case of the so-called ``replay attack'' where a correct request
! is duplicated maliciously by an intruder.
.LP
5.2. Multiple UPDATE requests or responses in transit might be delivered in
--- 841,849 ----
.LP
5.1. For correct operation, mechanisms may be needed to ensure idempotence,
! order UPDATE requests and provide mutual exclusion. An UPDATE message or
! response might be delivered zero times, one time, or multiple times.
! Datagram duplication is of particular interest since it covers the case of
! the so-called ``replay attack'' where a correct request is duplicated
! maliciously by an intruder.
.LP
5.2. Multiple UPDATE requests or responses in transit might be delivered in
***************
*** 894,898 ****
requestor is still open and the forwarder must use TCP to forward the
message. If the original requestor used UDP, the forwarder may use either
! UDP or TCP to forward the message, depending on the implementation.
.LP
6.3. It is reasonable for forward servers to be forwarders themselves, if
--- 899,903 ----
requestor is still open and the forwarder must use TCP to forward the
message. If the original requestor used UDP, the forwarder may use either
! UDP or TCP to forward the message, at the whim of the implementor.
.LP
6.3. It is reasonable for forward servers to be forwarders themselves, if
***************
*** 932,941 ****
data-absent dependencies in the Prerequisite Section.
.LP
! 7.3. The Additional Data Section might be used if some of the RRs later
needed for Secure DNS Update are not actually zone updates, but rather
ancillary keys or signatures not intended to be stored in the zone (as an
update would be), yet necessary for validating the update operation.
.LP
! 7.4. It is expected that in the absence of Secure DNS Update, a server will
only accept updates if they come from a source address that has been
statically configured in the server's description of a primary master zone.
--- 937,952 ----
data-absent dependencies in the Prerequisite Section.
.LP
! 7.3. The Additional Data Section can be used to supply a server with out of
! zone glue that will be needed in referrals. For example, if adding a new
! NS RR to HOME.VIX.COM specifying a nameserver called NS.AU.OZ, the A RR for
! NS.AU.OZ can be included in the Additional Data Section. Servers can use
! this information or ignore it, at the discretion of the implementor.
! .LP
! 7.4. The Additional Data Section might be used if some of the RRs later
needed for Secure DNS Update are not actually zone updates, but rather
ancillary keys or signatures not intended to be stored in the zone (as an
update would be), yet necessary for validating the update operation.
.LP
! 7.5. It is expected that in the absence of Secure DNS Update, a server will
only accept updates if they come from a source address that has been
statically configured in the server's description of a primary master zone.
***************
*** 943,958 ****
configured list.
.LP
! 7.5. It is not possible to create a zone using this protocol, since there is
no provision for a slave server to be told who its master servers are. It is
expected that this protocol will be extended in the future to cover this
case. Therefore, at this time, the addition of SOA RRs is unsupported. For
similar reasons, deletion of SOA RRs is also unsupported.
.LP
! 7.6. The prerequisite for specifying that a name own at least one RR differs
semantically from QUERY, in that QUERY would return <NOERROR,ANCOUNT=0> rather
than NXDOMAIN if queried for an RRset at this name, while UPDATE's prerequisite
condition [Section 2.4.4] would NOT be satisfied.
.LP
! 7.7. It is possible for a UDP response to be lost in transit and for a
request to be retried due to a timeout condition. In this case an UPDATE
that was successful the first time it was received by the primary master
--- 954,971 ----
configured list.
.LP
! 7.6. It is not possible to create a zone using this protocol, since there is
no provision for a slave server to be told who its master servers are. It is
expected that this protocol will be extended in the future to cover this
case. Therefore, at this time, the addition of SOA RRs is unsupported. For
similar reasons, deletion of SOA RRs is also unsupported.
.LP
! 7.7. The prerequisite for specifying that a name own at least one RR differs
semantically from QUERY, in that QUERY would return <NOERROR,ANCOUNT=0> rather
than NXDOMAIN if queried for an RRset at this name, while UPDATE's prerequisite
condition [Section 2.4.4] would NOT be satisfied.
.LP
! 7.8. It is possible for a UDP response to be lost in transit and for a
request to be retried due to a timeout condition. In this case an UPDATE
that was successful the first time it was received by the primary master
***************
*** 963,971 ****
TCP.
.LP
! 7.8. Because a requestor who requires an accurate response code will initiate
their UPDATE transaction using TCP, a forwarder who receives a request via TCP
must forward it using TCP.
.LP
! 7.9. Deferral of SOA SERIAL autoincrements is made possible so that serial
numbers can be conserved and wraparound at 2**32 can be made an infrequent
occurance. Visible (to DNS clients) SOA SERIALs need to differ if the zone
--- 976,984 ----
TCP.
.LP
! 7.9. Because a requestor who requires an accurate response code will initiate
their UPDATE transaction using TCP, a forwarder who receives a request via TCP
must forward it using TCP.
.LP
! 7.10. Deferral of SOA SERIAL autoincrements is made possible so that serial
numbers can be conserved and wraparound at 2**32 can be made an infrequent
occurance. Visible (to DNS clients) SOA SERIALs need to differ if the zone
***************
*** 973,977 ****
of visibility, for the purposes of this prerequisite.
.LP
! 7.10. A zone's SOA SERIAL should never be set to zero (0) due to
interoperability problems with some older but widely installed
implementations of DNS. When incrementing an SOA SERIAL, if the result of
--- 986,990 ----
of visibility, for the purposes of this prerequisite.
.LP
! 7.11. A zone's SOA SERIAL should never be set to zero (0) due to
interoperability problems with some older but widely installed
implementations of DNS. When incrementing an SOA SERIAL, if the result of
***************
*** 980,990 ****
more detail on this subject.
.LP
! 7.11. Due to the TTL minimalization necessary when caching an RRset, it is
recommended that all TTLs in an RRset be set to the same value. While the
DNS Message Format permits variant TTLs to exist in the same RRset, and this
variance can exist inside a zone, such variance will have counterintuitive
results and its use is discouraged.
.LP
! 7.12. Zone cut management presents some obscure corner cases to the add and
delete operations in the Update Section. It is possible to delete an NS RR as
long as it's not the last RR in the RRset. If deleting all RRs from a name,
--- 993,1005 ----
more detail on this subject.
.LP
! 7.12. Due to the TTL minimalization necessary when caching an RRset, it is
recommended that all TTLs in an RRset be set to the same value. While the
DNS Message Format permits variant TTLs to exist in the same RRset, and this
variance can exist inside a zone, such variance will have counterintuitive
results and its use is discouraged.
.LP
! 7.13. Zone cut management presents some obscure corner cases to the add and
delete operations in the Update Section. It is possible to delete an NS RR as
long as it's not the last RR in the RRset. If deleting all RRs from a name,
***************
*** 993,1006 ****
attempt to add an SOA will be treated as a replace operation.
.LP
- 7.13. The Additional Data Section will be made empty by requestors, passed
- through unchanged by forwarders and ignored by primary master servers. The
- Additional Data Section in responses will be made empty by primary master
- servers, ignored by forwarders, and ignored by requestors. This is intended
- to make it possible for future requestor specifications to use this section
- as a way to determine that a response was generated according to a future
- primary master server specification.
- .br
- .ne 6
- .LP
7.14. No semantic checking is required in the primary master server when
adding new RRs. Therefore a requestor can cause CNAME or NS or any other
--- 1008,1011 ----
***************
*** 1056,1059 ****
--- 1061,1073 ----
for names at the zone cut between them will be answered authoritatively using
only data from the child zone. (This is a clarification of RFC 1034.)
+ .LP
+ 7.23. Update ordering using the SOA RR is problematic since there is no way
+ to know which of a zone's NS RRs represents the primary master, and the zone
+ slaves can be out of date if their SOA.REFRESH timers have not elapsed since
+ the last time the zone was changed on the primary master. We recommend that
+ a zone needing ordered updates use only servers which implement NOTIFY (see
+ [NOTIFY]) and IXFR (see [IXFR]), and that a client receiving a prerequisite
+ error while attempting an ordered update simply retry after a random delay
+ period to allow the zone to settle.
.\"............................................................................
.Sh "8 - Security Considerations"
***************
*** 1063,1072 ****
alter the contents of a zone. This strongly indicates a need for out of
band access control such as static access control lists enforced by the
! server, or firewall techniques, or both.
.LP
At the time of this writing, work is progressing (see [DNSSEC]) on the
! general problem of DNS Security; however, no specification exists (at this
! time) for updating security related RRs, or for using security related RRs
! to control UPDATE access.
.\"............................................................................
.Sh "Acknowledgements"
--- 1077,1089 ----
alter the contents of a zone. This strongly indicates a need for out of
band access control such as static access control lists enforced by the
! server combined with the strongest possible firewall techniques.
.LP
At the time of this writing, work is progressing (see [DNSSEC]) on the
! general problem of DNS Security, and for Secure DNS Updates (see [SECUPD]).
! No updates should be accepted from hosts outside an enterprise network's
! security perimeter until and unless Secure DNS Updates have been implemented.
! For the purpose of this recommendation, a slave server acting as a forwarder,
! or the primary master itself, is outside the security perimeter if it is
! allowed to exchange DNS messages with hosts outside that perimeter.
.\"............................................................................
.Sh "Acknowledgements"
***************
*** 1074,1099 ****
We would like to thank the IETF DNSIND working group for their input and
assistance, in particular, Rob Austein, Randy Bush, Donald Eastlake,
! Masataka Ohta, Mark Andrews, and Robert Elz.
.\"............................................................................
- .bp
.Sh "References"
.IP [RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC
1035, USC/Information Sciences Institute, November 1987.
- .IP [DNSSEC]
- Donald E. Eastlake and Charles W. Kaufman, ``Domain Name System
- Protocol Security Extensions,'' Internet Draft, January 1996,
- <draft-ietf-dnssec-secext-09.txt>.
.IP [IXFR]
M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February 1996,
<draft-ietf-dnsind-ixfr-06.txt>.
.IP [NOTIFY]
! P. Vixie, ``Notify: a mechanism for prompt notification of authority
! zone changes,'' Internet Draft, February 1996,
! <draft-ietf-dnsind-notify-06.txt>.
.IP [KRE1996]
R. Elz, ``Serial Number Arithmetic,'' Internet Draft, February 1996,
<draft-ietf-dnsind-serial-00.txt>.
.\"............................................................................
.Sh "Authors' Addresses"
.DS
--- 1091,1120 ----
We would like to thank the IETF DNSIND working group for their input and
assistance, in particular, Rob Austein, Randy Bush, Donald Eastlake,
! Masataka Ohta, Mark Andrews, and Robert Elz. Special thanks to Bill Simpson
! and Ken Wallich for reviewing this document.
.\"............................................................................
.Sh "References"
.IP [RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC
1035, USC/Information Sciences Institute, November 1987.
.IP [IXFR]
M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February 1996,
<draft-ietf-dnsind-ixfr-06.txt>.
.IP [NOTIFY]
! P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes
! (DNS NOTIFY),'' Internet Draft, March 1996,
! <draft-ietf-dnsind-notify-07.txt>.
.IP [KRE1996]
R. Elz, ``Serial Number Arithmetic,'' Internet Draft, February 1996,
<draft-ietf-dnsind-serial-00.txt>.
+ .IP [DNSSEC]
+ Donald E. Eastlake and Charles W. Kaufman, ``Domain Name System
+ Protocol Security Extensions,'' Internet Draft, January 1996,
+ <draft-ietf-dnssec-secext-09.txt>.
+ .IP [SECUPD]
+ Donald E. Eastlake, ``Secure Domain Name System Dynamic Update,''
+ Internet Draft, February 1996, <draft-ietf-dnssec-update-00.txt>
.\"............................................................................
.Sh "Authors' Addresses"
.DS
=========================================================================
Date: Wed, 13 Mar 1996 18:51:24 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: dynDNS-08
X-To: paul@VIX.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <9603130848.AA25604@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 13, 96 12:48 am
Paul;
> If update ordering is required, a client has to have a way to get the current
> SOA value. Since it doesn't know which NS RR represents the primary, and
> since the primary may not even be reachable, finding the current SOA is going
> to be pretty difficult.
Your assumption that "the primary may not even be reachable" is
valid only when you leave forwarding feature.
Unless the primary changes, which is a lot less frequent than SOA
changes, we can find the primary quite easily.
> > > 5.3. A requestor can ensure transaction idempotence by explicitly
> > > deleting some ``marker RR'' (rather than deleting the RRset of which it
> > > is a part) and then adding a new ``marker RR'' with a different RDATA
> > > field. The Prerequisite Section should specify that the original
> > > ``marker RR'' must be present in order for this UPDATE message to be
> > > accepted by the server.
> > >
> > > 5.4. If the request is duplicated by a network error, all duplicate
> > > requests will fail since only the first will find the original ``marker
> > > RR'' present and having its known previous value.
> >
> > Header ID field is already there to prevent duplicated request.
>
> No, since the source address qualifies the ID, and we lose that in forwarding.
Is it a good reason to remove forwarders? Unfortunately for me,
I don't think so.
Because of the ID, a message is processed only once between forwarders.
Or, are you assuming several forwarders over different pathes
should be tried to reach the primary? If so, removing forwarding
feature is the protection against duplicated packets.
> > If a multitransaction request with marker RR fails, the requester
> > think the reason is because of other updates and reissues the
> > request.
> >
> > That is, unless the requests are idempotent ones from the beginning,
> > there always a possibility of duplicated request.
>
> Each transaction needs its own marker RR. If the totality of an update
> operation needs more than one transaction, then the "multitransaction
> request" will need its own "outer" marker RR.
???
If there are "outer" marker, which, I think, is provided with
out-of-band mechanism, we don't need internal markers.
> > > 7 - Design, Implementation, Operation, and Protocol Notes
> > Finally, an explanation should be added on how to assure
> > multitransaction atomic dynamic update with arbitrary any
> > prerequisite.
> I suspect that you intended the addresses in the last example to be different.
Oops, yes.
> In any case I don't know of a reason to support "OR", or any other logical
> operator.
Who proposed to "support" something?
So far, I have never seen the reason why the currnet limited
prerequisite is necessary but others are not. I did asked to ML
and got no answer.
KRE, in defence of the current draft, showed an example, where
partial matching of MX seems to be interesting.
A complex prerequisite is useful, when, for example, several
hosts want to be MX of several domains with balanced load.
> We are not, as I said earlier, trying to create a programming
> language here.
So? Who proposed a new protocol?
It's a description of a programming technique to make the current
protocol work with arbitrary any prerequisite.
> I heard you mention at the LA IETF DNSIND meeting that you thought there ought
> to be a standard for marker RR's. I don't agree, since the kind of locking
> being done here is "advisory", where the application is only trying to protect
> against simultaneous updates by another instance of itself on some other host,
> or another instance of the same privately defined locking mechanism.
My intention of the proposal was the MARKER RR as an standard
separator of TCP/UDP IXFR, in case you insisted on not using
IXFR format.
As I pointed out, compactified TCP IXFR won't work with the current
UPDATE format.
> At 25 pages, I am weighing new text very carefully to make sure that the
> document does not become so long that it's unreadable (that is, unreadable
> for a different reason than it is unreadable now :-)). To fully describe
> a multitransaction update would take another full page. I don't see the
> need, since your formulation above is the simplest possible interpretation
> of what the document already says, and it is perfectly correct. There are
> other correct ways to use the UPDATE to achieve the same result.
Want to shorten the document?
First, simplify protocol. I already suggested two simplifications.
Second, provide a separate document on how a healty zone should
be (only one SOA per zone, only one CNAME per node, only one WKS
per ...). Then, in the dynamic update document, you can simply
say that any update, other than a few exceptions, which make
the resulting zone wrong will be silently ignored (or loudly
refused, which is my recommendation).
As for the multitransaction update with arbitrary prerequisite,
I think, you can say (with less English errors):
After getting the marker RR for the multitransaction
update, the updater may check any condistions which
may not be expressed in prerequisite section and may
abort the transaction or change the content of request
according to it. Atomicity is still assurred if the
resulting request have the marker RR as prerequisite.
Why do you think a full page is necessary?
Masataka Ohta
=========================================================================
Date: Wed, 13 Mar 1996 02:29:43 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: dynDNS-08
In-Reply-To: Your message of "Wed, 13 Mar 1996 18:51:24 +0200."
<199603130951.SAA12299@necom830.hpcl.titech.ac.jp>
> Your assumption that "the primary may not even be reachable" is
> valid only when you leave forwarding feature.
I know of (have built; am currently maintaining for multinational
corporations who are customers of my company's technical services
arm) configurations where the primary is not reachable from outside
the enterprise network except TCP/53 from known external slaves.
> Or, are you assuming several forwarders over different pathes
> should be tried to reach the primary? If so, removing forwarding
> feature is the protection against duplicated packets.
That's what we've been discussing. Or what I've been discussing, anyway.
We don't agree. We know we don't agree. Let's move on.
> > Each transaction needs its own marker RR. If the totality of an update
> > operation needs more than one transaction, then the "multitransaction
> > request" will need its own "outer" marker RR.
>
> ???
>
> If there are "outer" marker, which, I think, is provided with
> out-of-band mechanism, we don't need internal markers.
No. "Outer" in that context meant a marker that was held during or
modified by the multitransaction update, as distinct from an "inner"
one modified by a single transaction in a multitransaction update.
The inner one protects against packet duplications which could
otherwise impede or revert the progress made during the multitransaction
update if an earlier transaction is reapplied.
The outer one protects against the entire multitransaction update
being done more than once by a client who doesn't know it's already
been done and cannot tell from QUERY or prerequisites pertaining to
the data itself that its proposed update has not been done yet.
No, I'm not going to give an example. Let's move on.
> It's a description of a programming technique to make the current
> protocol work with arbitrary any prerequisite.
Warning: Humour++;
Sure, let's represent the prerequisite section with a TXT RR containing JAVA.
Warning: Humour--;
> My intention of the proposal was the MARKER RR as an standard
> separator of TCP/UDP IXFR, in case you insisted on not using
> IXFR format.
Ah. Different markers, then. I apologize for misunderstanding you. We did
better at making ourselves understood in the terminal room, one on one, after
we'd both spent a bit of time at the bar, than we ever seem to do in the
meetings. I wish now that I'd asked you what you meant by the marker RR.
It's not up to me, by the way, to insist on using or not using the IXFR format.
If the IESG selects your existing format, BIND will implement it. No argument.
> As I pointed out, compactified TCP IXFR won't work with the current
> UPDATE format.
And as I pointed out, the compact (UDP) response has no economic basis, since
if updates are happening often enough to make the savings in TCP startup and
overhead look worthwhile, then the size of the IXFR is going to be such that
it will need a TCP connection to hold it all, anyway. You can't win with UDP
in the short case, since if the IXFR stream is small enough to fit in one
datagram, it means you aren't getting enough updates for the lack of TCP
overhead to amortize.
I still propose, and will shortly write up unless you do it first, that IXFR:
query(UDP) for SOA.
serial outdated? YES:
open(TCP)
send(IXFR?) with old SOA
IXFR unavailable or larger than AXFR? YES:
do standard AXFR
NO:
send(IXFR) with old SOA
repeat send(UPDATE) until done
send(IXFR) with new SOA
No UDP after the initial SOA query. Simple, short, easy. The UPDATEs will
be shorn of their prerequisite and zone sections, leaving only the update
and additional data sections. The slave will just use the same "apply update"
subroutine for an incoming IXFR that it would use for UPDATE if it were the
zone's primary master.
Fred Baker's speech in the open IESG meeting mentioned unified protocols. I
want one to come out of DNSIND. If we can't agree which IXFR format to use,
the AD or IESG will get two IXFR proposals and make the decision for us.
> Want to shorten the document?
No. But neither do I wish to lengthen it with something that's obvious,
as I believe your proposed example would be. I can be convinced otherwise;
if you really believe that the example is necessary for a reader to under-
stand the intent of the document, and you can convince me that conformant
implementations might otherwise not interoperate, I will add an example of
the multitransaction update. I will have to go to great lengths to make
sure that it does not appear to be part of the protocol description, since
not every client implementor will do multitransaction locking the same way
and that's __OK__ with me for reasons I explained earlier.
> As for the multitransaction update with arbitrary prerequisite,
> I think, you can say (with less English errors):
>
> After getting the marker RR for the multitransaction
> update, the updater may check any condistions which
> may not be expressed in prerequisite section and may
> abort the transaction or change the content of request
> according to it. Atomicity is still assurred if the
> resulting request have the marker RR as prerequisite.
>
> Why do you think a full page is necessary?
Your earlier example looked a lot longer than than paragraph.
=========================================================================
Date: Wed, 13 Mar 1996 08:12:32 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: zones that tick
In-Reply-To: Your message of "Wed, 13 Mar 1996 09:21:48 EST."
<Pine.SUN.3.91.960313082956.1107A-100000@cybercash.com>
> IF TTLs are trimmed as the expiration time approaches, which was
> discussed and I assumed was going to happen, I can't see
> why any caching server or whatever should ever give anyone a wrong answer,
> which is what its all about. So maybe this is a change from what the
> ancient hallowed texts say about serial number. Unless you can show that
> some ordinary resolver gives a wrong answer, I just don't see the problem
> with leaving the serial number alone.
>
> Donald
i hadn't thought about that aspect of it. you're right, we're OK.
=========================================================================
Date: Thu, 14 Mar 1996 11:24:09 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: zones that tick
X-To: paul@VIX.COM
In-Reply-To: <9603130419.AA25154@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 12, 96 8:19 pm
> >> While I can appreciate the needs of the DNSSEC group, who want insecure data
> > Such functionality of nameservers gives no real security,
> > because, if a nameserver is compromised, it is easy to set
> > the clock to a wrong value.
>
> I didn't say they wanted it for security. I said only that they wanted it,
You said it their "needs". But, how can DNSSEC need or want something
unrelated to security? I think they are violating their charter.
> and if you don't agree with this I suggest you read the DNSSEC-09 draft.
I'm tired of commenting on DNSSEC draft. If DNSSEC admit it unrelated
to security, can we, DNSIND, just ignore and let IESG do the rest of
job?
> > With DHCPRELEASE message, it is possible to return assigned values
> > before it's expiration. The returned value can be used again.
>
> All true. Apparently you missed the LA DHC meetings,
Yes.
> where someone brought
> up what they considered an example of an average case, where the DHCP client
> was turned off before it could release anything to anybody. The lease will
> eventually expire and the DHCP server will do the appropriate DNS update to
> make the PTR RR disappear. However, the DHCP client was responsible for
> adding the A RR,
And the weak security is broken by someone physically on the same
subnet (or on the different subnet with routing trick) assuming
the expired IP address. OK.
But, it is NOT at all a DNS problem.
After (or even before with routing trick, which is why weak security
is weak) the DHCP client turned off, ANYONE physically on the same
subnet can assume the IP address regardless of whether it is expired
or not.
It is only a restatement of a well known fact that the weak security
is not a protection against routing trick or compromised/malicious
hosts on the same subnet.
Or, are there any DHCP problem related to DNS expiration?
> I suppose that using a separate zone for each dynamically assignable hostname
> is one way to get expiration in the short term. Perhaps you should suggest
> that to Yakov, whose DHCP/DYNDNS Interaction draft needs to speak to this.
That's a good thing with various reasons and what I have been saying
from the pre-histric period of load-balancing ages.
But, having separate ZONE means that glue As should be updated
upon address reassignment, which is why I think BIND bug
on glues should be fixed and finer control of glues should
be possible.
Masataka Ohta
=========================================================================
Date: Thu, 14 Mar 1996 12:00:10 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: dynDNS-08
X-To: paul@VIX.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <9603131029.AA18611@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 13, 96 2:29 am
Paul;
> > My intention of the proposal was the MARKER RR as an standard
> > separator of TCP/UDP IXFR, in case you insisted on not using
^^^
> > IXFR format.
Apparently, you should have missed one of my mails.
> No, I'm not going to give an example. Let's move on.
OK, save lines. So, I won't repost my mail. Read it again from ML log.
> > Want to shorten the document?
>
> No. But neither do I wish to lengthen it with something that's obvious,
> as I believe your proposed example would be.
Obvious?
You said prerequisite section is necessary and my proposal is
unacceptable, because:
to make update atomic
and
because finer grain update is necessary
So, the programming technique is not obvious to you.
If you disagree on what you said, I can quote your mails.
> Your earlier example looked a lot longer than than paragraph.
Yes. So, if I rewrite your draft, it will be 10 or 15 pages
long half of which will be examples.
But, when your 25 pages of draft does not contain any examples,
why do you think you need examples?
Masataka Ohta
=========================================================================
Date: Wed, 13 Mar 1996 21:10:55 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: ongoing discussion betw. vixie and ohta
X-To: namedroppers@internic.net
We're boring our audience, so I'm going to let the current threads die off
without further reply. We all have more important things to do than continue
a discussion that goes nowhere as fast as this one is doing.
=========================================================================
Date: Thu, 14 Mar 1996 10:36:47 -0500
Reply-To: Internet-Drafts@CNRI.Reston.VA.US
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
Comments: RFC822 error: <W> Incorrect or incomplete address field found and
ignored.
From: Internet-Drafts@CNRI.RESTON.VA.US
Subject: I-D ACTION:draft-ietf-dnsind-notify-07.txt
X-cc: namedroppers@internic.net
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Title : A Mechanism for Prompt Notification of Zone Changes
(DNS NOTIFY)
Author(s) : P. Vixie
Filename : draft-ietf-dnsind-notify-07.txt
Pages : 8
Date : 03/13/1996
This draft describes the NOTIFY opcode for DNS, by which a master server
advises a set of slave servers that the master's data has been changed and
that a query should be initiated to discover the new data.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnsind-notify-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-notify-07.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnsind-notify-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960313170352.I-D@CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-notify-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-notify-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960313170352.I-D@CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
=========================================================================
Date: Thu, 14 Mar 1996 10:37:41 -0500
Reply-To: Internet-Drafts@CNRI.Reston.VA.US
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
Comments: RFC822 error: <W> Incorrect or incomplete address field found and
ignored.
From: Internet-Drafts@CNRI.RESTON.VA.US
Subject: I-D ACTION:draft-ietf-dnsind-dynDNS-08.txt
X-cc: namedroppers@internic.net
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Title : Dynamic Updates in the Domain Name System (DNS UPDATE)
Author(s) : P. Vixie, S. Thomson, Y. Rekhter, J. Bound
Filename : draft-ietf-dnsind-dynDNS-08.txt
Pages : 27
Date : 03/13/1996
The Domain Name System was originally designed to support queries of a
statically configured database. While the data was expected to change, the
frequency of those changes was expected to be fairly low, and all updates
were made as external edits to a zone's Master File.
Using this specification of the UPDATE opcode, it is possible to add
or delete RRs or RRsets from a specified zone. Prerequisites are specified
separately from update operations, and can specify a dependency upon either
the previous existence or nonexistence of an RRset, or the existence of a
single RR.
UPDATE is atomic, i.e., all prerequisites must be satisfied or else
no update operations will take place. There are no data dependent
error conditions defined after the prerequisites have been met.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnsind-dynDNS-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-dynDNS-08.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnsind-dynDNS-08.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960313165908.I-D@CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-dynDNS-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-dynDNS-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960313165908.I-D@CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
=========================================================================
Date: Fri, 15 Mar 1996 17:07:34 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: ongoing discussion betw. vixie and ohta
In-Reply-To: <9603140510.AA20803@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 13, 96 9:10 pm
Randy;
As I pointed out, because of newly raised problem of packed
TCP message format, IXFR can't simply use UPDATE format neither
for UDP nor TCP.
So, I think the format issue should be resolved before drafts
judged by IESG.
But Paul wrote:
> We're boring our audience, so I'm going to let the current threads die off
> without further reply. We all have more important things to do than continue
> a discussion that goes nowhere as fast as this one is doing.
So, could you assign a new UPDATE editor who has enough time to
discuss the format issue, and, hopefully other issues, on how to
or how not to modify the UPDATE/IXFR draft/protocol?
I may volunteer with assured quick convergence. :-)
Masataka Ohta
=========================================================================
Date: Fri, 15 Mar 1996 10:21:27 -0500
Reply-To: Internet-Drafts@CNRI.Reston.VA.US
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
Comments: RFC822 error: <W> Incorrect or incomplete address field found and
ignored.
From: Internet-Drafts@CNRI.RESTON.VA.US
Subject: I-D ACTION:draft-ietf-dnsind-dynDNS-09.txt
X-cc: namedroppers@internic.net
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Title : Dynamic Updates in the Domain Name System (DNS UPDATE)
Author(s) : P. Vixie, S. Thomson, Y. Rekhter, J. Bound
Filename : draft-ietf-dnsind-dynDNS-09.txt
Pages : 28
Date : 03/14/1996
The Domain Name System was originally designed to support queries of a
statically configured database. While the data was expected to change, the
frequency of those changes was expected to be fairly low, and all updates
were made as external edits to a zone's Master File.
Using this specification of the UPDATE opcode, it is possible to add or
delete RRs or RRsets from a specified zone. Prerequisites are specified
separately from update operations, and can specify a dependency upon either
the previous existence or nonexistence of an RRset, or the existence of a
single RR.
UPDATE is atomic, i.e., all prerequisites must be satisfied or else
no update operations will take place. There are no data dependent
error conditions defined after the prerequisites have been met.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnsind-dynDNS-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-dynDNS-09.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnsind-dynDNS-09.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960314160126.I-D@CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-dynDNS-09.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-dynDNS-09.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960314160126.I-D@CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
=========================================================================
Date: Fri, 15 Mar 1996 17:07:26 EST
Reply-To: George Dobrowski <ghd@CC.BELLCORE.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: George Dobrowski <ghd@CC.BELLCORE.COM>
Subject: Liaison from ATM Forum
X-To: randy@psg.com, namedroppers@internic.net
To: IETF
Randy Bush
email: randy@psg.com
Chair DNSIND
email: namedroppers@internic.net
Subject: Liaison on DNS Class Name, Class Code Point, and Domain Name for
ATM Name Service (ANS) Baseline Document
The ATM Forum's Service Aspects and Applications (SAA)/Directory Service (DS)
group is developing an ATM Name Service (ANS) specification containing
references to a DNS Class ATM and a DNS domain ATM.INT.
The ATM Forum has decided to use the Domain Name Sustem (DNS) [RFC1034,
RFC1035] for mapping names to ATM resources. According to section 3.6 of
RFC1035, we request a new Class name ATM. To support this class we require
a Class code point for the ATM Class protocol family. We also request that
ATM.INT be allocated as the Domain Name.
From: George Dobrowski
Chair ATM Forum Technical Committee
CC: SAA/DS Working Group
Attached for your reference is a copy of the current ANS baseline text. The
information contained represents work in progress and is subject to change
after more study and comments. It is offered for discussion in the interest
of maximizing the availability of interoperable equipment and services.
--------------------------------------------------------------------------------
ATM Forum: Technical Committee, SAA/Directory
ATM Forum/95-1532R2
Straw Vote
April 15-19, 1994
************************************************************
Title: ATM Name Service (ANS) Base Text
************************************************************
Abstract: Base text for version 1.0 of the ATM Name Service (ANS) is
presented. ANS is based on IETF's Domain Name Service (DNS) and provides
name to ATM address resolution and ATM address to name resolution. Version
0 of the ANS includes the basic functionality as defined in [RFC1034] and
[RCF1035] without their proposed extensions. These extensions would then be
part of version 2, which we would start working on after version 1 has been
finalized.
************************************************************
Date: April 15-19, 1996.
Anchorage, AK, USA
Distribution: ATM SAA
************************************************************
NOTICE
This document is offered to The ATM Forum membership as a basis for
discussion and is not binding on IBM or on any other member organization.
The requirements, specifications, proposals, comments or other material
presented herein are subject to change in form and content after further study.
IBM specifically reserves the right to add to, amend, or withdraw material
contained herein.
Technical Committee
ATM Name System (ANS)
Specification
Version 1.0
ATM Forum/95-1532R2
Straw Vote Version
April 1996
ATM Name System
Version 1.0
April 1996
O1996 The ATM Forum. All Rights Reserved. No part of this publication may be
reproduced in any form or by any means.
The information in this publication is believed to be accurate as of its publication date.
Such information is subject to change without notice and the ATM Forum is not
responsible for any errors. The ATM Forum does not assume any responsibility to update
or correct any information in this publication. Notwithstanding anything to the contrary,
neither The ATM Forum nor the publisher make any representation or warranty,
expressed or implied, concerning the completeness, accuracy, or applicability of any
information contained in this publication. No liability of any kind shall be assumed by The
ATM Forum or the publisher as a result of reliance upon any information contained in this
publication.
The receipt or any use of this document or its contents does not in any way create by
implication or otherwise:
( Any express or implied license or right to or under any ATM Forum member
company's patent, copyright, trademark or trade secret rights which are or may be
associated with the ideas, techniques, concepts or expressions contained herein; nor
( Any warranty or representation that any ATM Forum member companies will
announce any product(s) and/or service(s) related thereto, or if such announcements
are made, that such announced product(s) and/or service(s) embody any or all of the
ideas, technologies, or concepts contained herein; nor
( Any form of relationship between any ATM Forum member companies and the
recipient or user of this document.
Implementation or use of specific ATM standards or recommendations and ATM Forum
specifications will be voluntary, and no company shall agree or be obliged to implement
them by virtue of participation in the ATM Forum.
THE ATM FORUM IS A NON-PROFIT INTERNATIONAL ORGANIZATION
ACCELERATING INDUSTRY COOPERATION ON ATM TECHNOLOGY. THE ATM FORUM
DOES NOT, EXPRESSLY OR OTHERWISE, ENDORSE OR PROMOTE ANY SPECIFIC
PRODUCTS OR SERVICES.
Table of Contents
1. INTRODUCTION 5
1.1. MOTIVATION 5
2. TERMS AND DEFINITIONS 5
3. OVERVIEW OF ANS 5
4. LOGICAL MODELS 6
5. DATABASE ELEMENTS 6
5.1. RESOURCE RECORD DEFINITIONS 6
5.2. ATM SPECIFIC RESOURCE RECORDS 6
5.3. ATM ADDRESS TO DOMAIN NAME MAPPING 7
5.4. EXAMPLE MASTER FILE FORMAT 8
6. DNS PROTOCOL IN ATM ENVIRONMENT 9
6.1. RECURSIVE PROCESSING 9
6.2. INITIALIZATION 10
6.3. CLIENT INITIALIZATION 10
6.4. CONNECTION USAGE 10
7. NATIVE ATM SERVICES INTERFACE 11
8. ATM DIRECTORY SERVICE INTERFACE 11
9. REFERENCES 11
10. APPENDIX 1 - EXAMPLE ANS API 12
11. APPENDIX 2 - REQUIREMENTS 14
11.1. BASING OF ANS ON DNS 14
11.2. ANS REQUIREMENTS 15
1. Introduction
ATM applications require various types of directory services. Directory services
can be universal, that is, used by more than one application, or they may be
application specific. An example of a universal directory service is finding an
ATM address corresponding to the name of an ATM end system. An example of
an application specific service is finding the providers of specific types of services
(for example, VoD servers).
This document is version 1.0 of the ATM Name System (ANS). ANS is based on
Domain Name System (DNS) [RFC1034, RCF1035]. Among other functions,
DNS provides name to address and address to name resolution. ANS provides
name to ATM address resolution and ATM address to name resolution. Version
1.0 of the ANS includes the basic functionality as defined in [RFC1034] and
[RCF1035]. Future IETF extensions may become part of subsequent versions of
ANS.
1.1. Motivation
Basic name services are modeled on the Domain Name System [RFC1034,
RFC1035]. Extensions that may be considered are as follows: [DNSSEC]
describes security extensions. [DNSDYN] describes dynamic update capability.
[DNSNOT] describes a mechanism for prompt notification of zone changes.
[DNSIZT] describes incremental zone transfer capability.
The basic directory services are name to ATM address translation and ATM
address to name translation. However, information other than ATM names and
addresses may be added to the ANS data base. The ATMF supports rapid
deployment of the essential name services and provides infrastructure for higher
level directory services.
2. Terms and Definitions
See [RFC1034] and [RFC1035] for DNS terms and definitions.
3. Overview of ANS
See [RFC1034] and [RFC1035] for an overview of DNS.
4. Logical models
See section 2.2 of [RFC1035] for common DNS configurations.
5. Database elements
5.1. Resource Record Definitions
ATM specific resource records (RR) conform to the top level RR format and
semantics as defined in Section 3.2.1 of [RFC1035].
An RR CLASS code is needed to identify the ATM protocol family. This code
point is 0xzzzz.
<editor's note: A liasion with the IETF to obtain this codepoint is underway.>
5.2. ATM Specific Resource Records
One ATM specific resource record, TYPE A for CLASS ATM, has been defined.
It is used to map from domain names to ATM addresses. ATM address lookup
operates analogously to IP address lookup: the only distinction is that the
requested class is ATM (or "*") instead of INTERNET.
In CLASS ATM, TYPE A has the following RDATA format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| FORMAT | |
+--+--+--+--+--+--+--+--+ |
/ ADDRESS /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The fields have the following meaning:
FORMAT: One octet that indicates the format of ADDRESS. The two
possible values for FORMAT are value 0 indicating OSI NSAP format and
value 1 indicating E.164 format.
ADDRESS: Variable length string of octets containing the ATM address of
the node to which this RR pertains. The value is binary encoding of the
ATM address. This ATM address appears in the ATM End System
Address Octets field or the address number digits field of the Called or
Calling party number information element.
Type A RRs cause no additional section processing.
Other ATM specific resource records can be added in future releases of this
specification.
5.3. ATM Address to Domain Name Mapping
The PTR RR is defined in [RFC1035]. This RR is typically used under the "IN-
ADDR.ARPA" domain to map from IPv4 addresses to domain names.
Similarly, the PTR RR is used to map from ATM addresses to domain names
under the "ATM.INT" domain. A domain name is generated from the ATM
address according to the rules described below. A query is sent by the resolver
requesting a PTR RR for the provided domain name.
A domain name is generated from a OSI NSAP formatted ATM address by
concatenating from left to right the following substrings and separating them by a
"." character from each other:
the SEL field
the ESI field
the digits of the HO-DSP field in reverse order and separated by a "."
character from each other
the DCC, ICD, or E.164 field
the AFI field
the top level subdomain "NSAP.ATM.INT."
For example, the domain name used in the reverse lookup for the ATM address
39246f000e7c9c03120001000100001234567800
would appear as
00.000012345678.1.0.0.0.1.0.0.0.2.1.3.0.c.9.c.7.e.0.0.0.246f.39.NSAP.ATM.INT.
A domain name is generated from an E.164 formatted ATM address by
concatenating from left to right the following substrings and by separating them
with a "." character.
the digits of the national significant number in reverse order and separated
by a "." character from each other
the country code
the top level subdomain "E164.ATM.INT."
For example, the domain name used in the reverse lookup for the E.164
number
358400123456
would appear as
6.5.4.3.2.1.0.0.4.358.E164.ATM.INT.
Implementation note: For sanity's sake user interfaces should be designed to allow
users to enter ATM addresses using their natural order, that is, as they are typically
written on paper. Also, arbitrary "."s should be allowed (and ignored) on input.
5.4. Example Master File Format
This section describes an example master file format. Note that other formats are
possible.
The format of CLASS ATM RRs in Master Files conforms to Section 5,
"Master Files," of [RFC1035].
The mnemonic used to indicate the CLASS ATM is "ATM".
The RDATA section of an A line in a master file is expresses as follows:
OSI NSAP formatted ATM address: a string of hexadecimal digits. A "."
character can be used to separate any two digits for readability. The string
is case insensitive. For example:
39.246f.00.0e7c9c.0312.0001.0001.000012345678.00
E.164 formatted ATM address: a "+" character followed by a string of
decimal digits that form an international E.164 number. A "." character
can be used to separate any two digits for readability. For example:
+358.400.123456
Below are examples of the use of ATM RRs in Master Files to support name-to-
ATM address and ATM address-to-name mapping.
;;;;;;
;;;;;; Master File for domain dat.tele.fi.
;;;;;;
@ ATM SOA lohi.dat.tele.fi. jh.lohi.dat.tele.fi. (
1994041800 ; Serial - date
1800 ; Refresh - 30 minutes
300 ; Retry - 5 minutes
604800 ; Expire - 7 days
3600 ) ; Minimum - 1 hour
ATM NS lohi.dat.tele.fi.
ATM NS ns.tele.fi.
;
$ORIGIN dat.tele.fi.
salmon ATM A 39.246f.000e7c9c031200010001.000012345678.00
char ATM A 39.246f.000e7c9c031200010001.000023456789.00
;;;;;;
;;;;;; Master File for reverse mapping of ATM addresses under the
;;;;;; prefix 39.246f.000e7c9c031200010001
;;;;;;
@ ATM SOA lohi.dat.tele.fi. jh.lohi.dat.tele.fi. (
1994041800 ; Serial - date
1800 ; Refresh - 30 minutes
300 ; Retry - 5 minutes
604800 ; Expire - 7 days
3600 ) ; Minimum - 1 hour
ATM NS lohi.dat.tele.fi.
ATM NS ns.tele.fi.
;
$ORIGIN 1.0.0.0.1.0.0.0.2.1.3.0.c.9.c.7.e.0.0.0.246f.39.nsap.atm.int.
00.001234567800 ATM PTR salmon.dat.tele.fi.
00.002345678900 ATM PTR char.dat.tele.fi.
6. DNS Protocol in ATM Environment
The DNS assumes that protocol messages will be transmitted as datagrams or in a
byte stream carried by a virtual circuit. Datagrams are preferred for queries and
responses due to their lower overhead. Zone refresh activities (query type AFFR)
must use reliable virtual connections.
Since ATM networks do not support datagram services, ANS queries and
responses must be carried over ATM virtual connections established between the
clients and the servers.
6.1. Recursive Processing
By default, ANS clients, when they make queries, request recursive
processing of the query (by setting the RD bit to 1 in the header of the
query). ANS name servers must support recursion. If the server gives the
client a referral, then it can happen that the client does not have ATM
connectivity to the next server. In version 1, the servers use TCP/IP to
communicate among themselves.
6.2. Initialization
The following sections describe how a ANS client initializes an ATM
virtual connection to a ANS server and how ANS queries and responses
are carried over the virtual connection. In the first release of the ATM
name service specification, ANS servers are assumed to be running in
TCP/IP capable hosts and TCP is used for reliable communication.
6.3. Client Initialization
When a client becomes operational, initially it needs to find the ATM addresses of
one or more ANS servers. ANS clients use one of two mechanisms locate the
ATM address of ANS servers:
Get the ANS server addresses via ILMI.
Use a well-known ANS Address.
Getting ANS server addresses via ILMI is accomplished by defining a new type
value for the atmfSrvcRegTypes ILMI object that denotes ANS server:
-- ANS Server
atmfSrvcRegAnsServer OBJECT IDENTIFIER ::= { atmfSrvcRegTypes x }
If an DNS server address cannot be obtained from ILMI or if the client is unable to
establish a VC any ILMI supplied server address, then a well-known address may
be used. The well known address is
0x47007900000000000000000000.00a03e00000y.00.
<editor's note: x and y are TBD>
6.4. Connection Usage
After learning the ATM address of one or more ANS servers, an ANS client may
setup a connection to any one of the servers for sending ANS requests and
receiving ANS responses. The client sets up and releases the connection
dynamically using the UNI signaling protocol. The client should time-out after
some period of inactivity and release this connection. The server may release an
inactive connection so that the server provide services with other clients.
7. Native ATM Services Interface
The ANS client and ANS server access the ATM network via an API whose semantics are
specified by [ATMNAS]. The Native ATM Services connection attributes used for
communications between an ANS client and an ANS server are shown in the table below:
Attribute Name
Attribute Value
AAL_TYPE
AAL type 5
AAL5_FWD_MAX_SDU
512 bytes
AAL5_BAK_MAX_SDU
512 bytes
AAL5_SSCS_TYPE
Null
FWD_PCR_CLP1
line rate in cells per second
BAK_PCR_CLP1
line rate in cells per second
BEST_EFFORT
best effort requested
BEARER_CLASS
class X (BCOB-X)
TRAFFIC_TYPE
no indication
TIME_REQ
no indication
CLIPPING_IND
not susceptable to clipping
CONNECT_CONFIG
point-to-point connection
APPL_ID_TYPE
vendor-specific application ID
APPL_ID
The OUI (BHLI octets 6-8) is 0x00A03D.
The application ID (BHLI octets 9-12) is 0x00000001.
CALLED_ADDR_FORMAT
either private or public address format
CALLED_ADDR
ATM address of DNS server
CALLED_SUBADDR_TYPE
private subaddress format, if required
CALLED_SUBADDR
ATM subaddress of DNS server, if required
FWD_QOS_CLASS
QoS class 0
BAK_QOS_CLASS
QoS class 0
SSCS
Null
The following elements form a SAP address for the DNS server:
ATM address, including the selector byte
DNS application identification (carried in the BHLI information element)
Note that both layer-2 protocol identification and layer-3 protocol identification are ABSENT.
8. ATM Directory Service Interface
9. References
[ATMNAS]
ATM Forum Technical Committee, "Native ATM Services: Semantic Description,
Version 1.0", af-saa-0048-000, ATM Forum, January, 1996
[BSD4.3] S. J. Leffler, M. K. McKusick, M. Karels,
The Design and Implementation of the 4.3 BSD Unix Operating System,
1989
[DNSSEC]
D. Eastlake and C. Kaufman, "Domain Name System Protocol Security
Extensions", Internet Draft, March 1994, <draft-ietf-dnssec-secext-03.txt>.
[DNSDYN]
S. Thomson, Y. Rekhter, and J. Bound, "Dynamic Updates in the Domain Name
System (DNS)", Internet Draft, March 1995, <draft-ietf-dnsind-dynDNS-01.txt>
[DNSIZT]
M. Ohta, "Incremental Zone Transfer in DNS", August 1995, <draft-ietf-dnsind-
ixfr-03.txt>
[DNSNOT]
P. Vixie, "DNS NOTIFY, a mechanism for prompt notification of zone changes",
Internet Draft, October 1995, <draft-ietf-dnsind-notify-04.txt>
[RFC1034]
P. Mockapetris, "Domain Names - Concepts and Facilities", RFC
USC/Information Sciences Institute, November 1987.
[RFC1035]
P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1035,
USC/Information Sciences Institute, November 1987.
[RFC1706]
B. Manning and R. Colella, "DNS NSAP Resource Records", RFC 1706,
ISI/NIST, October 1994.
10. Appendix 1 - Example ANS API
This informative appendix contains an example API for ANS.
The interface to ANS could conform to the BSD 4.3 interface used today to resolve IP
protocol family addresses. This interface consists of the following system calls (defined
here in the most common 'C'-syntax)
extern int h_errno;
struct hostent *gethostbyname(name)
char *name;
struct hostent *gethostbyaddr(addr, len, type)
char *addr; int len, type;
struct hostent *gethostent()
sethostent(stayopen)
int stayopen;
endhostent()
herror(string)
char *string;
where
struct hostent {
char *h_name; /* official name of host */
char **h_aliases; /* alias list */
int h_addrtype; /* host address type */
int h_length; /* length of address */
char **h_addr_list; /* list of addresses from name server */
};
#define h_addr h_addr_list[0] /*address,for backward compatibility*/
The members of this structure are:
h_name Official name of the host.
h_aliases A zero terminated array of alternate names
for the host.
h_addrtype The type of address being returned
h_length The length, in bytes, of the address.
h_addr_list A zero terminated array of network addresses
for the host. Host addresses are returned in
network byte order.
h_addr The first address in h_addr_list; this is for
backward compatibility.
The sethostent, endhostent, gethostent, and herror calls are not
modified. To support the remaining two routines the semantics of the structure hostent
has to be extended by the newly supported address types because the component
h_addrtype today always carries AF_INET as answer and the type argument of the
gethostbyaddr function is be AF_INET always as well. The necessary new
specifications are two defines
#define AF_ATMNSAP
#define AF_ATME164
where the values are usually defined in the file socket.h and will vary among
implementations. If a mixture of IP/ATM addresses is found, the following should be
returned:
h_addrtype AF_MULTIPLE
that has to be specified in an RFC to be compatible with IETF.
The h_length is set to the length of the structures chained in h_addr_list. Each
structure in the h_addr_list looks the following way
struct
{
CHAR address[h_length-2];
WORD addresstype;
};
where addresstype is any of the address family numbers describing what type of
address is given in this structure. The address is filled into the address member starting at
the beginning. The call returning AF_MULTIPLE must put IP addresses in the front of the
list to assert comptability with implementations that assume that h_addrtype returned
is always AF_INET as it is in most implementations today a matter of fact.
Additionally, if a socket-like form of address conversion from human readable to internal
forms in the API is supported, some new structures and functions may to be provided
described in [BSD4.3].
struct atmnsap_addr
{
char atmnsap[20];
}
struct atme164_addr
{
char atme164[20];
}
struct atmnsap_addr *atmnsap_addr(const char *cp);
char *atmnsap ntoa(struct atmnsap_addr in);
struct atmnsap_addr *atme164_addr(const char *cp);
char *atme164_ntoa(struct atme164_addr in);
The returned and expected human readable strings conform to the form encountered in the
master file and described in section 8.4.
11. Appendix 2 - Requirements
This informative appendix captures the SAA/DS working group's requirements.
11.1. Basing of ANS on DNS
The ANS is based on the Domain Name Service (DNS) [RFC1034],
[RFC1035] including its security [DNSSEC], dynamic update [DNSDYN],
prompt notification of zone changes [DNSNOT] and incremental zone
transfer capability [DNSIZT] extensions. There are many reasons to use
DNS as the basis for ANS.
1.1.1. DNS is widely implemented in end systems.
1.1.2. DNS domain registration procedure has been implemented in most
countries.
1.1.3. DNS domain names are well known by the user community.
1.1.4. DNS can scale well if the name space is properly assigned. This
satisfies the requirement given in 2.1.3.
1.1.5. DNS implementations are efficient in terms of CPU and memory
usage. This satisfies the requirement given in 2.1.2.
1.1.6. DNS is resilient via the secondary server mechanism. This satisfies
the requirement given in 2.1.1.
1.1.7. DNS has low latency of queries. This satisfies the requirement
given in 2.1.4.
1.1.8. DNS extensions for dynamic updates and security are being worked
on.
1.1.9. DNS can be easily augmented with new database objects for ATM.
1.1.10. DNS allows dual hosts to choose between IP and native ATM.
11.2. ANS requirements
Several requirements for the directory service function that apply to ANS are:
No single point of failure (resilience)
efficient implementation including storage efficiency
Hierarchical naming structure (scalability)
low latency of queries
Toleration of temporary inconsistency, that is, that such
inconsistency does not damage the information in ANS.
The service may sometimes be transiently unavailability, for
example, "a busy signal"
Other ANS requirements include:
Independence between non-ATM network and transport layer
protocols
ANS is to be used by ATM applications. These applications may
not necessarily implement non-ATM network or transport
protocols. Most current DNS implementations carry DNS protocol
messages on top of UDP/IP and TCP/IP. This document specifies
the operation of DNS protocols using native ATM services instead
of TCP/IP.
<editor's note: as agreed at the last meeting, the use of native
ATM services is to be based on a contribution to the Los Angeles
meeting.>
Use of an existing naming scheme
ANS should exploit an already existing naming scheme in the same
way as ATM addressing utilizes existing addressing schemes.
Otherwise the ATM Forum would need to setup a new, worldwide
name registration service, which would be a difficult task to manage
and operate. Examples of existing naming schemes are the
Internet's DNS domain name hierarchy and X.500's directory
information tree hierarchy.
Dynamic updating of the directory data base
When an ATM end system address changes, it is important that the
ANS database need not be manually reconfigured. The end system
should be able to dynamically check and update its address
information in the ANS database. This is especially important when
the end user does not even necessarily know that an ATM address
of the end system has changed. (For example, a manager of the
switch could change the address prefix without notifying the users.)
Security of the dynamic updating process
Dynamic updating of the ANS database by end systems usually
requires that the updates can be authenticated. ANS must therefore
include an option to sign the ANS database entries with
cryptographic digital signatures. It would also be desirable if ANS
could store authenticated public keys in its database in order to
make the ANS protocol independent of yet another public key
management protocol.
Automatic configuration of ANS clients
Finally, automatic configuration of ANS clients is an important requirement. In order to
use directory services, the clients need to know one or more ATM addresses of
one or more ANS servers. If security is implemented, an ANS client needs a
correct public key of at least one zone of the hierarchical name space. A natural
solution is that ANS clients learn this information dynamically from an ATM
configuration server.
ATM Forum 95-1532R2 Straw Vote 16 SAA/Directory Services ANS
=========================================================================
Date: Sat, 16 Mar 1996 09:38:33 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: unified architecture? probably not.
In-Reply-To: mohta@NECOM830.HPCL.TITECH.AC.JP's message of 15 Mar 1996
00:25:29 -0800
>As I pointed out, because of newly raised problem of packed TCP message
>format, IXFR can't simply use UPDATE format neither for UDP nor TCP.
>
>So, I think the format issue should be resolved before drafts judged by IESG.
Given that you moved your document forward for IESG review without showing
any concern for whether it shared any similarities for the then-current, or
subsequent versions of the UPDATE protocol, I am surprised and a little
gratified to see you showing concern for the issue at this late date.
>So, could you assign a new UPDATE editor who has enough time to discuss the
>format issue, and, hopefully other issues, on how to or how not to modify
>the UPDATE/IXFR draft/protocol?
I stand ready to discuss serious proposals of how to unify these formats.
Our previous threads were not leading toward any particular end.
>I may volunteer with assured quick convergence. :-
There is no rule on who can do what with any given document, or write new ones.
I would have liked to see a unified architecture but I've let time run out.
As I know of no reason why IXFR will not work, I see the cost of changing it
at such a late date as greater than the benefit of changing it. You, as
author, would have to initate the level of change I see as needed. I, as
a fellow WG member, could at best produce a competing proposal, which would
do more harm than good at this point.
Randy, I'm ready to advance my two drafts. I have no further comment on Ohta's.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Sun, 17 Mar 1996 09:23:01 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: unified architecture? probably not.
X-To: paul@VIX.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <VIXIE.96Mar16093831@wisdom.vix.com>; from "Paul A Vixie" at Mar
16, 96 9:38 am
> >As I pointed out, because of newly raised problem of packed TCP message
> >format, IXFR can't simply use UPDATE format neither for UDP nor TCP.
> >
> >So, I think the format issue should be resolved before drafts judged by IESG.
>
> Given that you moved your document forward for IESG review without showing
> any concern for whether it shared any similarities for the then-current, or
> subsequent versions of the UPDATE protocol, I am surprised and a little
> gratified to see you showing concern for the issue at this late date.
WG last call on IXFR was issued at around Dallas.
On the draft, there have been NO technical comments other than
optional condensation one since Stockholm.
So, it was done and sent to IESG.
I did made comments on how UPDATE can use IXFR format without changing
its functionality.
You didn't responded and insisted on your proposal.
But, it was OK as long as unification was unimportant.
Now, there is your contribution that unification is somewhat important.
So, it is again a problem that you haven't properly responded
to my technical comments.
IXFR has reasons to have its current format, that is, to minimize
amount of traffic as much as possible. It shouldn't have prerequisite
section nor redundant deletion nor addition of data. It should have
a compact format to transfer differences over multiple versions.
The other reason is to detect inconsistency as much as possible.
That is try to detect errors as much as possible.
On the other hand, as I have been pointing out from the beginning,
UPDATE has no technical reason to have the current proposed format.
> >So, could you assign a new UPDATE editor who has enough time to discuss the
> >format issue, and, hopefully other issues, on how to or how not to modify
> >the UPDATE/IXFR draft/protocol?
>
> I stand ready to discuss serious proposals of how to unify these formats.
UPDATE should Use IXFR one.
> Our previous threads were not leading toward any particular end.
I'm afraid you don't have enough time to seriously discuss it.
> >I may volunteer with assured quick convergence. :-)
>
> There is no rule on who can do what with any given document, or write new ones.
>
> I would have liked to see a unified architecture but I've let time run out.
So, I'll volunteer, if you think it fair.
I'll mostly simplify your draft, which won't take so much time.
Masataka Ohta
=========================================================================
Date: Sun, 17 Mar 1996 09:43:09 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: unified architecture? probably not.
In-Reply-To: Your message of "Sun, 17 Mar 1996 09:23:01 +0200."
<199603170023.JAA01868@necom830.hpcl.titech.ac.jp>
[ this note contains a call for last minute objections before WG last call
on the UPDATE document. please read the last few paragraphs even if you
feel (understandably) obliged to skip the rest. --vix ]
> You didn't responded and insisted on your proposal.
We both did this.
> But, it was OK as long as unification was unimportant.
>
> Now, there is your contribution that unification is somewhat important.
I have always thought it was important. No more so now than earlier, however.
> So, it is again a problem that you haven't properly responded
> to my technical comments.
We are out of time. It doesn't matter whether I think unification is
important; getting IXFR and UPDATE and NOTIFY into the field is far more
important. We cannot keep fine tuning these proposals forever; at least,
I won't continue doing so forever, and a number of vendors are just going
to implement nonfinal drafts and be done with it unless we get the final
drafts done and moved to proposed.
IXFR will work as currently specified. That's good enough for me.
If you know of any reason why UPDATE, NOTIFY, or IXFR will not work as
they are currently specified, or why the documents as written could lead
to multiple conformant but noninteroperable implementations, I think we
should just move forward.
> IXFR has reasons to have its current format, that is, to minimize
> amount of traffic as much as possible. It shouldn't have prerequisite
> section nor redundant deletion nor addition of data. It should have
> a compact format to transfer differences over multiple versions.
> The other reason is to detect inconsistency as much as possible.
> That is try to detect errors as much as possible.
These are technical issues unrelated to end-veracity of the protocols the
quality of the documents that describe them. So, while I disagree with
your characterizations as stated above, and I think that you still do not
understand why the UDP case is either a breakeven or a net loss, I have no
objective which can be served by further discussion of this subject. Your
IXFR will work, to the best of my ability to analyze its theoretical behaviour.
> On the other hand, as I have been pointing out from the beginning,
> UPDATE has no technical reason to have the current proposed format.
Again, while I believe that I have answered your objections, it no longer
matters to my current objectives whether you understand UPDATE or not.
> > I stand ready to discuss serious proposals of how to unify these formats.
>
> UPDATE should Use IXFR one.
Your suggestion has been noted, as I assume my suggestion to you as IXFR's
draft editor that IXFR abandon its UDP model and use UPDATE with the zone
and prerequisites sections emptied. I think we both know where the other
stands. I think we've both heard as many arguments as we'll listen to. I
think we should agree to disagree, and move on.
> > Our previous threads were not leading toward any particular end.
>
> I'm afraid you don't have enough time to seriously discuss it.
I noted your objection 8 days ago and said I was expecting it to be raised
again during the IESG Last Call. I don't agree with your proposal, and I
have elected to stop trying to explain my reasons to you since the cost to
benefit ratio of you ever "getting it" has risen above the threshold allowed
by the importance of my real objectives wrt DNSIND.
> > I would have liked to see a unified architecture but I've let time run out.
>
> So, I'll volunteer, if you think it fair.
No, I don't think it's fair, where fairness is a function applied to our
responsibility to the user and vendor communities who are waiting for us.
> I'll mostly simplify your draft, which won't take so much time.
And I could do the same to your draft, but I don't see that it would serve
our user or vendor communities to do so. So, I won't.
I'll ask again -- if anyone knows a reason why UPDATE will not work or why
its document is ambiguous in a way that could impede multiple interoperable
implementations, please tell me about it.
=========================================================================
Date: Mon, 18 Mar 1996 08:14:15 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: unified architecture? probably not.
X-To: paul@VIX.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <9603171743.AA23780@wisdom.home.vix.com>; from "Paul A Vixie" at
Mar 17, 96 9:43 am
> [ this note contains a call for last minute objections before WG last call
> on the UPDATE document. please read the last few paragraphs even if you
> feel (understandably) obliged to skip the rest. --vix ]
>
> > You didn't responded and insisted on your proposal.
>
> We both did this.
OK. You might have.
> > So, it is again a problem that you haven't properly responded
> > to my technical comments.
>
> We are out of time.
I, at least, think we don't have time to waste on meta discussion.
> I'll ask again -- if anyone knows a reason why UPDATE will not work or why
> its document is ambiguous in a way that could impede multiple interoperable
> implementations, please tell me about it.
Lack of weak secutiry because of forwarding was already a good/bad
enough show stopper for UPDATE, I think.
Masataka Ohta
=========================================================================
Date: Sun, 17 Mar 1996 15:59:50 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Subject: Re: unified architecture? probably not.
X-To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: Your message of "Mon, 18 Mar 1996 08:14:15 +0200."
<199603172314.IAA02755@necom830.hpcl.titech.ac.jp>
> > We are out of time.
>
> I, at least, think we don't have time to waste on meta discussion.
If the IESG kicks this thing back because it isn't unified, then
we'll know it was important enough to add more delay even after
being nine months late.
> Lack of weak secutiry because of forwarding was already a good/bad
> enough show stopper for UPDATE, I think.
> Masataka Ohta
We have no security. We say that we have no security. We've been saying
for the whole draft development period that we have no security. If you
know a reason why having no security will impede acceptance of UPDATE by
the industry or by the user community, please tell me.
=========================================================================
Date: Sun, 17 Mar 1996 16:09:00 PST
Reply-To: Randy Bush <randy@PSG.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Randy Bush <randy@PSG.COM>
Subject: Re: forwarding loops in UPDATE
X-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
X-cc: namedroppers <namedroppers@internic.net>
> On the other hand, if they think someone outside firewall may
> dynamically update DNS data, they will open a hole in the
> firewall.
I am less sure of this than you seem to be.
Which is more vulnerable, a hole in the wall or a forwarding through a
commune-size plate of spaghetti running as root.
And, if the update may come from a roamer, how do we limit the hole?
It seems a tough call.
randy
=========================================================================
Date: Mon, 18 Mar 1996 14:34:15 +1100
Reply-To: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Subject: Re: forwarding loops in UPDATE
X-To: Randy Bush <randy@psg.com>
In-Reply-To: Your message of "Sun, 17 Mar 1996 16:09:00 PST."
<m0tySW4-0004zrC@roam.psg.com>
> > On the other hand, if they think someone outside firewall may
> > dynamically update DNS data, they will open a hole in the
> > firewall.
>
> I am less sure of this than you seem to be.
>
> Which is more vulnerable, a hole in the wall or a forwarding through a
> commune-size plate of spaghetti running as root.
>
> And, if the update may come from a roamer, how do we limit the hole?
>
> It seems a tough call.
>
> randy
>
Update correctly does not force any security model onto the
transaction. Implementors are free to implement their own
security model. DNSSEC will provide the basic one model some
time soon. In the mean time you can use which ever model you require.
You could use a transaction identifier for this case. Just put
"<id>.domain <class> NULL" into the additional section. Unless the
<id> matches the next expected <id>, reject the update. 2^504 labels
is a reasonably large search space. And that is only one label.
UPDATE provides the framework to allow this to happen. If it
didn't allow you to implement different security mechanisms you
should scream. Just because it doesn't give you one is not a
reason to scream. It specifically worns that it has no inbuilt
security.
Mark
--
Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au
MOBIL: +61 41 942 8884 UUCP:....!uunet!syd.dms.csiro.au!marka
=========================================================================
Date: Sun, 17 Mar 1996 21:00:28 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: forwarding loops in UPDATE
In-Reply-To: randy@PSG.COM's message of 17 Mar 1996 17:42:15 -0800
I liked Mark Andrews' answer to this -- we're not making security
impossible; we're just failing to make it mandatory. I expect that Secure
DNS Update will be the preferred mechanism for bringing in updates from
roamers.
Speaking as an implementor, I'm going to put an access control list on each
zone, and the default will be "accept nothing from anywhere" unless Secure
DNS Update has been implemented and is used in an update.
The importance of UPDATE forwarding is that it makes it possible for end to
end security to work and to depend upon a fairly reasonable transport.
To rehash, the reason that the WG directed the UPDATE draft editor to put
in forwarding was to avoid requiring the SOA.MNAME server to be reachable
by all update clients.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Sun, 17 Mar 1996 21:34:53 -0500
Reply-To: bound@ZK3.DEC.COM
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: bound@ZK3.DEC.COM
Subject: Re: unified architecture? probably not.
X-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
In-Reply-To: Your message of "Sun, 17 Mar 96 09:23:01 +0200."
<199603170023.JAA01868@necom830.hpcl.titech.ac.jp>
Please do not modify this draft. Paul is only one co-author of four
people for dynDNS UPDATE. We are now talking off line as co-authors.
Paul has been driving this phase of the dicussion, but at the end of the day
there are four authors for this spec. We need to review the technical
request amongst ourselves and respond as a set of co-authors. This will
take a few days.
Any modifications you suggest would be useful as diffs as to what you would
like to see to the mailing list as opposed to input as an editor which
we do not need with 4 authors for this spec.
What I would like to see before anymore changes are made for dynDNS-09
are as follows:
1. Name of Person requesting the change:
2. Reason/Rationale for the change:
3. Existing Wording in the specificiation:
4. Replacement Wording in the specification suggested:
After this we can respond as co-authors to the WG. In this manner we
can get the last minute input to dynDNS and respond with our perception
and how we propose to accept or reject the input as co-authors. Then
its up to the WG, Chair, AD, and IETF to resolve any differences.
So before any edits lets use the process we have and reiterate exactly
what the final issues are and what would make the spec acceptable.
thanks
/jim
=========================================================================
Date: Mon, 18 Mar 1996 06:12:31 PST
Reply-To: Yakov Rekhter <yakov@CISCO.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Yakov Rekhter <yakov@CISCO.COM>
Subject: Re: unified architecture? probably not.
X-To: bound@zk3.dec.com
In-Reply-To: Your message of "Sun, 17 Mar 96 21:34:53 EST."
<9603180234.AA14015@fwasted.zk3.dec.com>
Jim,
> What I would like to see before anymore changes are made for dynDNS-09
> are as follows:
>
> 1. Name of Person requesting the change:
>
> 2. Reason/Rationale for the change:
>
> 3. Existing Wording in the specificiation:
>
> 4. Replacement Wording in the specification suggested:
>
> After this we can respond as co-authors to the WG. In this manner we
> can get the last minute input to dynDNS and respond with our perception
> and how we propose to accept or reject the input as co-authors. Then
> its up to the WG, Chair, AD, and IETF to resolve any differences.
>
> So before any edits lets use the process we have and reiterate exactly
> what the final issues are and what would make the spec acceptable.
As one of the co-authors I certainly support your suggestion.
Yakov.
=========================================================================
Date: Mon, 18 Mar 1996 07:56:00 PST
Reply-To: Randy Bush <randy@PSG.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Randy Bush <randy@PSG.COM>
Subject: WG last call on NOTIFY
X-To: namedroppers <namedroppers@internic.net>
Please consider this the start of a two week WG last call on
draft-ietf-dnsind-notify-07.txt
randy
=========================================================================
Date: Mon, 18 Mar 1996 06:10:45 PST
Reply-To: Yakov Rekhter <yakov@CISCO.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Yakov Rekhter <yakov@CISCO.COM>
Subject: DHCP - DynDNS Interaction
X-To: dhcp-dns@bucknell.edu, dhcp-v4@bucknell.edu
Folks,
One of the issues raised during my presentation on the interaction
between DHCP and DynDNS Updates was the ability to expire individual
RRs. As was observed, at the present momement DynDNS has no mechanisms
by which an entity that originates a DNS update could convey to a DNS
server the expiration time for the RRs that are updated.
For the PTR RRs the inability to convey the expiration time in the
DynDNS Updates could be overcomed by requiring a DHCP server to update
(delete) the appropriate PTR RRs once the server detects that the lease
on the IP addresses (associated with the PTR RRs) that the server
leased to its clients either expired or is released by the DHCP
clients.
For the A RRs a similar approach could be used when the A RRs are
updated by a DHCP server.
So, the only open issue is how to deal with a situation where a DHCP
client is responsible for updating its A RRs. Moreover, the problem
would occur only if the client would not be able to update (delete) its
A RR when the lease expires (this could happen if the client is turned
off at this moment). In this case it could be possible that the
client's FQDN would be associated with an IP address of some other
host. Observe that this would matter only when some other host
would try to contact the client (e.g., the client has some server
application).
I'd like to get an input from the DHC WG members whether the WG would
insist on requiring DynDNS Updates to provide a mechanism to convey the
expiration time (DynDNS doesn't have such a mechanism at the present
moment), or whether the WG would agree that I would document in the
DHCP-DynDNS Internet Draft the (potential) limitations imposed by the
absence of such a mechanism in DynDNS, and we'll live with the limitations.
Yakov.
=========================================================================
Date: Mon, 18 Mar 1996 11:49:17 -0600
Reply-To: Mike Howsmon <mike@ACCESSUS.NET>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Mike Howsmon <mike@ACCESSUS.NET>
Will somebody please take me off this mailing list!!!!!!!!!!!!!!!!!!!!!!!!!!!!
=========================================================================
Date: Mon, 18 Mar 1996 13:33:13 -0500
Reply-To: kaplan@cs.umass.edu
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Alan Kaplan <kaplan@LIBERATION.CS.UMASS.EDU>
> Will somebody please take me off this mailing
> list!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Me too please. I have tried sending the appropriate commands to
Majordomo@internic.net
but with no success.
Alan
[Sorry to waste the bandwidth.]
=========================================================================
Date: Tue, 19 Mar 1996 08:42:15 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: unified architecture? probably not.
X-To: bound@ZK3.DEC.COM
X-cc: Multiple@necom830.hpcl.titech.ac.jp,
recipients@necom830.hpcl.titech.ac.jp,
of@necom830.hpcl.titech.ac.jp, list@necom830.hpcl.titech.ac.jp,
NAMEDROPPERS@necom830.hpcl.titech.ac.jp
In-Reply-To: <9603180234.AA14015@fwasted.zk3.dec.com>; from
"bound@ZK3.DEC.COM" at Mar 17, 96 9:34 pm
Jim;
> What I would like to see before anymore changes are made for dynDNS-09
> are as follows:
>
> 1. Name of Person requesting the change:
>
> 2. Reason/Rationale for the change:
>
> 3. Existing Wording in the specificiation:
>
> 4. Replacement Wording in the specification suggested:
Randy, is the above acceptable behaviour of a WG editor in IETF?
I have never suggested mere wording change.
Masataka Ohta
=========================================================================
Date: Mon, 18 Mar 1996 17:16:46 -0800
Reply-To: Michael Dillon <michael@MEMRA.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Michael Dillon <michael@MEMRA.COM>
Organization: Memra Software Inc. - Internet consulting
Subject: Re: I need a new red pen.
X-To: bmanning@ISI.EDU
X-cc: newdom@iiia.org, namedroppers@internic.net
In-Reply-To: <199603182326.AA27374@zed.isi.edu>
On Mon, 18 Mar 1996 bmanning@ISI.EDU wrote:
> 1. Modern BIND or equivalents (if any exist).
Is it possible to summarize what constitutes a BIND equivalent? If not,
then perhaps this should just require BIND.
> The upgrade process wiill be coordinated with the zone-master staff
> and will occur within 96 hours of inital notification.
Does this refer to the upgrading to newer versions of BIND? Or does this
refer to the upgrading of zone files?
> 5. Protected:
> In general, each server must be adequately protected against security
> threats. The system administrator must stay up-to-date on the latest
> security methods and threats and must implement reasonable security
> countermeasures. Audits by the zone administrator or authorized agents
> will be permitted and corrective measures will be taken. A good way to
> keep current is to follow the CERT recommendations. A reasonable approach
> is to only run DNS sw, NTP and ICMP support with extensive logging.
> Recommended packages to assist are tcp_wrappers and ipfilter. Any other
> package which is an acceptable technology is fine.
Is it reasonable to come right out and list which OS'es are acceptable?
In fact, since these are not general purpose machines, would it be going
too far to say they *MUST* run a specific OS with specific modifications?
I'm thinking of something like NetBSD here which runs on a reasonable
range of hardware. Or would that be going a bit overboard?
> 11. Name server and its immediate infrastructure are on uninterruptable
> power supply.
If this "immediate infrastructure" is meant to refer to the network hubs
and routers which connect the nameserver to the Internet, couldn't we
just specify that.
Michael Dillon Voice: +1-604-546-8022
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com
=========================================================================
Date: Tue, 19 Mar 1996 11:22:01 +1100
Reply-To: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Subject: Re: forwarding loops in UPDATE
X-To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: Your message of "Tue, 19 Mar 1996 08:25:11 +0200."
<199603182325.IAA05960@necom830.hpcl.titech.ac.jp>
> > > I am less sure of this than you seem to be.
> > >
> > > Which is more vulnerable, a hole in the wall or a forwarding through a
> > > commune-size plate of spaghetti running as root.
> > >
> > > And, if the update may come from a roamer, how do we limit the hole?
> > >
> > > It seems a tough call.
> > >
> > > randy
> > >
> >
> > Update correctly does not force any security model onto the
> > transaction.
>
> Update does force weak secutiry model out of the transaction, which
> is the problem.
>
> How can you have the weak security when source IP addresses are lost?
>
You know that secondaries make the source IP address invisible
so don't trust them
or
have them configured to return REFUSED/NOTIMPL for that zone and
trust them
or
have them implement the same trust model as the primary.
There are many ways to skin a cat.
> > Implementors are free to implement their own
> > security model.
>
> As long as it works.
>
> > You could use a transaction identifier for this case. Just put
> > "<id>.domain <class> NULL" into the additional section. Unless the
> > <id> matches the next expected <id>, reject the update. 2^504 label
> s
> > is a reasonably large search space. And that is only one label.
>
> I'm afraid you are proposing a new security model not necessary for
> secured DNS in a way quite incompatible with the existing practice
> of DNS operation.
>
> It is a overkill to have "<id>.domain" even though "<id>.domain"
> is not a valid DNS name.
Who ever said it had to be a existing name? It will be a valid
name so long as the total length limits are not exceeded. B.T.W.
I'd love you to be able to find the RR that signs a message with
DNSSEC in the cache. It just won't be there. There is no
difference here.
It doesn't matter what the security mechanism is. I could have
used "domain <class> TXT <2040 bits of transaction ID>" or
include a MD5 hash of the packet + transaction ID and shoved
that into the TXT records data field.
All I was saying is that you can design your own scheme and as
long as the server and the client agree on what it is it doen't
matter.
>
> When paul and other authors insists that the current draft is OK
> and have refused to add even a single paragraph, how can you put
> it, even if it were acceptable one, to the draft?
>
> > UPDATE provides the framework to allow this to happen.
>
> The problem of UPDATE is that it provide frameworks, which are NOT
> necessary.
I don't know why you say they are not necessary IPSEC support
MULTIPLE security mechanisms.
>
> When there are two solutions, one is to allow weak security by removing
> a unnecessary feature,
Having that feature does NOT weaken security. You don't HAVE to
forward, you are free to lie about what you are capable of
doing and I would expect many implementations too lie. Personally
having a server return REFUSED gives away too much information.
This is like having login not giving you a password prompt when
you don't type in a valid username.
> the other is to disallow weak security and develop
> a new one by leaving the unnecessary feature as is and adding yet another
> explanations, which, do you you think, is better?
>
> > If it
> > didn't allow you to implement different security mechanisms you
> > should scream. Just because it doesn't give you one is not a
> > reason to scream. It specifically worns that it has no inbuilt
> > security.
>
> If it has not builtin security and forbid familiar ones, that's a
> good reason to dismiss it.
>
You CAN perform secure communications over the existing IPV4
network without IP level security. Is this any reason to blow
away IPV4? IPV6 will support IP level security but you don't
have to use it. UPDATE will support multiple security models
including NONE. Just because we are still waiting to DNSSEC to
conclude so we can put a COMMON security model in place in no
reason to stop UPDATE proceeding.
Mark
> Masataka Ohta
>
--
Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au
MOBIL: +61 41 942 8884 UUCP:....!uunet!syd.dms.csiro.au!marka
=========================================================================
Date: Mon, 18 Mar 1996 16:33:28 -0800
Reply-To: bmanning@ISI.EDU
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: bmanning@ISI.EDU
Subject: Re: I need a new red pen.
X-To: Michael Dillon <michael@memra.com>
X-cc: newdom@iiia.org, namedroppers@internic.net
In-Reply-To: <Pine.BSF.3.91.960318170747.22066Q-100000@sidhe.memra.com> from
"Michael Dillon" at Mar 18, 96 05:16:46 pm
>
> On Mon, 18 Mar 1996 bmanning@ISI.EDU wrote:
>
> > 1. Modern BIND or equivalents (if any exist).
>
> Is it possible to summarize what constitutes a BIND equivalent? If not,
> then perhaps this should just require BIND.
Well, there is the DNS code the MS is delivering which,
according to rumor, is not based on BIND. Also, according
to rumor, BIND may be "stablized" in the near term and
a replacement coded up. As long as the code meets the specs... :)
> > The upgrade process wiill be coordinated with the zone-master staff
> > and will occur within 96 hours of inital notification.
>
> Does this refer to the upgrading to newer versions of BIND? Or does this
> refer to the upgrading of zone files?
Zone and Code updates. e.g. Secure-DNS code, New TLDs
>
> > 5. Protected:
>
> Is it reasonable to come right out and list which OS'es are acceptable?
Not to me. I'd prefer that to be an implementation detail.
> In fact, since these are not general purpose machines, would it be going
> too far to say they *MUST* run a specific OS with specific modifications?
Heavens No. I'd like to see/foster some genetic diversity
in these servers.
> I'm thinking of something like NetBSD here which runs on a reasonable
> range of hardware. Or would that be going a bit overboard?
Overboard imho.
> > 11. Name server and its immediate infrastructure are on uninterruptable
> > power supply.
>
> If this "immediate infrastructure" is meant to refer to the network hubs
> and routers which connect the nameserver to the Internet, couldn't we
> just specify that.
Cause not every site will/should have the same connection
topology.
A little breathing room for diversity is a good thing.
--
--bill
=========================================================================
Date: Mon, 18 Mar 1996 19:02:02 -0800
Reply-To: Michael Dillon <michael@MEMRA.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Michael Dillon <michael@MEMRA.COM>
Organization: Memra Software Inc. - Internet consulting
Subject: Re: I need a new red pen.
X-To: newdom@iiia.org
X-cc: namedroppers@internic.net
In-Reply-To: <199603190033.AA27451@zed.isi.edu>
On Mon, 18 Mar 1996 bmanning@ISI.EDU wrote:
> > > 1. Modern BIND or equivalents (if any exist).
> >
> > Is it possible to summarize what constitutes a BIND equivalent? If not,
> > then perhaps this should just require BIND.
>
> Well, there is the DNS code the MS is delivering which,
> according to rumor, is not based on BIND. Also, according
> to rumor, BIND may be "stablized" in the near term and
> a replacement coded up. As long as the code meets the specs... :)
But how do we determine if the code meets the spec? We're not discussing
what DNS software to allow on the Internet here; we're discussing what
are the requirements for the nodes which are part of an essential global
Internet service. I don't see anything wrong with nailing this down more
firmly and limiting choices.
> > > 5. Protected:
> >
> > Is it reasonable to come right out and list which OS'es are acceptable?
>
> Not to me. I'd prefer that to be an implementation detail.
Seems to me this ID wannabe already leans heavily into "implementation".
> > In fact, since these are not general purpose machines, would it be going
> > too far to say they *MUST* run a specific OS with specific modifications?
>
> Heavens No. I'd like to see/foster some genetic diversity
> in these servers.
If that is part of your intent, perhaps you should add a paragraph saying
so and giving some of the reasons why.
Michael Dillon Voice: +1-604-546-8022
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com
=========================================================================
Date: Tue, 19 Mar 1996 13:12:08 +1100
Reply-To: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Subject: Re: DHCP - DynDNS Interaction
X-To: Yakov Rekhter <yakov@cisco.com>
In-Reply-To: Your message of "Mon, 18 Mar 1996 06:10:45 PST."
<199603181411.GAA00357@yakov-home-ss20.cisco.com>
> Folks,
>
> One of the issues raised during my presentation on the interaction
> between DHCP and DynDNS Updates was the ability to expire individual
> RRs. As was observed, at the present momement DynDNS has no mechanisms
> by which an entity that originates a DNS update could convey to a DNS
> server the expiration time for the RRs that are updated.
>
> For the PTR RRs the inability to convey the expiration time in the
> DynDNS Updates could be overcomed by requiring a DHCP server to update
> (delete) the appropriate PTR RRs once the server detects that the lease
> on the IP addresses (associated with the PTR RRs) that the server
> leased to its clients either expired or is released by the DHCP
> clients.
>
> For the A RRs a similar approach could be used when the A RRs are
> updated by a DHCP server.
>
> So, the only open issue is how to deal with a situation where a DHCP
> client is responsible for updating its A RRs. Moreover, the problem
> would occur only if the client would not be able to update (delete) its
> A RR when the lease expires (this could happen if the client is turned
> off at this moment). In this case it could be possible that the
> client's FQDN would be associated with an IP address of some other
> host. Observe that this would matter only when some other host
> would try to contact the client (e.g., the client has some server
> application).
>
> I'd like to get an input from the DHC WG members whether the WG would
> insist on requiring DynDNS Updates to provide a mechanism to convey the
> expiration time (DynDNS doesn't have such a mechanism at the present
> moment), or whether the WG would agree that I would document in the
> DHCP-DynDNS Internet Draft the (potential) limitations imposed by the
> absence of such a mechanism in DynDNS, and we'll live with the limitations.
>
> Yakov.
>
I don't think UPDATE should be tied to getting a working expiry
mechanism defined. The two are orthogonal.
Mark
P.S. It is possible to get a working expire without the use of a
new RR or a SIG record. Ttl is defined to be a _signed_ number
of which _only_ positive values are allowed. You have 2^31 bits
to encode expiry/insersion information if you are willing to
allow ttl to default to zone minimum.
Mark
--
Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au
MOBIL: +61 41 942 8884 UUCP:....!uunet!syd.dms.csiro.au!marka
=========================================================================
Date: Mon, 18 Mar 1996 18:24:03 -0800
Reply-To: George Herbert <gherbert@CRL.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: George Herbert <gherbert@CRL.COM>
Subject: Re: I need a new red pen.
X-To: Michael Dillon <michael@memra.com>
X-cc: newdom@iiia.org, namedroppers@internic.net
In-Reply-To: Your message of "Mon, 18 Mar 1996 19:02:02 PST."
<Pine.BSF.3.91.960318185750.22066S-100000@sidhe.memra.com>
Michael writes:
>[...]
>But how do we determine if the code meets the spec? We're not discussing
>what DNS software to allow on the Internet here; we're discussing what
>are the requirements for the nodes which are part of an essential global
>Internet service. I don't see anything wrong with nailing this down more
>firmly and limiting choices.
>
>[...]
>> > In fact, since these are not general purpose machines, would it be going
>> > too far to say they *MUST* run a specific OS with specific modifications?
>>
>> Heavens No. I'd like to see/foster some genetic diversity
>> in these servers.
>
>If that is part of your intent, perhaps you should add a paragraph saying
>so and giving some of the reasons why.
I think that a combination of stability and experimentation is a
desirable end goal, to serve both current and future needs.
An introductory paragraph to that effect would be useful.
Perhaps the technical requirements should be simplified with that
in mind. Say, there shall be two types of servers. All shall meet
the following minimum specifications (performance, security, etc),
half or two thirds of the root servers of any new TLD shall use
only well proven software (or recent derrivatives thereof, such as
a more recent BIND with fixes) and the rest may run less well proven or
tested software so that it can be properly tested in a production
environment...
-george william herbert
gherbert@crl.com
=========================================================================
Date: Mon, 18 Mar 1996 16:01:55 EST
Reply-To: Shawn Mamros <mamros@FTP.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Shawn Mamros <mamros@FTP.COM>
Subject: Re: DHCP - DynDNS Interaction
X-To: yakov@cisco.com
X-cc: dhcp-dns@bucknell.edu, dhcp-v4@bucknell.edu
>One of the issues raised during my presentation on the interaction
>between DHCP and DynDNS Updates was the ability to expire individual
>RRs. As was observed, at the present momement DynDNS has no mechanisms
>by which an entity that originates a DNS update could convey to a DNS
>server the expiration time for the RRs that are updated.
[...]
>So, the only open issue is how to deal with a situation where a DHCP
>client is responsible for updating its A RRs. Moreover, the problem
>would occur only if the client would not be able to update (delete) its
>A RR when the lease expires (this could happen if the client is turned
>off at this moment). In this case it could be possible that the
>client's FQDN would be associated with an IP address of some other
>host. Observe that this would matter only when some other host
>would try to contact the client (e.g., the client has some server
>application).
It's actually a little bit worse than that. Even if the client is
up and running when its lease expires (and it hasn't been able to
renew its lease one way or another), specifically when should it delete
its A RR? It can't do it after the expiration time, because at that
point it can no longer safely use its IP address, and without that
you can't actually do the DynDNS exchange. That means you'd have to
delete the A RR before lease expiration time, but how much time should
one allow beforehand? There isn't really any one "right" value...
>I'd like to get an input from the DHC WG members whether the WG would
>insist on requiring DynDNS Updates to provide a mechanism to convey the
>expiration time (DynDNS doesn't have such a mechanism at the present
>moment), or whether the WG would agree that I would document in the
>DHCP-DynDNS Internet Draft the (potential) limitations imposed by the
>absence of such a mechanism in DynDNS, and we'll live with the limitations.
I'd prefer the latter (document the limitations). That may seem like
a contradiction of what I stated above - arguably, having the RR expire
on its own would potentially solve that problem - but I have a few reasons
to prefer not to do so.
First, I'm starting to believe that the case where the client will "own"
the A RR, while useful in some cases, will not be all that common in
practice. In the case of a "roving laptop" (my favorite one :-), I'm
beginning to feel that it would probably be better to use Mobile IP (with
DHCP being used only to obtain an address on the foreign net), and thus
there won't be a need to update the A RR "back home" - that will stay
at the home address.
Second, if RRs did have expiration times, that means the client or server
would have to update that expiration time every time the lease is renewed.
In my experience, lease renewals happen far more frequently than do lease
expirations, and I'd prefer minimizing the number of times I have to do
DynDNS.
Lastly, and perhaps most important, I'd like to see DynDNS move forward
ASAP, and it's my impression that trying to add per-RR expiration at this
late date is only going to delay things.
-Shawn Mamros
E-mail to: mamros@ftp.com
=========================================================================
Date: Mon, 18 Mar 1996 15:26:32 -0800
Reply-To: bmanning@ISI.EDU
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: bmanning@ISI.EDU
Subject: I need a new red pen.
X-To: newdom@iiia.org, namedroppers@internic.net
Round three...
Your constructive comments are encouraged. Particularly in
replacing XXX and xxx fields (section 7).
-----------------------------------------------------------
alt.scooby-doo_is_the_true_messiah B. Manning
Internet Draft ISI
March 1996 P. Vixie
ISC
Technical Criteria for Root and TLD Servers
Abstract
This draft proposes criteria for servers and their environments that
will support zones for top level and root domains. It is expected that
the machines running root service will be different than machines running
TLD service.
Although this draft has been discussed in various bodies, it is not
final, it should not be regarded as a consensus document, and it is
presented for open debate in the Internet community.
Status of this Memo
This document wants to be an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Design Goals:
Define the basic set of requirements for TLD/Root server hardware.
Make them all objectively verifiable.
Disclaimer:
This document doesn't discuss actual placement of servers.
Procedures for dealing with non-compliance are not covered in
this memo.
Selected Operational Qualifications:
1. Modern BIND or equivalents (if any exist).
The upgrade process wiill be coordinated with the zone-master staff
and will occur within 96 hours of inital notification.
2. UDP checksums enabled.
3. Dedicated host
no user accounts, just the admin or root account.
no other services except NTP. (remove telnet, SMTP, FTP etc).
This requires support to be from the console or other specified
secure channel. It is expected that one-time tokens will be used
for authentication.
4. Singly homed (only one interface).
5. Protected:
In general, each server must be adequately protected against security
threats. The system administrator must stay up-to-date on the latest
security methods and threats and must implement reasonable security
countermeasures. Audits by the zone administrator or authorized agents
will be permitted and corrective measures will be taken. A good way to
keep current is to follow the CERT recommendations. A reasonable approach
is to only run DNS sw, NTP and ICMP support with extensive logging.
Recommended packages to assist are tcp_wrappers and ipfilter. Any other
package which is an acceptable technology is fine.
6. Servers time is synchronized via NTP.
This is useful for supporting functions; e.g. logging. It is expected that
future enhancements such as dynamic update and security support will take
advantage of accurate clocks.
7. Sufficient resources to support a transaction rate of XXX/sec and
mean time to respond of xxx seconds per transaction. There should be
enough extra resources available to support a 15% growth in the number of
transactions per second without affecting the response time.
8. Representative on TLD/Root administrator list is responsive:
8a. e-mail about required changes will be answered within 24 hours;
8b. vacations will cause responsibilities to be delegated, not ignored;
8c. contact numbers on file with zone-master senior staff members;
8d. an escalation/delegation list that has at least three levels of
hierarchy.
9. Named.boot file will specify...
9a. "xfrlist" of local nets and maybe other roots;
9b. server will use "secondary"