draft-ietf-dnsop-no-response-issue-02.txt   draft-ietf-dnsop-no-response-issue-03.txt 
Network Working Group M. Andrews Network Working Group M. Andrews
Internet-Draft ISC Internet-Draft ISC
Intended status: Best Current Practice February 21, 2016 Intended status: Best Current Practice April 6, 2016
Expires: August 24, 2016 Expires: October 8, 2016
A Common Operational Problem in DNS Servers - Failure To Respond. A Common Operational Problem in DNS Servers - Failure To Respond.
draft-ietf-dnsop-no-response-issue-02 draft-ietf-dnsop-no-response-issue-03
Abstract Abstract
The DNS is a query / response protocol. Failure to respond or to The DNS is a query / response protocol. Failure to respond or to
respond correctly to queries causes both immediate operational respond correctly to queries causes both immediate operational
problems and long term problems with protocol development. problems and long term problems with protocol development.
This document identifies a number of common kinds of queries to which This document identifies a number of common kinds of queries to which
some servers either fail to respond or else respond incorrectly. some servers either fail to respond or else respond incorrectly.
This document also suggests procedures for TLD and other similar zone This document also suggests procedures for TLD and other similar zone
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 24, 2016. This Internet-Draft will expire on October 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 7, line 11 skipping to change at page 7, line 11
operator should now check that the server responds to EDNS, Unknown operator should now check that the server responds to EDNS, Unknown
Query Type and TCP tests as described above. If the TLD operator Query Type and TCP tests as described above. If the TLD operator
finds that server fails any of the tests, the TLD operator shall take finds that server fails any of the tests, the TLD operator shall take
steps to inform the operator of the server that they are running a steps to inform the operator of the server that they are running a
faulty nameserver and that they need to take steps to correct the faulty nameserver and that they need to take steps to correct the
matter. The TLD operator shall also record the <server, query name> matter. The TLD operator shall also record the <server, query name>
for follow-up testing. for follow-up testing.
If repeated attempts to inform and get the customer to correct / If repeated attempts to inform and get the customer to correct /
replace the faulty server are unsuccessful the TLD operator shall replace the faulty server are unsuccessful the TLD operator shall
remove all delegations to said server from the zone. remove all delegations to said server from the zone. Removal of
delegations is the step of last resort in handling complaints as
specified in [RFC1033] COMPLAINTS.
It will also be necessary for TLD operators to repeat the scans It will also be necessary for TLD operators to repeat the scans
periodically. It is recommended that this be performed monthly periodically. It is recommended that this be performed monthly
backing off to bi-annually once the numbers of faulty servers found backing off to bi-annually once the numbers of faulty servers found
drops off to less than 1 in 100000 servers tested. Follow-up tests drops off to less than 1 in 100000 servers tested. Follow-up tests
for faulty servers still need to be performed monthly. for faulty servers still need to be performed monthly.
Some operators claim that they can't perform checks at registration Some operators claim that they can't perform checks at registration
time. If a check is not performed at registration time, it needs to time. If a check is not performed at registration time, it needs to
be performed within a week of registration in order to detect faulty be performed within a week of registration in order to detect faulty
skipping to change at page 7, line 35 skipping to change at page 7, line 37
they have been required from the very beginnings of DNS to do this they have been required from the very beginnings of DNS to do this
[RFC1034]. Checking for compliance of nameserver operations should [RFC1034]. Checking for compliance of nameserver operations should
just be a extension of such testing. just be a extension of such testing.
It is recommended that TLD operators setup a test web page which It is recommended that TLD operators setup a test web page which
performs the tests the TLD operator performs as part of their regular performs the tests the TLD operator performs as part of their regular
audits to allow nameserver operators to test that they have correctly audits to allow nameserver operators to test that they have correctly
fixed their servers. Such tests should be rate limited to avoid fixed their servers. Such tests should be rate limited to avoid
these pages being a denial of service vector. these pages being a denial of service vector.
Nothing in this section precludes others testing servers for protocol
compliance. DNS operators should test their servers to ensure that
their vendors have shipped protocol compliant products. Nameserver
vendors can use these tests as a part of this release processes.
Registrants can use these tests to check their DNS operators servers.
4. Firewalls and Load Balancers 4. Firewalls and Load Balancers
Firewalls and load balancers can affect the externally visible Firewalls and load balancers can affect the externally visible
behaviour of a nameserver. Tests for conformance need to be done behaviour of a nameserver. Tests for conformance need to be done
from outside of any firewall so that the system as a whole is tested. from outside of any firewall so that the system as a whole is tested.
Firewalls and load balancers should not drop DNS packets that they Firewalls and load balancers should not drop DNS packets that they
don't understand. They should either pass through the packets or don't understand. They should either pass through the packets or
generate an appropriate error response. generate an appropriate error response.
skipping to change at page 15, line 35 skipping to change at page 15, line 35
expect: status: NOERROR expect: status: NOERROR
expect: SOA record to be present expect: SOA record to be present
expect: OPT record to be present expect: OPT record to be present
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
expect: flag: aa to be present expect: flag: aa to be present
If EDNS is not supported by the nameserver, we expect a response to If EDNS is not supported by the nameserver, we expect a response to
all the above queries. That response may be a FORMERR or NOTIMP all the above queries. That response may be a FORMERR or NOTIMP
error response or the OPT record may just be ignored. error response or the OPT record may just be ignored.
Some nameservers only return a EDNS response when a particular EDNS
option or flag (e.g. DO=1) is present in the request. This
behaviour is not compliant behaviour and may hide other incorrect
behaviour from the above tests. Re-testing with the triggering
option / flag present will expose this misbehaviour.
9. Security Considerations 9. Security Considerations
Testing protocol compliance can potentially result in false reports Testing protocol compliance can potentially result in false reports
of attempts to break services from Intrusion Detection Services and of attempts to break services from Intrusion Detection Services and
firewalls. None of the tests listed above should break nominally firewalls. None of the tests listed above should break nominally
EDNS compliant servers. None of the tests above should break non EDNS compliant servers. None of the tests above should break non
EDNS servers. All the tests above are well formed, though not EDNS servers. All the tests above are well formed, though not
necessarily common, DNS queries. necessarily common, DNS queries.
Relaxing firewall settings to ensure EDNS compliance could Relaxing firewall settings to ensure EDNS compliance could
skipping to change at page 16, line 14 skipping to change at page 16, line 21
10. IANA Considerations 10. IANA Considerations
IANA / ICANN needs to consider what tests, if any, from above that it IANA / ICANN needs to consider what tests, if any, from above that it
should add to the zone maintenance procedures for zones under its should add to the zone maintenance procedures for zones under its
control including pre-delegation checks. Otherwise this document has control including pre-delegation checks. Otherwise this document has
no actions for IANA. no actions for IANA.
11. Normative References 11. Normative References
[RFC1033] Lottor, M., "Domain Administrators Operations Guide",
RFC 1033, DOI 10.17487/RFC1033, November 1987,
<http://www.rfc-editor.org/info/rfc1033>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, DOI 10.17487/RFC3225, December 2001, RFC 3225, DOI 10.17487/RFC3225, December 2001,
 End of changes. 7 change blocks. 
5 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/