“DNS Proxy Bypass by Recursive DNSDiscovery and LOCAL.ARPA”

draft-ietf-dns-recursive-discovery

Ray Bellis

IETF76 DNSOP WG

Hiroshima, 11th November 2009

The Fundamental Problem…

ISPISP

DNS

DNS settings learntvia DHCP or PPP/IPCP

DHCPDISCOVER

DHCPOFFER

DNS Servers (6) = 192.168.1.1

FAIL

Please try again – the DNS proxy on192.168.1.1 doesn’t work properly (see RFC5625)

The Chicken and Egg Problem…

ISPISP

DNS

DNS settings learntvia DHCP or PPP/IPCP

DHCPDISCOVER

DHCPOFFER

DNS Servers (6) = 192.168.1.1

FAIL

Still not right – you don’t know the real DNS servers because the LAN came up before the WAN.

Didn’t you fix that proxy yet?

The Configuration Problem…

ISPISP

DNS

End-user configuresDNS settings

DHCPDISCOVER

DHCPOFFER

DNS Servers (6) = 192.168.1.1

FAIL

Uh-oh - someone forgot to implement TR124 requirement LAN.DNS.2.End-user supplied DNS settings SHOULD be in the DHCP OFFER.

BTW – your proxy still doesn’t work properly!

The Proposed Solution…

ISPISP

DNS

• Let the DHCP stuff happen• Use the DNS proxy initially …• to ask the recursive DNS server for a list

of real DNS servers• Then use those instead!

IN A? domain.local.arpa.

IN A 192.0.2.1

The Proposed Solution…

ISPISP

DNS

• Let the DHCP stuff happen• Use the DNS proxy initially …• to ask the recursive DNS server for a list

of real DNS servers• Then use those instead!

IN A? domain.local.arpa.

IN A 192.0.2.1

A little more detail

• Why we’re proposing this:

– Because DNS proxies don’t work!• to get DNSSEC through• to get TCP queries through

• The draft reserves local.arpa.

– for use “within a network’s administrative boundaries”

– and domain.local.arpa for this application

• Version -02 will have NXDOMAIN redirect detection

– probably via nxdomain.local.arpa.

– if nxdomain.local.arpa == domain.local.arpa then ignore the results, your ISP is trapping NXDOMAIN

Things we’ve thrown out already

• Anycast

– If you’re going to use an Anycast address to discover DNS, you might as well use that address for all DNS!

• “.local”

– Too much baggage

Things we’re still figuring out!

• Does the bootstrap query need additional protection, and if so, how?

– DNSSEC no good, proxies break it!

– A random nonce prefix?

– Something else?

• Interaction with DNSSEC-signed .arpa

– If IANA has an NSEC[3] record that says local.arpa doesn’t exist, then the locally-supplied copy is bogus

Any Questions?