DNS/課題/Barwood

Contents

    1. DNS/課題/Barwood
  2. Notes on the DNS Standard
    1. 1. Partial delegation
    2. 2. Rules for cache over-writing
    3. 3. Bailiwick checking
    4. 4. Delegation checking
    5. 5. Glue
    6. 6. Truncation
    7. 7. ANY with DO=0
    8. 8. Spoofing
    9. 9. Fragmentation
    10. 10. Amplification attacks
    11. 11. TCP Fallback
    12. 12. Reservation

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

Notes on the DNS Standard

The following are areas when I feel the existing DNS standard is problematic,
or where the proper or best way to implement DNS is unclear from the standard.

1. Partial delegation

If the parent servers for a zone are a subset of the child servers, the DNS protocol does not specify how a resolver can discover the complete set of servers.

A server has no way of discovering the Bailiwick of the query, so is not able to generate the required referral.

Some authoritative servers (e.g. BIND) include the NS RRset with every authoritative response. With DNSSEC this can lead to a large increase in the response size, once additional section processing is performed.

It's not clear whether BIND is correct, or whether in fact partial delegation is a configuration error.

A happy medium may be to return the NS RRset, but not perform additional section processing on it.

2. Rules for cache over-writing

RFC 2181, section 5.4.1 says "When considering whether to accept an RRSet in a reply, or retain an RRSet already in its cache instead, a server should consider the relative likely trustworthiness of the various data."

This could cause problems where old child data is not replaced with fresh data from the parent zone.

For example, where the name servers for a domain are renamed, and the child NS records have a longer TTL than the A records.

I think it's best for fresh data to replace old data. This rule is simpler, and I believe better.

3. Bailiwick checking

The standard does not describe the necessity for resolvers to check the bailiwick of records before accepting them.

The natural check is to accept a record [Name1 Type Value] when querying a server with name SN provided the resolver has (or can obtain) a valid record [Name2 NS SN] where Name1 is equal to, or a subdomain of, Name2.

4. Delegation checking

Existing resolvers do not generally re-check delegations when they expire. A delegation should be time-limited, so that if ownership changes, the new owner has an assurance that old data will no longer be used once the delegation TTL has passed.

5. Glue

The standard is not clear on when glue may be silently omitted from a referral response to prevent truncation.

Generally truncation is undesirable, but there is a danger that most or all the glue is lost, for example

dig 012345689. (repeated 25 times) .com @a.root-servers.net

Fortunately, the chances of this happening are not high for typical NS and DS RRsets, but a happy medium may be to truncate ( set TC=1 ) if less than 2 "functional" NS records can be included ( a "functional" NS record is one where either glue is included, or glue is not required because the name server is not within the zone ).

6. Truncation

When a response is truncated, it's unclear what is best practice. It may be best to set TC=1 and return just the Question ( no Answer/Authority or Additional section). Apparently most clients ignore data in truncated responses and always retry using TCP.

Example: dig dnskey se @a.ns.se +dnssec +bufsize=1400

7. ANY with DO=0

RFC 3225 says :

"Security records that match an explicit SIG, KEY, NXT, or ANY query, or are part of the zone data for an AXFR or IXFR query, are included whether or not the DO bit was set."

I think this is ill-advised, as it means that DNSSEC is not fully backward compatible with pre-DNSSEC applications.

It means that qmail will not deliver mail to domains that are signed with DNSSEC.

Instead it's best to send DNSSEC records only when the query really is explicit, which does not include ANY with DO=0.

8. Spoofing

The DNS ID field is only 16 bits, which is insufficient protection against spoofing.

Source port randomization can help, but is ineffective for resolvers that are behind a NAT device that will typically remove randomization when mapping ports.

Query repetition is an effective client-side remedy, but is complex to implement, and inefficient, especially for non-deterministic authorities.

Therefore a protocol extension to stop blind spoofing of UDP responses may be worthwhile. A MAC (Message Authentication Code) should be considered, so that fragmented packets cannot be spoofed.

Alternatively, a fully-fledged means of protecting packets over the network, such as DNSCurve, should be considered. This would be complementary to the end-to-end authentication offered by DNSSEC, and would provide network confidentiality and improved security against denial of service attacks.†

9. Fragmentation

IP fragmentation is problematic for DNSSEC for several reasons.

(a) It's quite likely that IP packets > MTU will fail to traverse the network.

(b) Fragmented packets are vulnerable to spoofing : the DNS ID field only protects the first fragment.

(c) If a fragment is lost, the whole IP packet must be resent.

The best way forward is not clear.†

10. Amplification attacks

Sending large responses over UDP may allow "amplification" attacks, that is an attacker can send a large number of requests to an authoritative server, causing the server to transmit a large amount of packets.

A protocol extension that can be used to limit the amplification may be useful.†

11. TCP Fallback

Connection-oriented protocols imply significant per-client state. This leaves a server vulnerable to denial of service attacks where the attacker makes a large number of connections to a server but then fails to proceed in a timely manner.

SYN-cookies provide some protection, but this weakness is to a large extent inherent in connection-oriented protocols.

A protocol extension that makes TCP fallback unnecessary might be worthwhile.†

12. Reservation

The standard is not as clear as it could be on reserved codes and bits.

The correct principle is for senders to leave reserved areas zero or empty, until the standard defines a meaning, and for receivers to ignore reserved areas.

Examples are: Z flags, Additional section of query, EDNS Option codes, etc.

Some implementations incorrectly interpret "must be zero" as implying that receivers should check that the value is zero, which renders the reservation useless.

George Barwood, July 2009

†Since July, I have worked on a proposal to address these issues, please see this IETF draft on DNS Transport or here. https://tools.ietf.org/html/draft-barwood-dnsext-dns-transport-18