[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 chan