ietf
[Top] [All Lists]

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-08 20:16:12

In message 
<201203082359(_dot_)q28NxpwU027318(_at_)fs4113(_dot_)wdf(_dot_)sap(_dot_)corp>, 
Martin Rex writes
:
Mark Andrews wrote:

Martin Rex writes:

Thanks for mentioning rfc 4074.  The stuff in that document matches
the thoroughly broken behaviour of the IPv6 DNS resolver client of
Windows 2003 that I had encountered just recently.

IMO, rfc4074 exhibits a significant amount of cluelessness about DNS,
the "Full Standard" document maturity level, and the realities of
backwards compatibilities for an incredibly huge installed base.

So not answering a query because the type is 28 matches RFC 1034
behaviour?  DNS is a query/response protocol.

So returning NXDOMAIN because the query type is 28 when you have
type 1 in the database matches RFC 1034 behaviour?

Returning A record content in software written *after* type code
28 was defined matched RFC 103[45] behaviour?  The same servers
shove A rdata into TXT rdata.  Everything is a A record.

We started this with the NOTIMP, which is certainly a permissible
response for an AAAA query per rfc1035.

What I briefly saw the win2003 DNS client doing in a wireshark trace
(which I forgot to save before I had to reboot after windows disabled
all networking) was visualized as a mixture of "no name" and "server fail"
for 23 consecutive AAAA lookups until ~18 seconds later the first A lookup
was finally sent.
I assume the two locally configured DNS Server were caching(-only) servers,
not authoritative ones (at least our current DNS Zones do not contain
NS records for any of the two).


Besides what you can deduce from the spec itself, you will also have
to take into account how that incredibly huge installed base was
created.  A number of software vendors perform only black-box testing
and limited interop testing, so it will not be unusual that your
AAAA queries may be the first queries of that kind that a DNS responder
might be seeing. 

The incredibly huge base that returned NOERROR to type 28 queries
when AAAA was defined.  Almost all of the offending boxes were
designed after AAAA was defined.

Lots of them get responses to RFC 1035 types wrong.  If you don't
implement the type then you can't load the zone if it contains the
type, partial zone loads are not permitted as per RFC 1035.  If you
have loaded the zone then the type doesn't exist, so it doesn't
matter that you don't implement it, you therefore can't match the
type as per RFC 1034 so the answer is NOERROR or NXDOMAIN depending
apon whether the name exists in the zone or not.


So if the behaviour (how to exactly respond to queries for unknown
QTYPEs) is neither explicitly specified, nor likely have been part of
the usual/common interop tests performed by the vendor,
what you're left with might be "ureflected&untested guessing"
on part of the implementors to fill those gaps.

Bottom line, the receiver must be VERY conservative with assumptions
about what exactly can be infered from error responses for situations
that are fairly vague in the spec and potentially untested in the
installed base.  That is called "robustness principle".

Which is why there are lots of SERVFAILs as you can't infer anything
from NOTIMP.
 
-Martin
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>