On Wed, Feb 1, 2017 at 3:44 PM, Robert Edmonds <edmo...@mycre.ws> wrote: > Warren Kumari wrote: >> The largest outstanding issue is what to do about DNSSEC -- this is >> (potentially) a problem for any / all 6761 type names. >> The root is signed, so if a query leaks into the DNS (as they will), >> an (unaware) validating resolver will try resolve it, and will expect >> either a signed answer, or proof of an insecure delegation; without >> this things will look bogus, and so resolvers will SERVFAIL. >> >> Clearly, a signed answer isn't feasible, so that leaves 2 options - 1: >> simply note that validation will fail, and that SERVFAIL will be >> returned in many case (to me this seems "correct"), or 2: request that >> the IANA insert an insecure delegation in the root, pointing to a: >> AS112 or b: an empty zone on the root or c" something similar. > > Hi, Warren: > > I'm kind of confused. If a .ALT query leaks into the DNS, and there's > neither a secure or insecure delegation in the root, isn't the result a > signed NXDOMAIN, not a SERVFAIL? > > ; <<>> DiG 9.11.0-P1 <<>> +dnssec foo.alt > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36917 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
Yup, but if a resolver has a (empty) local zone for .alt, and someone queries it and validates, then I think you get SERVFAIL -- the root says .alt doesn't exist, but here you have an answer apparently from inside the zone -- 'tis an empty / NXD answer, but still looks like shenanigans are happening... W > > -- > Robert Edmonds -- 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
