Open ghost opened 3 years ago
the domain is apparently valid and the issue seems to be rather with unbound
reopening since it appears to a bug in violation of https://tools.ietf.org/html/rfc1034#section-3.1
To simplify implementations, the total number of octets that represent a domain name (i.e., the sum of all label octets and label lengths) is limited to 255.
whilst
paypal.com.us.continue.myaccount.account.active.login.us.intl.internationa.transfer.now.login.myaccount.account.active.login.us.intl.internationa.transfer.now.myaccount.account.active.login.us.intl.internationa.transfer.now.newmanhope.duckdns.org
has a length of 248 the added RPZ domain is exceeding the limit of 255
It might worth to consider limiting the subdomain to a length of 240, e.g. with wildcards https://github.com/NLnetLabs/unbound/issues/285#issuecomment-669204785 , in order to allow for a suitable RPZ label in order to prevent this from happening, particularly if an actor gets the notion of setting a 255 url length.
With the 248 length from this example it leave just 6 characters for RPZ label.
I'm planning to add sed '/^[a-z0-9.]{250,}/d' -i $rpz
after https://github.com/EnergizedProtection/block/blob/master/ultimate/build.sh#L626, but first I'd need to become properly comfortable with using sed
, and also make sure that the build.sh
scripts are actually even being used during list generation.
The same previously mentioned RFC https://tools.ietf.org/html/rfc1034#section-3.1 also stipulates
Each node has a label, which is zero to 63 octets in length
In following the RFC specification it would thus mean that the subdomain represented in an RPZ should not exceed 191 octets (254 - 63).
For the given example
paypal.com.us.continue.myaccount.account.active.login.us.intl.internationa.transfer.now.login.myaccount.account.active.login.us.intl.internationa.transfer.now.myaccount.account.active.login.us.intl.internationa.transfer.now.newmanhope.duckdns.org
and taking into consideration the advise from the unbound developers:
The RPZ producer can work around it by specifying a zone name and making sure that all RPZ records are within the limits by applying wildcards for example.
wildcards should probably applied from left to right, e.g. turning the representation into
*.internationa.transfer.now.login.myaccount.account.active.login.us.intl.internationa.transfer.now.myaccount.account.active.login.us.intl.internationa.transfer.now.newmanhope.duckdns.org
This is now 187 octets.
Whilst it would be preferable that block list sources provide the domain representation in line with RFC specifications it may not be counted on in which case it places the burden on EnergizedProtection to implement a suitable check and rectification routine.
Energized Protection - block ⚡
Issue Submit Form
Issue(s):
Type
x
in between[ ]
and make sure there isn't any space between brackets. Example; for Your Selected Issue(s), type like this -[x]
You can select more than one category of issues if you need to!Pack(s):
Write the name of the pack(s) you are using.
Your Config:
Just to ensure there is no issues or conflicts with other app/software/magisk module/extension/source list. Make sure you are running Energized Protection Service only.
Client: unbound
Version: 1.11.0
Config
Details:
Write us a lil bit more about your issue or query. You can attach any screen shot or log of the issue or advert, this will help to highlight it.
unbound log prints:
Thank you for making Energized Protection great, with your kind help!
A project by Ador with ❤