4 ms·

Authoritative DNS server written in Node.js

4 points by andris9 6y ago

andris9 6y ago
Author here. This application was initially part of my domain parking service https://projectpending.com/ https://projectpending.com/. Bunch of people asked about the DNS server powering the service, so I extracted it into a separate open source project. In general the development for PendingDNS was fueled by my deep hate towards zone files and slowly uptdating DNS servers where you have to wait 15mins before any change actually gets propagated. There is no reloading in PendingDNS as all record changes are written directly to Redis and also read from Redis to serve DNS requests.
- memexy 6y ago
  Can you explain how writing to Redis solves the zone update problem? Why do zone updates take a long time currently? Is it something inherent to the updates themselves or is it purely an implementation detail with the other DNS providers?
  - andris9 6y ago
    When you change zone files (eg. in Bind9) then you need to reload the server in order to have the changes registered. For large amount of zone files reloading gets very expensive, so it is not done after every change but after every, like, 5 or 10 minutes. On the user side this is super annoying: 1. you create a new A record 2. you try to open the domain name in a browser 3. changes are yet not reloaded, so DNS server responds with NXDOMAIN 4. browser caches the failing result for an hour or so 5. changes get reloaded after 10minutes and the domain gets available... 6. ...except for your computer because every DNS server between the source and your computer has cached the errored response As PendingDNS reads always records from Redis then there is no reloading step and thus there is nothing to wait for.
    - memexy 6y ago
      Good to know. How is the client side issue addressed? > 4. browser caches the failing result for an hour or so
      - andris9 6y ago
        If the client manages to get a successful response then it is cached normally - whatever the TTL value attached to the record defines. In case of PendingDNS all TTL values are 5min by default. So the problem is with unsuccessful responses - there is no TTL attached, so the client uses whatever it finds suitable - maybe uses values from SOA records, maybe has its own default, who knows - in any case, it is quite long.
        memexy 6y ago
        Thx.

4 points by andris9 6y ago

Author here. This application was initially part of my domain parking service https://projectpending.com/ https://projectpending.com/. Bunch of people asked about the DNS server powering the service, so I extracted it into a separate open source project. In general the development for PendingDNS was fueled by my deep hate towards zone files and slowly uptdating DNS servers where you have to wait 15mins before any change actually gets propagated. There is no reloading in PendingDNS as all record changes are written directly to Redis and also read from Redis to serve DNS requests.

memexy 6y ago
Can you explain how writing to Redis solves the zone update problem? Why do zone updates take a long time currently? Is it something inherent to the updates themselves or is it purely an implementation detail with the other DNS providers?
- andris9 6y ago
  When you change zone files (eg. in Bind9) then you need to reload the server in order to have the changes registered. For large amount of zone files reloading gets very expensive, so it is not done after every change but after every, like, 5 or 10 minutes. On the user side this is super annoying: 1. you create a new A record 2. you try to open the domain name in a browser 3. changes are yet not reloaded, so DNS server responds with NXDOMAIN 4. browser caches the failing result for an hour or so 5. changes get reloaded after 10minutes and the domain gets available... 6. ...except for your computer because every DNS server between the source and your computer has cached the errored response As PendingDNS reads always records from Redis then there is no reloading step and thus there is nothing to wait for.
  - memexy 6y ago
    Good to know. How is the client side issue addressed? > 4. browser caches the failing result for an hour or so
    - andris9 6y ago
      If the client manages to get a successful response then it is cached normally - whatever the TTL value attached to the record defines. In case of PendingDNS all TTL values are 5min by default. So the problem is with unsuccessful responses - there is no TTL attached, so the client uses whatever it finds suitable - maybe uses values from SOA records, maybe has its own default, who knows - in any case, it is quite long.
      - memexy 6y ago
        Thx.