DNS server support

Support for writing DNS servers, and various API changes to accomplish that, specifically:

 - `DnsType` -> `DnsType<RecordType>` where RecordType is a subclass of `DnsEntry`, and has payload decoders for specific types
 - Introduced record-specific subclasses of `DnsEntry` for common types, with fallback to the ByteBuf-based `DnsResource`
 - `DnsEntry` gains public `writeTo()` and `writePayload()` to write itself correctly into a ByteBuf
 - Added `DnsQueryDecoder` and `DnsResponseEncoder`
 - Introduced `NameWriter` for writing names, so that it's possible to implement a stateful `NameWriter` to do DNS name compression
 - `DnsMessage` is threadsafe (needed for proxy DNS servers where multiple calls to remote DNS servers may contribute partial responses)
    - If someone really feels strongly that creating the `List` instances it uses internally should be lazy, that could be done, but it would be good to have some evidence that really accomplishes something - feels like premature optimization
 - `DnsQuestion` is no longer a subclass of `DnsEntry` (which now has a time-to-live, since that is common to all other record types).
 - Added the package io.netty.handler.codec.dns.server with `DnsServerHandler`, a `SimpleChannelInboundHandler<DatagramPacket>` that handles the common plumbing of writing a DNS server that is unlikely to differ between implementations
 - Corrected error codes in `DnsResponseCode` to match https://tools.ietf.org/html/rfc2929 (they were sequential, but in fact 11-15 are unused and numbering restarts at 16)
 - Added error codes that exist but were not included in `DnsResponseCode` but are part of the spec
 - Added `DnsDecoderException` which can specify a `DnsResponseCode`
 - `DnsQuery` implements `Iterable<DnsQuestion>`, simply because it's intuitive
 - Reasonable `toString()` implementations on entity classes for logging purposes
 - Added to netty-examples:  DNS server, DNS client, proxy DNS server

If someone actually needs to construct one of these, let them do a pull
request - there wasn't any use case for instantiating one in foreign code
(these get thrown if the inbound data is garbage, before client code could
get hold of anything), so my default if there isn't a real use case for
making something API is to leave it out of the public API.

On Mon, Dec 1, 2014 at 3:35 AM, Norman Maurer <notifications@github.com>
wrote:

> In
> codec-dns/src/main/java/io/netty/handler/codec/dns/DnsDecoderException.java:
>
> > + * License for the specific language governing permissions and limitations
> > + * under the License.
> > + */
> > +package io.netty.handler.codec.dns;
> > +
> > +import io.netty.handler.codec.DecoderException;
> > +
> > +/**
> > + * {@link DecoderException} which can be thrown during parsing of a DNS query or response,
> > + * which indicates the DNS error code that should be returned.
> > + */
> > +public class DnsDecoderException extends DecoderException {
> > +
> > +    private final DnsResponseCode code;
> > +
> > +    DnsDecoderException(DnsResponseCode code) {
>
> Also I wonder if we may want to make the constructors public. Any reason
> why these are package private ?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/netty/netty/pull/3146/files#r21075905>.
>



-- 
http://timboudreau.com