DNS/実装/GbDnsについて、ここに記述してください。

http://www.george-barwood.pwp.blueyonder.co.uk/DnsServer/

o Resolution algorithm (notes)

  - Suppose we want to determine the answer to QNAME QTYPE

  - We are given a list of root servers
  - Set Bailiwick to "" ( root )
  - Ask one of the Bailiwick servers the question ( QNAME, QTYPE )
  - Response will either be authoritative or non-authoritative ( or an error code )

   - If Authoritative
    - If RCODE is NXDOMAIN that is result 
    - Check if there is a CNAME response  QNAME CNAME xxxxx
    - If so, that forms part of the final answer, change QNAME to xxxxx and restart
    - Otherwise add matching answers to final answer, we are finished

   - If response is not authoritative
    - Authority section should contain list of name servers
    - LHS should be more specific than current bailiwick ( if not, server is lame )
    - Set Bailiwick to LHS of NS records
    - Continue ( but may first need to recursively resolve name server IP address if it is not in-zone )

  - The above says nothing about caching
  - Or whether to use A or AAAA when resolving name server IP address
  - Implemented

o Delegations should be time limited

  - When parent delegation expires, it should be re-fetched.
  - And cache entries below the delegation should be deleted.
  - If the delegation has changed.
  - DONE : child NS TTL limited by parent, so always expires first

o RRset status could be clarified / simplified

  - Affects various things, including over-writing rules
  - Level is a bit messy ?
  - Decide what attributes are needed
  - Authoritative Data / Non-Authoritative
  - Parent Data / Child Data ( watch out for RRSIGs ? )
  - Local data ( loaded from file ) / Data fetched from elsewhere
  - Anything else?
  - Also want to re-check delegations
    - But not keep re-fetching from parent if TTL has not expired
  - When we use an Authoritative NS RRset fom child
    - Check the parent NS RRset has not expired
    - If it has, we need to re-fetch the parent NS RRset
  - Done

o IP packet fragmentation

  - Vulnerable to spoofing
  - SOmetimes just doesn't work due to faulty implementations ( firewalls, NATs )
  - An attacker can spoof just a part of the whole packet, circumventing ID
  - Hard to spoof OPT ( because it is in last packet which carries UDP checksum )
  - Mitigations (ideas - these may not work )
    - Discard unsigned records unless they are in first 512 bytes of reply
    - Signed records must be checked before being cached/used
  - Only clean solution seems to be some kind of protocol extension
    - Package response in TXT records
    - Xor-ed with Ping data
    - Hmm...
  - Or sign everything?
  - Or resolver mitigation
    - Put limit on question length ( may cause problems ... )
    - Problem if Question + NS RRset does not fit in first 512 bytes
  - Suggestion
    - The server Xor's RRdata with the transaction ID
    - This means a blind attacker can no longer predict the data in the Additional section
    - The UDP checksum should now catch forgery attempts
    - Support signalled by an OPT record ( or bit ) sent by the client
  - Another way:
    - Include a page selection OPT record ( indicates which "page" of response we want )

o Which records in a response are essential

  - Records whose owner name exactly matchs the question ( type and name, or cname and name )
  - NS records where the question name ends with the owner name ( referral )
  - All othe records are in-essential 

  [ Implemented discard when convergence is slow ]