[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
> 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
> dnsmasq: using nameserver
> dnsmasq: query[AAAA] www.sfgate.com from
> dnsmasq: forwarded www.sfgate.com to
> dnsmasq: forwarded www.sfgate.com to
> dnsmasq: query[A] www.sfgate.com from
> dnsmasq: forwarded www.sfgate.com to
> dnsmasq: reply www.sfgate.com is <CNAME>
> dnsmasq: reply sfgate.com is
> dnsmasq: query[AAAA] www.sfgate.com from
> dnsmasq: forwarded www.sfgate.com to
> dnsmasq: query[A] www.sfgate.com from
> dnsmasq: cached www.sfgate.com is <CNAME>
> dnsmasq: cached sfgate.com is
> dnsmasq: query[AAAA] sfgate.com from
> dnsmasq: forwarded sfgate.com to
> dnsmasq: query[A] sfgate.com from
> dnsmasq: cached sfgate.com is
> 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

;thekelleys.org.uk.             IN      AAAA

thekelleys.org.uk.      1800    IN      SOA     ns1.mydyndns.org. 
zone-admin.dyndns.org. 2004062503 10800 1800 604800 1800

;; Query time: 358 msec
;; 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

;junk.thekelleys.org.uk.                IN      A

;; Query time: 45 msec
;; 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.


> Comments?
> 					-=EPS=-
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss