[Opendnssec-develop] what to do with garbage in

Rickard Bellgrim rickard.bellgrim at iis.se
Thu Sep 30 08:14:05 UTC 2010


On 29 sep 2010, at 16.44, Matthijs Mekking wrote:

> Classes a) and b):
> I think these should be rejected if we are primary. This is according to
> rfc 1035 and rfc2672 (-bis).

Yes, since it must be enforced that there is only one CNAME or DNAME.

"If a DNAME RR is present at a node N, there may be other data at N
      (except a CNAME or another DNAME), but there MUST be no data at
      any descendant of N.  This restriction applies only to records of
      the same class as the DNAME record."
...
"It MUST be enforced when authoritative zone data is loaded." 

> In the unlikely situation that we get an {A,I}XFR that tries to insert
> this garbage, probably also reject it and continue with the old zone.

Yes, since the one sending the {A,I}XFR also have to obey the rule above. It thus unlikely that we will get such a zone transfer. If we do, then we can safely reject it since there is probably something wrong with the master.

> Classes c):
> we should accept on zone transfer and dynamic update (rfc 5936), but
> reject on zone file (rfc 2672). Thus also follow these rules on the
> outbound side.

Zone file: Yes, the rule above also states that " there MUST be no data at any descendant of N".

Dynamic update: Yes, RFC2136 7.14 "No semantic checking is required in the primary master server when adding new RRs."

Zone transfers: Doesn't these sort under the same rules as zone files?

// Rickard




More information about the Opendnssec-develop mailing list