[Dnsmasq-discuss] Is there a way to "block" IPv6 address queries?
Simon Kelley
simon@thekelleys.org.uk
Wed, 06 Apr 2005 09:10:49 +0100
Eric P. Scott wrote:
> This example uses a FreeBSD 4.x installation, in which most user
> applications invoke the getaddrinfo(3)* API for name-to-address
> resolution. By default, this tries both IPv6 and IPv4, giving
> preference to the former.
>
> *FreeBSD man pages: http://www.freebsd.org/cgi/man.cgi
>
> My Internet Service Provider du jour only believes in IPv4, so
> even "successful" IPv6 resolution is nonproductive:
>
> % ftp ftp.isc.org
> ftp: connect to address 2001:4f8:0:2::18: No route to host
> Trying 204.152.184.110...
> Connected to ftp.isc.org.
> 220 Welcome to ftp.isc.org.
>
> That's an unusual case, of course. Nearly all the sites I care
> about simply don't "do" IPv6, and have no plans to adopt it in
> the foreseeable future.
>
> Now, I've compiled dnsmasq with -DNO_IPV6. This merely prevents
> dnsmasq itself from doing inappropriate things. But watch what
> happens when it's used:
>
> # dnsmasq -h -u bind -g dialer -i lo0 -b -r /etc/resolv.conf,sbc-sf -n -D -d -q
> dnsmasq: started, version 2.22 cachesize 150
> dnsmasq: setting --bind-interfaces option because of OS limitations
> dnsmasq: cleared cache
> dnsmasq: reading /etc/resolv.conf,sbc-sf
> dnsmasq: using nameserver 206.13.31.12#53
> dnsmasq: using nameserver 206.13.28.12#53
> dnsmasq: query[AAAA] www.sfgate.com from 127.0.0.1
> dnsmasq: forwarded www.sfgate.com to 206.13.28.12
> dnsmasq: forwarded www.sfgate.com to 206.13.31.12
> dnsmasq: query[A] www.sfgate.com from 127.0.0.1
> dnsmasq: forwarded www.sfgate.com to 206.13.28.12
> dnsmasq: reply www.sfgate.com is <CNAME>
> dnsmasq: reply sfgate.com is 66.35.240.8
> dnsmasq: query[AAAA] www.sfgate.com from 127.0.0.1
> dnsmasq: forwarded www.sfgate.com to 206.13.28.12
> dnsmasq: query[A] www.sfgate.com from 127.0.0.1
> dnsmasq: cached www.sfgate.com is <CNAME>
> dnsmasq: cached sfgate.com is 66.35.240.8
> dnsmasq: query[AAAA] sfgate.com from 127.0.0.1
> dnsmasq: forwarded sfgate.com to 206.13.28.12
> dnsmasq: query[A] sfgate.com from 127.0.0.1
> dnsmasq: cached sfgate.com is 66.35.240.8
>
> Notice how the public DNS keeps being hammered with identical
> AAAA queries, which, of course, have identical results [no error,
> no records returned]. The whole point of using a caching DNS
> server was to eliminate redundant network traffic. Dnsmasq has
> cut it in half, but it really should be doing much better.
>
> It's true, that on this machine, some applications (such as ftp
> and ssh) offer command-line options to restrict queries to IPv4-
> only. But many do not, and there's no other convenient means to
> make this the default. While I could conceivably use LD_PRELOAD
> to override getaddrinfo(3) [along with its "predecessors"
> getipnodebyname(3) and gethostbyname2(3)], this is awkward at
> best. Recompilation to remove the IPv6 bits entirely is even
> more distasteful. None of this helps in a production
> environment, where queries would originate on other LAN clients,
> with differing operating systems, configurations, etc.
>
> So what am I looking for? (1) a means to alleviate repeated
> forwarding when no records of a given type (AAAA, MX, TXT, etc.)
> have been determined to exist for a [NOERROR] domain.
That's negative caching. The way it's done is specified in RFC 2308 and
dnsmasq supports it. The crucial thing is that there needs to be an SOA
record in the authority section of the reply in order for a negative
cache entry to be generated. I've noticed that recently my ISP's
nameservers have stopped including an NS section. They probably think
doing that will reduce the load on their nameservers. Poor fools.
I suspect that your ISP has done the same thing. Try running a query
using "dig" for an unknown domain and see what you get: it should look
like this:
; <<>> DiG 9.2.1 <<>> aaaa thekelleys.org.uk
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4694
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;thekelleys.org.uk. IN AAAA
;; AUTHORITY SECTION:
thekelleys.org.uk. 1800 IN SOA ns1.mydyndns.org.
zone-admin.dyndns.org. 2004062503 10800 1800 604800 1800
;; Query time: 358 msec
;; SERVER: 194.168.8.100#53(194.168.8.100)
;; WHEN: Wed Apr 6 08:52:42 2005
;; MSG SIZE rcvd: 105
but if it looks like this instead, that's the source of the problem.
; <<>> DiG 9.2.1 <<>> junk.thekelleys.org.uk
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25755
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;junk.thekelleys.org.uk. IN A
;; Query time: 45 msec
;; SERVER: 194.168.4.100#53(194.168.4.100)
;; WHEN: Wed Apr 6 08:55:28 2005
;; MSG SIZE rcvd: 40
(2) a
> "deep six" option that might work as follows: If an AAAA query
> comes in that can not be answered from the cache, forward an A
> instead. If that comes back with NXDOMAIN, pass it along.
> Otherwise, save the A record, and [non-authoritatively?] respond
> that no AAAA records exist. A subsequent A query would be
> satisfied from the cache.
>
One has to differentiate between NXDOMAIN and NODATA replies. NXDOMAIN
menas that the _domain_ doesn't exist and that is true for all query
types. NODATA means that whilst the domain does exist, there is no
associated data for a particular record type. It's not possible to infer
anything about other record types from that.
Actually, I think dnsmasq does miss a trick here, it doesn't use
NXDOMAIN information from one record type to infer that same information
for other types. That doesn't make any difference in your case but
fixing it would be a small enhancement.
Cheers,
Simon.
> Comments?
>
> -=EPS=-
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>