[dns-operations] (co.)bw DNSSEC failure

[Warren Kumari]

On Tue, Sep 20, 2016 at 5:57 PM, Mark Andrews <marka at isc.org> wrote:
>
> In message <26C14ADA-DD55-47E4-B6E9-5D3A7602393E at powerdns.com>, "Peter van Dijk
> " writes:
>> Hi Warren,
>>
>> On 20 Sep 2016, at 20:29, Warren Kumari wrote:
>>
>> > So, that explains *this* case, but we often seem to see other *weird*
>> > issues... I'm trying to find the example (I have it squirreled away
>> > somewhere), but one of my favorites was getting back NXDOMAIN
>> > responses along with a full (complete and correct) answer. I never
>> > figured out what I should do with that - do I use the answer or not?
>>
>> Hard to say without seeing it. I have seen a lot of this (typed from
>> memory):
>>
>> $ dig a www.example.com
>> ; .. .. ..
>> ; status: NXDOMAIN
>>
>> ;; ANSWER SECTION:
>> www.example.com.   600  IN CNAME  www.example.org.
>>
>> ;; AUTHORITY SECTION
>> example.org. .. IN SOA ..
>>
>> In this case, the auth thinks it is also authoritative for example.org
>> and thus is able to return NXDOMAIN from there. NXDOMAIN applies to the
>> QNAME -as defined by 2308- so given the misconfiguration of this auth,
>> this is the right response. As a client, you use the CNAME, ignore the
>> NXDOMAIN (as its out of bailiwick) and chase www.example.org
>> yourself.
>

Bwahahahah... <sob>
Ok, that makes some kind of twisted sense....

> A stub client doesn't chase the CNAME as it is using the recursive
> server to do so.  People do point stub resolvers at authoritative
> servers that hold the entire namespace for that stub so authoritative
> servers do need to follow CNAME records when present in the authoritative
> data.
>
> With DNSSEC we don't care who gives the NXDOMAIN as long as it
> validates as secure.
>
>> Most misconfigurations of this type involve accidentally hosted root
>> zones, btw.
>>
>> > Another good one was querying for a AAAA only got me back a TXT record
>> > containing the string: "TODO - FIXME!!!".
>>
>> Hah. Still better than NXDOMAIN or a lame response..
>
> But it should be reason to pull the delegation for that zone if it
> is not fixed after being reported.  It is not hard to return a no
> error no data response.


Sure, but I'm trying to understand the thought process here -- someone
woke up one morning and thought "Hmmm.. I have an operational need to
return DNS answers. I don't like NSD or BIND or PowerDNS or DJB or
Mara. I also don't like Knot or YADIFA or Microsoft or Secure64 or
ANS.... Well, I have an editor and a compiler, how hard can it be?!"
...and then, after they have much of it working, someone asked for V6
support, so instead of just ignoring the request and going to the
beach, or taking the code and banging on it slightly, instead they
decided "Wow! What will make things better will be to return a
completely different type, containing a human readable string...." -
and then they went home at the end of the day with a feeling of having
made the world a better place?

W

>
>> Kind regards,
>> --
>> Peter van Dijk
>> PowerDNS.COM BV - https://www.powerdns.com/
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>> dns-operations mailing list
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf