Subject: Re: {Blocked Content} I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-07.txt

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Jan 2008 11:42:40 +1100

> >#5.2.  Dynamic Update and DNAME
> >#
> >#   Zones containing a DNAME RR MUST NOT accept a dynamic update message
> >#   that would add a record or delegation with a name existing under a
> >#   DNAME.
> >#
> >#   A server MUST return an error message with RCODE=REFUSED [RFC2136] in
> >#   response to a dynamic update message that would add a resource record
> >#   under a DNAME in the zone.
> >
> >This section should state that it is permissible to delete a DNAME RR set fr
> om a name or modify one.  What about adding?  That's more complex because the
> re may be existing names below the proposed owner of the DNAME.  Would it be 
> like adding an NS RR?  Masking away the obscured names?  Or is the addition a
>  flat-out error?  I think that needs to be discussed (meaning, I don't have a
>  definite opinion myself).

	Just make DNAME like delegating NS records.  The DNAME record
	hides any records below it.  This makes it consistant with NS
	behaviour where if you add a delegating NS RRset then remove
	it you restore the visible zone to its original state.

	B.T.W. this is what named does.

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

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

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 04 Jan 2008 15:23:44 +0100

Hi Ed,

Edward Lewis wrote:
>> SOA+NS+DNAME records
> The first sentence makes no sense to me.  I would suggest omitting it as
> the valid point is made in the second sentence. 
OK.

> # 2.4.  Names Next to and Below a DNAME Record
OK.

> #3.2.  CNAME synthesis
> ...
> #   It does not make sense for the authoritative server to follow the
> #   chain of DNAMEs, CNAMEs and wildcards outside of the zone of the
> #   query, as some resolver implementations will remove out-of-zone
> #   information from the answer.
> 
> This wording bothers me.
...
> If the intent is to edit those comments, this is a much bigger deal than
> advertised (=update to DNAME).

I think an update to 1034 is not warranted. I suggest to remove the text
in the next version.

> #3.3.  Acceptance and Intermediate Storage
> #
> #   DNS Caches MUST NOT allow data to be cached below the owner of a
> #   DNAME RR, except CNAME records and their signatures.  CNAME records
> 
> All sorts of alarm bells began to ring on this one - "and their
> signatures" set them off.  The CNAMEs aren't signed in this case.
> 
> What about a situation in which data at a name is cached for a week and
> three days later the zone administrator puts in a DNAME above the name
> cached.  If the cache learns of the DNAME, does the cache have to purge
> the previously cached data?

How about this text?
DNS Caches MUST be capable of handling inconsistency when data arrives
below the owner of a DNAME, or a DNAME arrives above owner names of
other data. Due to delays and caching in the DNS, these sort of
situations can appear after a zone is changed and TTLs have yet not expired.

So this says that when the cache learns of the DNAME in your example, it
should continue to work (not crash). Since TTLs mean that either answer
(DNAME or original data) are valid DNS answers, it can sometimes pretend
to never had gotten the DNAME, or pretend the original data fell out of
the cache, or attempt to restore sanity to its cache some other way.

After some time, expiry of TTLs will restore sanity.

> Another thing bothers me that is not related to the text here and I
> couldn't find where it is mentioned.  Synthesizing the CNAME with a TTL
> of 0 is a mistake because that means unaware caches (those that can't
> handle DNAME) will not hold onto the CNAME.  Perhaps the TTL should be
> the same as the DNAME but DNAME aware caches ought to treat the CNAME as
> 0 - if they even ever see it.  (They'll see it from older responders
> that don't understand the UD bit.)

I agree with Pauls response. Lets try to minimize unnecessary repeated
queries.

> This section should state that it is permissible to delete a DNAME RR
> set from a name or modify one.  What about adding?  That's more complex
> because there may be existing names below the proposed owner of the
> DNAME.  Would it be like adding an NS RR?  Masking away the obscured
> names?  Or is the addition a flat-out error?  I think that needs to be
> discussed (meaning, I don't have a definite opinion myself).

I'll go with Marks suggestion (works like NS updates), if that appears
to be consensus.

> #5.3.2.3.  Response With Synthesized CNAME
> ... I'd recommend just removing
> the comment altogether as it isn't really needed here and the caveats
> that could be included would dwarf the rest of the paragraph.  Case in
> point, this comment is more than twice as long as what I'm commenting on.
OK :-)

Best regards,
   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Jan 2008 09:39:37 -0500

>After some time, expiry of TTLs will restore sanity.

I'm not overly fond of the text "MUST be capable of handling," it 
sounds like "hey - cope."

I wouldn't put an RFC 2119 term there but mention that it is possible 
that a cached entry may be below a DNAME because changes may happen 
at the authoritative servers while the cache is independently holding 
on to old data.  I would further state that this is an uncommon, 
transitional condition, hence there is no specification for how a 
cache will treat this, with the choices being to store both and use 
each as if the other didn't exist, drop the previously held entry 
causing the conflict, or always drop the lower name.  From a 
specification and protocol development viewpoint it is impossible to 
decide which of the strategies is the best, perhaps in operations 
this will be apparent.  However, keep in mind that this will not be a 
common event in the protocol.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 04 Jan 2008 15:51:19 +0100

Michael StJohns wrote:
>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-07.txt
>>
>> # 2.3.  DNAME Apex not Redirected itself
>> ...
>> #  This means that a DNAME RR is not allowed at the same domain name as
>> #  NS records unless there is also a SOA record present.  DNAME RRs are
>> #  not allowed at the parent side of a delegation point but are allowed
>> #  at a zone apex.
>>
>> The first sentence makes no sense to me.  I would suggest omitting it as the valid point is made in the second sentence.  (That is - if you are a cache and happen to have all of a domain name's information stored you will always have an SOA where there is an NS.  From that perspective a restriction saying "it can't have NS unless there's an SOA" has got to be defined in the context of a zone file.)
> 
> Agreed.  AND... this really needs to be defined in terms of server and resolver behavior rather than what can and can't be in the zone file. People will screw up and bad things will happen.  How - exactly - does this record work in the presence of "bad data"?    E.g.  what happens at a cache if it gets both a DNAME and NS records for a specific name?  Does it keep the DNAME records and discard the NS records? Vice versa?  Crash in disgust?
> 
> In 2.4 - "refuse to load" should probably be "refuse to serve" data below a DNAME.
> 
> What does a recursive resolver do if it gets conflicting data (e.g. data below a DNAME followed later by a DNAME and vice versa?)
> 
> There are other places in the text which have this problem as well.
> 

Hi Michael,

I agree, such a statement should have been made in the context of a zone
file. Thanks for your comments.

However I disagree about having server and resolver behaviour terms and
'refuse to serve', see below about bad data for a solution I propose.

Having DNAME and NS records for one domain name is perfectly reasonable.
 The NS records define the server authoritative for that one domain
name, and the DNAME redirects names below that one domain name.

An example of bad data is when data (say an AAAA record at
www.example.com) exists below a DNAME record (at example.com).

How will things work with bad data. A server must refuse to load a zone
with bad data. Due to delays conflicts may appear for resolvers. A
resolver must select one side of the conflict. Due to data falling out
of the cache, a resolver may change sides in the conflict. Until TTLs
expire (due to the zone file being correct, since it managed to load
without refusal), then sanity prevails again.

Since a resolver can change sides in the conflict situation anyway, it
can just as well be allowed to change sides per-query.

Best regards,
   Wouter

---

From: Wouter Wijngaards <[email-masked]>
Date: Mon, 07 Jan 2008 12:01:56 +0100

Edward Lewis wrote:
| I'm not overly fond of the text "MUST be capable of handling," it sounds
| like "hey - cope."
|
| I wouldn't put an RFC 2119 term there but mention that it is possible
| that a cached entry may be below a DNAME because changes may happen at
| the authoritative servers while the cache is independently holding on to
| old data.  I would further state that this is an uncommon, transitional
| condition, hence there is no specification for how a cache will treat
| this, with the choices being to store both and use each as if the other
| didn't exist, drop the previously held entry causing the conflict, or
| always drop the lower name.  From a specification and protocol
| development viewpoint it is impossible to decide which of the strategies
| is the best, perhaps in operations this will be apparent.  However, keep
| in mind that this will not be a common event in the protocol.
|

How is this for text (for section 3.3), no capital terms ?

3.3.  Acceptance and Intermediate Storage

~   DNS caches can encounter data at names below the owner name of a
~   DNAME RR, due to a change at the authoritative server where data from
~   before and after the change resides in the cache.  This conflict
~   situation is a transitional phase, that ends when the old data times
~   out.  The cache can opt to store both old and new data and treat each
~   as if the other did not exist, or drop the old data, or drop the
~   longer domain name.  In any approach, consistency returns after the
~   older data TTL times out.

~   DNS Caches MUST perform CNAME synthesis on behalf of DNAME-ignorant
~   clients.  A DNS Cache that understands DNAMEs can send out queries on
~   behalf of clients with the UD bit set.  After receiving the answers
~   the DNS Cache sends replies to DNAME ignorant clients that include
~   DNAMEs and synthesized CNAMEs.

You also asked about TTL nonzero synthesis. This is already in the
draft, section 3.2 cname synthesis (TTL equal to that of the DNAME).

For dynamic update I added the below paragraph at the start of 5.2 and
kept the existing text.
~   Dynamic update for DNAME records works similar to dynamic update for
~   delegating NS records.  For example, adding a DNAME obscures names in
~   the zone.  DNAME records can be added, changed and removed.

Best regards,
~   Wouter