Subject: Re: [dnsext] Danger of coming unstuck

From: Francis Dupont <[email-masked]>
Date: Mon, 22 Jun 2009 16:18:46 +0200

In your previous mail you wrote:

   Possible fixes:
   
   (1) Set the reply as truncated

=> this is what the standard recommends

   (2) Discard some non-authoritative NS records, so a mixture of NS
 records and glue can be sent.

=> if this means a partial RRset this is not (yet) allowed

   (3) Respond to explicit requests for an A record, where the
 non-authoritative value is held as glue, with a non-authoritative
 answer.

=> IMHO this doesn't fit in the authoritative vs caching servers model.
And of course you can't send the query to an authoratative server if
you don't know an address of one of them (:-).

   (4) Similar to (3), but place the result in the additional section
  ( not to be discarded ).
   
=> same than (3)

   (2) might also be a solution to the BIND @512 question.
   
Thanks

[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: Francis Dupont <[email-masked]>
Date: Tue, 23 Jun 2009 17:14:50 +0200

Well I have tried my best to find what the spec says, I could not
  find anything very explicit, but there is this:

    http://tools.ietf.org/html/rfc4035#section-3.1.4 
   
      Including these DS, NSEC, and RRSIG RRs increases the size of
      referral messages and may cause some or all glue RRs to be omitted.
      If space does not permit inclusion of the DS or NSEC RRset and
      associated RRSIG RRs, the name server MUST set the TC bit (see
      Section 3.1.1).
   
   Here there is a fairly clear implication that glue RRs are omitted,
  without setting the TC bit, and this seems to be universal practice.
   
=> I agree but this applies only to not required glue RRs, so the
issue is for necessary but not required glue RRs (i.e., which may
be omitted (== not required) but are necessary to reach name servers).

   So this seems to be an unpleasant trap, and it's seems quite likely
  someone can fall into it one day. A child zone can be cut off from
  some resolvers, with no warning, when it's parent does a rollover that
  tips a referral over the limit.
   
=> if I disagree about the details I agree there is a real problem.
IMHO the simplest solution is to set the TC bit but we have to be
sure it is not a frequent case first...

Regards