disable dnssec for particular domain

Mark Andrews marka at isc.org
Thu Feb 8 08:12:56 UTC 2018


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 <dot at 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  <dot at 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 at 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: marka at isc.org



More information about the bind-users mailing list