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

[Wouter Wijngaards <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHfkfnkDLqNwOhpPgRAo34AJ9jg8h8j4/WSd2D1P5BfqS+ESXNOwCeMl0N
U+7RVSDCoF9bjduf3nQV9FY=
=+cLY
-----END PGP SIGNATURE-----

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