In message <4dd39053-3e33-4bd1-a83d-f81219484...@dnss.ec>, Roy Arends writes:
> > On 27 Jul 2017, at 09:08, Shane Kerr <sh...@time-travellers.org> wrote:
> >
> > I support the draft, and am willing to contribute text and review!
> >
> > I have a few points now, in fact:
> >
> > 1. Does it make sense to divide the response codes up into those
> > corresponding to each error type? That is, something like 1xxxx for
> > SERVFAIL, 2xxxx for FORMERR, and so on?
>
> Loving this idea. 3xxxx for REFUSED.
>
> > 2. Do we mind having lots of error codes? For example, we can go really
> > far and do things likes DNSERR_BADCOMPRESS "name compression used
> > in RRTYPE that forbids it", or DNSERR_NAMETOOLONG "name longer than
> > 255 bytes", and so on. We could end up with hundreds of error codes.
> > As a developer I don't mind this too much, as these provide hints
> > about stuff you should be considering, but I can see why some people
> > would prefer to keep it simple.
>
> Really like this as well. I think it is really helpful.
> >
> > 3. As a concrete proposal, I suggest DNSERR_CENSORED, with the code 451
> > for consistency with the HTTP response code. This may be a useful
> > addition to the RPZ draft. ;)
>
> Sure.
>
> Roy
Well if we want to add new error code we need to bump the EDNS
version field or otherwise indicate that the client supports new
error codes.
NXRRSET instead of NOERROR with NODATA
NOTAUTH instead of REFUSED when not configured to
serve the query's namespace. We already do this for AXFR / IXFR.
If we want to reattempt to add new labels types a more precise error
code would be useful. In this case the use of the new label type
would be a signal that the error code (and EDNS) is understood.
Query minimisation is also required to achieve this as then only
the servers for zones with such labels need to support the label
type.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
