ICANN participation

Preparation | Test AAAA support | Test EDNS0 Support | Share Your Results | Results Reported

Background

The DNS Root Server System Advisory Committee (RSSAC) and ICANN Security and Stability Advisory (SSAC) are jointly studying the topic of including the IPv6 addresses at the root level of the DNS. This involves two related actions on the parts of the IANA and the DNS Root Server Operators:

1. Add resource records of Type AAAA to the hints file. The IANA maintains the authoritative root hints file at ftp://ftp.internic.net/domain/.
2. Provision the 13 root name servers to return the Type AAAA records when name server resolvers bootstrap, perform what is known as a priming request.
   

Currently, the operators of five root name servers - B, F, H, K, and M - have assigned IPv6 addresses to their systems. These addresses are not included in the hints file at this time, nor are they returned in DNS priming responses. If the five IPv6 addresses were added to the Additional Section of the DNS Type NS response message root server operators return during the priming exchange, the size of the response message would increase from the current 436 bytes to 576 bytes. Ultimately, when all 13 root name servers are assigned IPv6 addresses, the priming response will increase in size to 800 bytes. This imposes two conditions for the successful completion of a priming exchange that do not exist today. Specifically, resolvers and any intermediate systems that are situated between resolvers and root name servers must be able process DNS messages containing Type AAAA resource records. Additionally,

• Resolvers must use DNS Extensions (EDNS0, RFC 2671) to notify root name servers that they are able to process DNS response messages larger than the 512 byte maximum DNS message size specified in RFC 1035, and
• Intermediate systems must be configured to forward UDP-encapsulated DNS response messages larger than the 512 byte maximum DNS message size specified in RFC 1035 to resolvers that issued the priming request.

The joint committees are soliciting feedback from the Internet community on whether commercial firewalls organizations use to protect name server resolvers will block (silently discard) priming responses because they do not satisfy these conditions.

Preparing and Testing Firewall Implementations and Versions

Several top level domains return IPv6 addresses in DNS response messages today, and several of these responses
are larger than 512 bytes. Using TLD name servers as targets for DNS Type NS queries, organizations can test
firewall implementations and versions to determine whether they would be affected when the DNS priming
response is extended to include AAAA records for root name servers.

Test if your Firewall implementation accommodates Type AAAA RRs

To test the action a firewall implementation takes when it encounters Type AAAA resource records, a network or firewall administrator can perform the following DNS lookup using the popular dig program:

dig hk ns @203.119.2.18

This command should elicit a 508 bytes response that contains AAAA resource records:

		; <<>> DiG 9.2.3 <<>> hk ns @203.119.2.18
	;; global options:  printcmd
	;; Got answer:
	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
	;; flags: qr aa rd; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 6
	;; QUESTION SECTION:
	;hk.				IN	NS
	

;; ANSWER SECTION:
hk.	604800	IN	NS	NS2.HKIRC.NET.hk.
hk.	604800	IN	NS	NS3.CUHK.EDU.hk.
hk.	604800	IN	NS	SEC3.APNIC.NET.
hk.	604800	IN	NS	TLD1.ULTRADNS.NET.
hk.	604800	IN	NS	TLD2.ULTRADNS.NET.
hk.	604800	IN	NS	TLD3.ULTRADNS.ORG.
hk.	604800	IN	NS	TLD4.ULTRADNS.ORG.
hk.	604800	IN	NS	TLD5.ULTRADNS.INFO.
hk.	604800	IN	NS	TLD6.ULTRADNS.CO.UK.
hk.	604800	IN	NS	ADNS1.BERKELEY.EDU.
hk.	604800	IN	NS	ADNS2.BERKELEY.EDU.
hk.	604800	IN	NS	NS-HK.RIPE.NET.
hk.	604800	IN	NS	B.DNS.TW.
hk.	604800	IN	NS	NS1.HKIRC.NET.hk.
hk.	604800	IN	NS	NS2.CUHK.EDU.hk.
;; ADDITIONAL SECTION:
B.DNS.TW.	32446	IN	A	210.201.138.58
NS2.CUHK.EDU.hk.	45329	IN	A	137.189.6.21
NS2.HKIRC.NET.hk.	6723	IN	A	203.119.2.19
NS3.CUHK.EDU.hk.	45329	IN	A	202.45.188.19
SEC3.APNIC.NET.	142421	IN	A	202.12.28.140
SEC3.APNIC.NET.	142421	IN	AAAA	2001:dc0:1:0:4777::140

		;; Query time: 312 msec
	;; SERVER: 203.119.2.18#53(203.119.2.18)
	;; WHEN: Tue Dec 12 12:18:54 2006
	;; MSG SIZE  rcvd: 508
	

If no response is received, network and firewall administrators should first determine if a security policy other than the vendor's default processing for DNS messages is blocking the response message. If no policy other than the vendor's default processing is configured, note the implementation and version, and contact your vendor to determine if an upgrade or hot fix is available.

Test if Your Firewall Implementation Accommodates Large DNS Response Messages

To test the action a firewall implementation takes when it receives a UDP-encapsulated DNS response message larger than 512 bytes, a network or firewall administrator can perform the following DNS lookup using the popular dig program:

dig hk ns +bufsize=4096 @203.119.2.18

This command should elicit a 747 byte response that contains AAAA resource records:

		; <<>> DiG 9.2.3 <<>> hk ns +bufsize=4096 @203.119.2.18
	;; global options:  printcmd
	;; Got answer:
	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
	;; flags: qr aa rd; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 19
	;; OPT PSEUDOSECTION:
	; EDNS: version: 0, flags:; udp: 4096
	;; QUESTION SECTION:
	;hk.				IN	NS
	

;; ANSWER SECTION:
hk.	604800	IN	NS	B.DNS.TW.
hk.	604800	IN	NS	NS1.HKIRC.NET.hk.
hk.	604800	IN	NS	NS2.CUHK.EDU.hk.
hk.	604800	IN	NS	NS2.HKIRC.NET.hk.
hk.	604800	IN	NS	NS3.CUHK.EDU.hk.
hk.	604800	IN	NS	SEC3.APNIC.NET.
hk.	604800	IN	NS	TLD1.ULTRADNS.NET.
hk.	604800	IN	NS	TLD2.ULTRADNS.NET.
hk.	604800	IN	NS	TLD3.ULTRADNS.ORG.
hk.	604800	IN	NS	TLD4.ULTRADNS.ORG.
hk.	604800	IN	NS	TLD5.ULTRADNS.INFO.
hk.	604800	IN	NS	TLD6.ULTRADNS.CO.UK.
hk.	604800	IN	NS	ADNS1.BERKELEY.EDU.
hk.	604800	IN	NS	ADNS2.BERKELEY.EDU.
hk.	604800	IN	NS	NS-HK.RIPE.NET.
;; ADDITIONAL SECTION:
B.DNS.TW.	31310	IN	A	210.201.138.58
NS2.CUHK.EDU.hk.	44193	IN	A	137.189.6.21
NS2.HKIRC.NET.hk.	5587	IN	A	203.119.2.19
NS3.CUHK.EDU.hk.	44193	IN	A	202.45.188.19
SEC3.APNIC.NET.	141285	IN	A	202.12.28.140
SEC3.APNIC.NET.	141285	IN	AAAA	2001:dc0:1:0:4777::140
TLD1.ULTRADNS.NET.	31021	IN	A	204.74.112.1
TLD1.ULTRADNS.NET.	45	IN	AAAA	2001:502:d399::1
TLD2.ULTRADNS.NET.	82715	IN	A	204.74.113.1
TLD3.ULTRADNS.ORG.	31021	IN	A	199.7.66.1
TLD4.ULTRADNS.ORG.	31310	IN	A	199.7.67.1
TLD4.ULTRADNS.ORG.	31310	IN	AAAA	2001:502:100e::1
TLD5.ULTRADNS.INFO.	3521	IN	A	192.100.59.11
TLD6.ULTRADNS.CO.UK.	364	IN	A	198.133.199.11
ADNS1.BERKELEY.EDU.	117756	IN	A	128.32.136.3
ADNS2.BERKELEY.EDU.	117756	IN	A	128.32.136.14
NS-HK.RIPE.NET.	117756	IN	A	193.0.12.100
NS-HK.RIPE.NET.	117756	IN	AAAA	2001:610:240:0:53:cc:12:100

		;; Query time: 312 msec
	;; SERVER: 203.119.2.18#53(203.119.2.18)
	;; WHEN: Tue Dec 12 12:37:50 2006
	;; MSG SIZE  rcvd: 747
	

If no response is received, network and firewall administrators should first determine if a security policy other than the vendor's default processing for DNS messages is blocking large response messages or large UDP messages. If no policy other than the vendor's default processing is configured, note the implementation and version, and contact your vendor to determine if an upgrade or hot fix is available.

Share Your Results with the Internet Community

The SSAC and RSSAC committees encourage you to share your test results with the community by sending an email to the ICANN SSAC Fellow containing the following information:

• Firewall Product Manufacturer
• Firewall Model
• Firewall software/firmware version
• Action when AAAA RR encountered
• (Optional) A copy of the dig input and output (as illustrated above, this can
  be obtained by directing the output to a file, e.g., "dig hk ns @203.119.2.18 > digAAAA.txt")
• Action when DNS message larger than 512 bytes received
• (Optional) A copy of the dig input and output (as illustrated above, this can
  be obtained by directing the output to a file, e.g., "dig hk ns +bufsize=4096 @203.119.2.18 > digEDNS0.txt")

Testing Performed

The following results have been reported to the SSAC fellow as of 5 February
2007:

¹ Firewall configuration includes "fixup protocol dns maximum-length 1500".