[SAC016]: Testing Firewalls for IPv6 and EDNS0 Support

Date: 
30 Janvier, 2007

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:

Product Version Action when AAAA RR encountered Action when large DNS message
received
Source
Checkpoint Firewall-1 NG, R55 Allow Allow user
Check Point FW-1 NGX R61 HFA 1 on Nokia IPSO 4.1-BUILD013 Allow Allow user
Cisco C2600 IOS 12.2(37) Allow Allow user
Cisco FWSM 2.3(4) Allow Allow user
Cisco PIX Version 6.2.5 Allow Deny vendor
Cisco PIX Version 6.3.5 Allow Allow1 vendor
Cisco PIX Version 7.2.1 Allow Allow vendor
Clavister Security Gateway (All models) Allow Allow vendor
Eland Systems SYS-2, SYS-2 SOHO 3.x, 4.x Allow Allow vendor
Fortinet Fortigate 60 Version 3.0.x Allow Allow user
FreeBSD OpenBSD pf 6.2-PRERELEASE Allow Allow user
GajShield Infotech Securegate version 5.4 Allow Allow vendor
Juniper/Netscreen ScreenOS Versions 5.4r2, 5.30r3, 4.0.3r4.0 Allow Allow user
Kobelt Development NetSentron 3.1.0p11-Pro Allow Allow vendor
Linux 2.6 kernel Shoreline Shorewall Firewall 2.4.1-3 Allow Allow user
Linux kernel - Debian iptables 2.6.17.1 Firewall 2.6.17.1 Allow Allow user
Lucidata Lucigate Firewall 3.14 Allow Allow vendor
Mandriva Linux 2006 OpenBSD 4.0 pf Allow Allow user
NetStealth Firewall StealthOS Not supported Not supported vendor
Secure Computing Sidewinder Versions 5.2.1, 6.1.2.00 Allow Allow user
Shiva/Eicon 3105 v 8.42 Allow Allow user
Sonicwall SonicOS Standard 3.1.0.7-77s Allow Allow user
Sepehr 3400 GOS 3.0 Allow Allow vendor
Sepehr 4100 GOS 3.0 Allow Allow vendor
Watchguard Firebox X 1000 Fireware v8.2 Allow Allow user
Watchguard Firebox X Edge 8.0 Allow Allow user
XNet Solutions SN330 Version 1.2.1 Allow Allow vendor
XNet Solutions EN400 Version 1.0.0 Allow Allow vendor

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