[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: version -01 of draft-ietf-dnsext-dns-protocol-profile sent
> I have some comments on draft-ietf-dnsext-dns-protocol-profile-01:
>
> > 4.2.2. TCP
> >
> > {new normative language, maybe.. } The server MAY accept TCP
> > connections. {? what is the correct wording and reference?}
>
> I would like to keep the current requirement from RFC1123 section
> 6.1.3.2 that servers SHOULD support TCP. Two reasons for this are
> 1) to support answers that are too large to fit even in an EDNS0-extended
> UDP packet, and 2) to support the use of fallback to TCP as part of
> mechanisms to defend against query ID guessing attacks.
I would make TCP a MUST for a recursive server.
> > 4.3. DNS Message processing
> [...]
> > * The TC bit answer FORMERR MUST not have the TC bit set.
> > * RCODES SHOULD ignored.
>
> I have trouble parsing the two above bullet points.
>
> > 4.6. Label compression in RDATA
> >
> > [RFC 1035 (section 3.3. and 4.4.1)] ("Pointers can only be used for
> > occurrences of a domain name where the format is not class
> > specific.")
> >
> > Do label compression for labels in rdata for which this is
> > specifically mentioned in the RFC defining the RR.
> > o NS, SOA, CNAME, and PTR [RFC 1035 (3.3)].
> > o Others defined in [RFC 1035 (3.3)]are not compressed.
> > o MB, MG, MR, MINFO, MX also have compressed dnames. These RRs and
> > their compression are described in [RFC 1035].
>
> I find it confusing that the list of RR types from RFC1035 subject to
> compression is split into two bullet points separated by an unrelated
> bullet point.
>
> > o AFSDB, RP, RT [RFC 1183, (Section 1,2 & 3.3.3)].
>
> This seems to imply that a server may compress names in AFSDB, RP, and
> RT when sending them. That is incorrect; [RFC 3597] says names in
> these record types MUST NOT be compressed, but SHOULD be decompressed
> if received in a compressed form.
>
> > o You MUST follow the rules in [RFC 3597].
>
> Perhaps this should be at the beginning of the section rather than at
> the end, since RFC3597 is the the current specification of the
> compression rules and the rest of the section is basically reiterating
> those rules.
>
> > 4.7. Truncation handling
> >
> > Truncation handling is as specified in [RFC 2181 (9)].
> >
> > {TBD normative text for this section. RFC references required.} If
> > inclusion of a RR set that is REQUIRED in either the answer or
> > authority section leads to message truncation. The section is left
> > empty and the truncation (TC) bit is set. If the DO bit is set RRSIG
> > RRs are required in the answer and authority section.
> >
> > If inclusion of an RRset in the Additional section is not possible
> > RRs are omitted one by one. This may lead to incomplete RRsets.
> > Omission of RRs from the Additional section because of message size
> > constraints will NOT lead to setting of the TC bit. [RFC 2181 (9)].
>
> According to RFC2181, incomplete RRsets are allowed when TC is set
> but not when it is clear. The above text says the opposite.
> --
> Andreas Gustafsson, gson@araneus.fi
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>