[dns-operations] need someone else to look at these servers

[Mark Andrews]

In message <874mv1jfje.fsf at mid.deneb.enyo.de>, Florian Weimer writes:
> * Mark Andrews:
> 
> > The servers (or the firewalls in front of them) are not RFC 103[45]
> > compliant.  DNS is a query/response protocol.  If you don't get a
> > response the server is broken.
> 
> Running a UDP service which responds to unrecognizable packets is
> precisely what you should not do because it can result in never-ending
> packet loops.

Yes, that happens sometimes.  Named has a built in list of ports
to not respond to on parsing errors for this reason.  The list is
about 5 ports long without looking at the code and a second parsing
error (the packet structure is wrong) from the same port in 60
seconds will also not be replied to.  Packet with "qr=1" set are
not replied to though they are logged.

By parsing I mean the length fields etc.  You can send as many
records as you like.  If we know the internal structure of a record
that will also be checked.

Well formed EDNS packets are NOT unrecognisable packets.  The may
have field values that you have not seen but if they make it through
a packet parser they should be replied to.

Setting the EDNS version to 1 DOES NOT create a unrecognisable packet.
Setting EDNS flag bits including DOES NOT create a unrecognisable packet.
Adding a EDNS option DOES NOT create a unrecognisable packet.

All of those things have well defined behaviour specified for them
so that new and old version will interoperate.

For a EDNS version you do not support you return BADVERS.
For unknown EDNS options you ignore them. You do not add it to the response.
For unknown flags you ignore them.  You do not add them to the response.

Yet somehow firewall vendors choose to do everything BUT what they
were instructed to do thereby causing a denial of service.  If
they allow through EDNS version 0 packets they SHOULD let through
all of these.

Similarly there is NOTHING *wrong* with having AD, CD, AD, RD, RA,
QR or even the last unallocated header bit set in the DNS header
in any combination.  Yet there are firewalls that block CD, AD, AA
and the last unallocated header bit.

CD and AD even have RFC's stating that they are expected to be set
in queries.  RD and RA have been expected to be set from the very
beginning.

Unallocated OP codes should also not cause a issue.  NOTIMP is the
expected RCODE for them.

Unknown types should get NOERROR, NXDOMAIN or YXDOMAIN as a response.
The rational for this comes from RFC 1034.  A authoritative server
is not permitted to load a zone which contains types it cannot
parse.  Having successfully loaded a zone the RFC 1034 4.3.2.
Algorithm determines the response code.  NOTIMP is NOT the correct
response to a unknown qtype based on RFC 1034.

If you are configured for a zone by have failed to load it then
SERVAIL is the correct response.

If you are authoritative only and get a query for a zone you are
not configured for REFUSED or a referral to the root zone works. 

If you get a AXFR/IXFR request for a non zone apex NOTAUTH is
a appropriate response code. 

REFUSED is a reasonable response to a unknown QCLASS.

While RFC 103[45] didn't explain it well, it was still clear enough
that unknown types (non well known types) were expected to be treated
as opaque records.  Stub resolvers were specifically instructed to
allow for all possible values.

> > If you can't parse the packet,
> > you *construct* a response which is just the DNS header with the
> > rcode set to FORMERR, the id set to that of the query and qr set
> > to 1, aa set to 0, aa set to 0, ad set to 0, rd copied, ra set as
> > appropriate (not that it really matters), cd copied if you support
> > DNSSEC otherwise set to 0, z set to 0.  This isn't rocket science.
> > It is not hard to do this.
> 
> Reflecting the packet in this way may have been compliant in the RFC
> 1034/1035 days, but it is explicitly outlawed by RFC 6891 section 7
> (you cannot strip the OPT record as required if you cannot parse the
> packet).  I pointed out prior to publication that EDNS0bis explicitly
> imposed a requirement on implementations which do not implement this
> specification, but this comment was sadly ignored.

Did I say REFLECT a packet?   I said CONSTRUCT a packet.  In
particular one that is 12 bytes long, consisting of only a DNS
packet header.

To get a EDNS OPT record in the response you need to be able to
parse the EDNS OPT record out of the request.  If you can do that
you almost certainly have a well formed request.

As for returning FORMERR + OPT that only happens when values are
out of range rather than the stucture of the record is wrong.  If
the structure is wrong you get FORMERR without OPT.  The only values
that can be out of range are those within a EDNS option.  Version
is specifically handled by BADVERS.  Flag bits are never out of
range.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org