Home Gateways and DNS

Ray Bellis, Advanced Projects, Nominet UK

IETF 76, Hiroshima, 9th November 2009

Previous Research

“DNSSEC Impact on Broadband Router and Firewalls”

• Joint study between Nominet UK and Core Competence

• Expansion of .SE’s previous study

• Devices tested:

– 4 SOHO Firewalls

– 12 Dual Ethernet “Gateways”

– 8 ADSL Routers

• Published by ICANN SSAC (SAC035) September 2008

Proxy Behaviour #1

• Responses truncated at 512 bytes (without setting TC)

• Responses having TC flag cleared in transit

• Packets dropped in either direction when CD=1 or AD=1

• EDNS0 packets black-holed or rejected

• No support for failover to TCP

Many implementors have only implemented RFC 1035 and nothing since:

These can break DNSand DNSSEC

Proxy Behaviour #2

• Fragment reassembly was a big problem

– Some fragments black-holed

– Some sent from the wrong Source IP

– Typically evident in packets near the WAN MTU

Devices that were “dumb” about DNS tended to do better than “smart” devices, but only so long as they did the rest of UDP/IP correctly:

DHCP Behaviour

• 15 devices put their own (LAN) IP address in their DHCP server’s “Domain Name Server” option

– But 9 of those 15 have no way to change the DHCP settings

• A further six devices put the upstream addresses in, but only once the WAN link is up (“chicken and egg” problem)

• The remaining three don’t proxy by default

Why proxy at all?

• Why do home gateways have DNS proxies in them?

– To establish stable DHCP offers?

– Because TR069 says so?

– Other reasons?

• Are there better alternatives?

– Issue a (very) short DHCP lease until the WAN is up?

– Ensure that end-users can configure DNS via the router’s DHCP settings

– Heuristics to bypass the proxy?

(e.g. draft-bellis-dns-recursive-discovery-01)

But if you must proxy…

… please do it properly

• RFC 5625 (BCP 152) - August 2009

– Summarizes flaws found

– Uses IETF language

– Recommends core DNS-related RFCs that must be implemented to be compatible with current DNS technologies