In message <[email protected]>, Tony 
Finch writes:
> Sorry for the delayed reply...
> 
> Stephane Bortzmeyer <[email protected]> wrote:
> 
> Your comments on the draft are very good and I agree with them. Minor
> quibble, though:
> 
> > Note also that "required" and "necessary" are used in the draft but
> > never defined. In a referral, the only RRset (for non-DNSSEC answers)
> > which is really required is the NS set. Glue records are not required
> > (you can always make a specific request for them: it means one more
> > RTT but it will work).
> 
> I don't think this is right: if you ask a parent zone name server for a
> glue record, you will get a referral to the child just as if you asked for
> any other record in the child zone. So glue records have to be present in
> referrals.

Correct.  Glue is not optional.  Failure to fit glue should result
in TC=1.  It is a mis-reading of RFC 1034 that all additional records
are optional.  Only data added at Section 4.3.2, step 6 is optional.
Note the word "attempt".  All other data is required including that
added at Section 4.3.2, step 3b.

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.

There are secure referrals where the authority section leaves no
space for additional records with EDNS@512.  Named sets TC=1 for
these when the <QNAME,QTYPE> matches a glue.  Without TC=1 being
set resolution failures occur.  It would be much simpler to do it
whenever glue does not fit independent of QNAME or QTYPE however
this would result in every COM and NET referral from the root setting
TC=1 for plain DNS.

Mark
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email protected]

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to