desec-io / desec-stack Goto Github PK

We currently do not allow any cross origin requests on the API, although that may be an important use-case. Implementing such requests however appears to be quite painful, as we must support OPTIONS requests properly to cover CORS preflight requests.

Maybe related to 550649b#diff-88ce4e4fa296cf686289c9e0f6e1e3fdR138

desecapi django module shouldn't load itself.

Otherwise, cryptokeys and comments of deleted domains will become orphans

We don't expect restricted types like DNSSEC-related stuff (see RRsetDetail.restricted_types) in the lord pdns database. Decide what to do if we encounter such a record. (Presence of an SOA record is expected and should just be ignored by the API.)

New major versions available

• users who signed up online can create zones under dedyn.io only
• manually created users can create arbitrary zones

Checklist:

• implementation
• unit tests
• docs

Per RFC 4343, Section 4, case can be changed at input, and per Section 6, it is more or less recommended to do so. This allows us to deal with uniqueness constraints more easily.

If possible, allow users to see their preferred spelling.

some of the more common subdomains should be reserved. This has several reasons:

• secures some commonly used subdomains for future growth
• some subdomains could be used to obfuscate the real URL or trick/confuse a user
• the subdomain www. should be reserved .... (www.dedyn.io)

http://wiki.dwscoalition.org/notes/List_of_reserved_subdomains shows possible subdomains to reserve, but not all subdomains on this list seem to be necessary woth of reserving.

Currently, the domain list view does not return creation/update timestamps. Should we add them?

(And why is it not the case so far?)

Checklist:

• implementation
• unit tests
• docs

Require solving a captcha to register a new user.

Currently, subzone ("more specific zones") can only be created if 1) we do not know the parent zone, or 2) the parent zone is owned by the same user. Otherwise, malicious users could hijack subzones from other users.

This can be improved by

1. integrating the public suffix list. Currently, if someone creates co.uk, other users cannot create their zone under co.uk.
2. Allow cross-user delegations by checking the NS records in the parent domain (with proper subdomain) (or by checking some other setting of the parent domain) -- not required for launch

As of now, some unit tests in the api depend on the availability of the pdns API. This should not be the case, all requsts should be intercepted and answered independently of pdns.

See https://github.com/desec-io/desec-stack/blob/60f58b1/dbmaster/51-server.cnf#L3-L4

Currently, it is hard to determine the git base commit from inside our Docker builds. To change this, a few parameters need to be passed at build time. Ideas:

• https://blog.scottlowe.org/2017/11/08/how-tag-docker-images-git-commit-information/
• http://container-solutions.com/tagging-docker-images-the-right-way/

• MySQL schema migrations, closes #65
• Use pdns REST API for DNSSEC management and get rid of nslord cronjob

@nils-wisiol How do we best apply schema changes on dblord and dbmaster? This is outside Django's migration framework, and I cannot think of something better than the manual approach right now.

currently, this is not handled by the API (it works because of an external circumstance that should not be relied upon)

Currently, the API accepts malformed strings for IPs in the update request, which causes the pdns API to error, which in turn causes an internal server error.

Input IP addresses should be checked for correct syntax before sending them to pdns, however the API should also be able to deal with error returned from the pdns API.

The API should have an endpoint that accepts updates to several RR sets that are applied atomic.

After implementation, the existing rrset endpoint and dyndns12 endpoint can be special cases of this new endpoint.

Per discussion with @peterthomassen, this new view shall be responsible for organizing correct order of "select for update", "update or create", and so on, removing this code from the models layer.

currently, the API is available under /api/. It should be available under /api/v1/ to allow for future incompatible changes under v2/.

@nils-wisiol I came across this dynDNS test

The name of it is testManualIPv6 though. Was it supposed to test something IPv6-related? I tried to track it down historically, but it's been like this since this respository exists.

When an error occurs, the API would ideally return a meaningful status code. However, in many cases the API simply returns 500 (e.g. when the IP address from the query string cannot be processed by pdns, we get 422 from pdns and still return 500 to the client).

Checklist:

• implementation
• unit test

Because it's useful for debugging with docker exec -ti ... bash

However, this may be a desirable feature for companies (even small ones perhaps).

Exception caught when trying to unlock account (reason unknown):

File "./desecapi/views.py" in unlock
316.                 User.objects.get(email=email).unlock()

File "./desecapi/models.py" in unlock
89.             domain.pdns_resync()

File "./desecapi/models.py" in pdns_resync
109.         if not pdns.zone_exists(self.name):

File "./desecapi/pdns.py" in zone_exists
88.     return _pdns_get('/zones/' + normalize_hostname(name)).status_code != 404

File "./desecapi/pdns.py" in _pdns_get
35.         raise Exception(r.text)

Exception Type: Exception at /api/v1/unlock/user/XXXX
Exception Value: {"error": "Could not find domain 'XXXX.dedyn.io.'"}

Currently, crashed services won't be restarted. A restart policy should be added to docker-compose.yml.

desec.io scores A- in the SSL Labs audit because Forward Secrecy is not supported with some reference browsers. It would be nice to fix this.

Currently, users can update there IPv4 and IPv6 addresses for their domain.dedyn.io. IPv6 users, however, often control a dynamic subnet and may want to run services on various IP addresses within this subnet.

It would be nice to allow users to create subdomains with static "local IP bits", only updating the subnet through our update mechanism. The user would have to specify the subnet size (e.g. /80), and upon IP update, only the first 80 bits of the AAAA records would be updated.

Various environment variables are outdated in .travis.yml, see new names in .env.default.

If we don't need it, it should be dropped.

If the client sends an invalid authentication header that contains not exactly one :, the server errors (see authentication.py).

When updating dyn DNS IP addresses, desec does not recognize the domain that needs updating by the provided username. (However, authentication works!)

In most cases this is not a problem, as some other mechanism for identification of the domain kicks in (for most users, their only domain gets updated as last resort).

This bug stops updating of dyn DNS domains if the following conditions are met:

1. the user as more than one domain
2. the user uses domainname:authtoken HTTP Basic authentication
3. the user does not provide the domain name in the query parameters

In this case,

There is no unit test for this scenario; exceptions get caught by the 'catch all' construct. Both should be avoided in the future.

Some of our containers don't use the most up-to-date base images (e.g., the nameserver containers use Debian jessie, not stretch). This is not a problem at the moment, but updating to more recent versions will help avoid running into using eventually unsupported software.

Double-check that we have enough entropy for DNSSEC key generation inside the pdns lord container.

Setting the arecord field on a domain immediately after it's creation fails and causes a 500 server error.

Steps to reproduce (bash):

export [email protected]
export DESEC_PASSWORD=123password
export DESEC_DOMAIN=baz.dedyn.io

http POST https://desec.nils.dedyn.io/api/v1/auth/register/ email:=\"${DESEC_USERNAME}\" password:=\"${DESEC_PASSWORD}\"
export DESEC_AUTH=$(http POST https://desec.nils.dedyn.io/api/v1/auth/login/ email:=\"${DESEC_USERNAME}\" password:=\"${DESEC_PASSWORD}\" | grep auth_token | egrep -o [a-z0-9]{40})
http POST https://desec.nils.dedyn.io/api/v1/domains/ Authorization:"Token ${DESEC_AUTH}" name:=\"${DESEC_DOMAIN}\"
http PATCH https://desec.nils.dedyn.io/api/v1/domains/${DESEC_DOMAIN}/ Authorization:"Token ${DESEC_AUTH}" arecord:=\"127.1.1.1\"

The reason appears to be that this request is made without pdns already having a SOA record for the domain (pdns reply: {"error": "No SOA found for domain 'baz.dedyn.io.'"}).

I cannot pinpoint where exactly the SOA record is added later (any idea, @peterthomassen?); it appears to have something to do with the cron job.

The error will cause any update to be lost (as would be expected by the client); however with the next non-erroring POST to that domain any previous error will be recovered, so in many cases this is not an urgent problem.

This is a change coming with pdns 4.1, see https://github.com/PowerDNS/pdns/pull/5518/files#diff-43949877f3417da458d3bc2a90c65833R4

This is a reminder to not forget the upgrade. (On our dbmaster, records.id is currently at about 1/7 of the max int value, and auto_increment does not wrap.)

Rationale, especially for DNS records in our database: When we sync the database from pdns, all the created timestamps would be updated, which is implausible from the user's perspective

Currently, deploying desec-stack requires setting up a customized api-settings.py file. That's unnecessary as all relevant settings can be controlled from the .env file. We therefore should get rid of api-settings.py.

In order to get security updates, use ~= instead of == as recommended in requirements.txt.

Limitations:

• do not allow zone rename
• do not support pdns fields disabled, set-ptr, comments

Checklist:

• implementation
• unit tests
• docs (try readthedocs.org?)

Creating a domain breaks at views.py:31 if the domain already exists in the pdns database, with the pdns API returning an error code and {"error": "Domain 'xxx.dedyn.io.' already exists"} at models.py:121.

Solution: check whether domain exists in desec.desecapi_domain and return 409 Conflict if so.