bevhost / probind Goto Github PK

Not sure if probind is completely dead or not...but have there ever been ideas about implementing multitenancy that would allow ACL per zone?

So Customer/user XYZ only has access to zones XXX and ZZZ and so on.

I noticed this on brzones.php, where we do, without any escaping, something like this:

<INPUT type="text" value="$record['data']">

The problem with this is that $record['data'] (specially in the case of TXT records) can have ruinous characters, like ". So, if we have a TXT record saying this is an "example", our HTML will be:

<input type="text" value="this is an "example"">

Which is obviously wrong, and can even lead to data loss.

Which makes installing PHPExcel as per instructions a tad difficult.
It is available via https://github.com/PHPOffice/PHPExcel so perhaps an install doc update to reflect.

The latest change made on the idna_convert library shipping with probind (by me) was to make convert parse paths. Not only that breaks the correct use of convert, but convert is meant not to work on paths, and we should be using encode_uri .

More info here: marado/idna_convert@1b1f95f#commitcomment-16530427

According to RFC 4408,

SPF or TXT records containing multiple strings are useful in constructing records that would exceed the 255-byte maximum length of a string within a single TXT or SPF RR record.

and

The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. This will keep even older DNS implementations from falling over to TCP. Since the answer size is dependent on many things outside the scope of this document, it is only possible to give this guideline: If the combined length of the DNS name and the text of all the records of a given type (TXT or SPF) is under 450 characters, then DNS answers should fit in UDP packets. Note that when computing the sizes for queries of the TXT format, one must take into account any other TXT records published at the domain name. Records that are too long to fit in a single UDP packet MAY be silently ignored by SPF clients.

While SHOULD is not a MUST, I don't see anything wrong as treat it as a MUST on ProBIND, specially since the server and/or client MAY silently ignore us otherwise. I wouldn't mind accepting longer records, but I really don't see "how much longer": in particular, I don't find an RFC stating the maximum number of strings a record can have.

Nowadays we're only accepting 255 characters, which is not enough to comply with the RFC, but I am guessing 448 is. I will be submiting a patch very soon, to fix this.