You break a chain of trust by proving there is a insecure delegation. NXDOMAIN is not a delegation.
The point on OPTOUT is to allow the parent zone to add and remove insecure delegations without resigning. Mark > On 7 Feb 2018, at 11:26 pm, Tony Finch <d...@dotat.at> wrote: > > Pruned debug logs... > > validating testa.eu/DS: looking for closest encloser > validating testa.eu/DS: NSEC3 QBQ65Q6097OCPPR0EUCQNSC1FHE073UA indicates > potential closest encloser: 'eu' > validating testa.eu/DS: NSEC3 QBQ65Q6097OCPPR0EUCQNSC1FHE073UA at > super-domain eu > validating testa.eu/DS: NSEC3 GLIBHU0LF7IH1TGCCS68E3R5508AKBFR proves name > does not exist: 'testa.eu' > validating testa.eu/DS: NSEC3 GLIBHU0LF7IH1TGCCS68E3R5508AKBFR indicates > optout > validating testa.eu/DS: NSEC3 4EIKQ8ORL4U4NTG72QEDRA6P3NDA1UNC proves name > does not exist: '*.eu' > validating testa.eu/DS: in checkwildcard: *.eu > validating testa.eu/DS: NEEDNODATA = 0 > validating testa.eu/DS: FOUNDNODATA = 0 > validating testa.eu/DS: FOUNDOPTOUT = 1 > validating testa.eu/DS: NEEDNOQNAME = 1 > validating testa.eu/DS: FOUNDNOQNAME = 1 > validating testa.eu/DS: NEEDNOWILDCARD = 1 > validating testa.eu/DS: FOUNDNOWILDCARD = 1 > validating testa.eu/DS: FOUNDCLOSEST = 1 > validating testa.eu/DS: nonexistence proof(s) found > > Looks OK so far... > > fctx 0x7f1a5bfc1a10(testa.eu/DS): nonexistence validation OK > validating testa.eu/SOA: in dsfetched2: ncache nxdomain > validating testa.eu/SOA: resuming proveunsecure > validating testa.eu/SOA: insecurity proof failed > > Then it goes pear-shaped. > > Aha! I think what's happening here is that BIND is expecting a NODATA > response, to indicate that there is a delegation without a DS record. > (For an example, `dig +dnssec +multiline europa.eu ds) > > However the validator gets an NXDOMAIN response claiming the domain > doesn't exist at all. But this is an opt-out NXDOMAIN so it is not a > proof. Nevertheless the validator believes it, and is convinced that it > has not proved the NODATA that it was expecting to prove, so it tells > itself it has not found an insecure delegation. > > This is a tricky case. You can argue convincingly either way whether it is > a bug or not, I think. Even if it is a bug, fixing it is not going to > solve your problem any time soon - you need a pragmatic operational > solution. > > What you should do is add some nameservers to the registration (serving an > empty zone or something), so that the .eu nameservers return a NODATA > response instead of an NXDOMAIN response. Then your private zone will > work. > > Tony. > -- > f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode > Tyne, Dogger: Northwest 4 or 5, backing southwest 5 to 7. Slight or moderate. > Wintry showers, then occasional rain. Good, occasionally poor. > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
