[Dnssec-deployment] Fetching the RRSIGs can be a problem too.

[Mark Andrews]

DNSSEC validation *requires* a DNSSEC clear path from the validator
to the authoritative servers.  It is *impossible* to do DNSSEC
validation reliably without a DNSSEC clear path.

In message <CACU5sDk7XJA4HZ=M-Z8W7Zno9QJrAqexBpJEBj5UzsDX03qF3g at mail.gmail.com>,
 Mohan Parthasarathy writes:
> --bcaec5215bbf11c1a904abd093be
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi,
> 
> Here is my setup:
> 
> Validating Resolver ---> DNS proxy --> Security aware Recursive name server
> 
> The DNS proxy does not forward the EDNS0 option on the other side. The
> resolver is smart in the sense that if it does not receive the DNSSEC
> records, it would issue a request for it separately.
> 
> I tried both with 75.75.75.75 (comcast) and 149.20.64.20 (DNS-OARC) for the
> recursive name server and found slightly different set of issues. In both
> cases it did not work. Let us say we are looking up www.ietf.org.
> 
> 1) With 75.75.75.75: After the DS record for ietf.org is fetched, the
> resolver issues the query for RRSIG for "ietf.org". Comcast servers just
> return what is in its cache and the resolver gets back RRSIGs whose
> typeCovered is "DNSKEY" and not "DS". Hence, can't proceed further.
> 
> 2) With 149.20.64.20: Here, when the RRSIGs were fetched for "ietf.org", it
> returns all of them that includes DNSKEY and DS. But then it does not return
> when a DS query is issued for root. This can be easily fixed in the
> resolver. But then it was odd if you see a request for DS and not even
> respond back with NXDomain ? (Currently the resolver always issues the DS
> query and ignores when it gets NXDomain.).
> 
> It looks like the specs are silent on this.  Is there any document that can
> be recommended to the operators to fix this problem ? At least the first one
> ?
> 
> thanks
> mohan
> 
> --bcaec5215bbf11c1a904abd093be
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> Hi,<div><br></div><div>Here is my setup:</div><div><br></div><div>Validatin=
> g Resolver ---&gt; DNS proxy --&gt; Security aware Recursive name server</d=
> iv><div><br></div><div>The DNS proxy does not forward the EDNS0 option on t=
> he other side. The resolver is smart in the sense that if it does not recei=
> ve the DNSSEC records, it would issue a request for it separately.</div>
> <div><br></div><div>I tried both with 75.75.75.75 (comcast) and=A0149.20.64=
> .20 (DNS-OARC) for the recursive name server and found slightly different s=
> et of issues. In both cases it did not work. Let us say we are looking up <=
> a href=3D"http://www.ietf.org">www.ietf.org</a>.</div>
> <div><br></div><div>1) With <a href=3D"http://75.75.75.75">75.75.75.75</a>:=
>  After the DS record for <a href=3D"http://ietf.org">ietf.org</a> is fetche=
> d, the resolver issues the query for RRSIG for &quot;<a href=3D"http://ietf=
> .org">ietf.org</a>&quot;. Comcast servers just return what is in its cache =
> and the resolver gets back RRSIGs whose typeCovered is &quot;DNSKEY&quot; a=
> nd not &quot;DS&quot;. Hence, can&#39;t proceed further.</div>
> <div><br></div><div>2) With <a href=3D"http://149.20.64.20">149.20.64.20</a=
> >: Here, when the RRSIGs were fetched for &quot;<a href=3D"http://ietf.org"=
> >ietf.org</a>&quot;, it returns all of them that includes DNSKEY and DS. Bu=
> t then it does not return when a DS query is issued for root. This can be e=
> asily fixed in the resolver. But then it was odd if you see a request for D=
> S and not even respond back with NXDomain ? (Currently the resolver always =
> issues the DS query and ignores when it gets NXDomain.).</div>
> <div><br></div><div>It looks like the specs are silent on this. =A0Is there=
>  any document that can be recommended to the operators to fix this problem =
> ? At least the first one ?</div><div><br></div><div>thanks</div><div>mohan<=
> /div>
> <div><br></div>
> 
> --bcaec5215bbf11c1a904abd093be--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org