[RPZ] Unwanted AAAA records; replace A with authoritative response

Paul Vixie vixie at isc.org
Thu Nov 3 20:39:55 UTC 2011


On Wednesday, November 02, 2011 13:42:13 Jan-Piet Mens wrote:
> I've just been asked whether it would be possible to create an RPZ which
> hides broken (for any definition of broken) IPv6 sites. My solution is
> to create a record for the site with a corresponding A answer so that
> BIND replies there is no AAAA
> 
>         jpmens.net.rpz-net.  A  95.143.172.12
> 
> That works well enough with BIND 9.9.0a3, but it means records need to
> be populated with the A addresses.

this is a really terrible idea, for the reasons vjs described.

> Is there some trick to have the original authoritative A response
> returned instead of manually adding it to the RPZ zone? Something like
> 
>         jpmens.net.rpz-net.  A  *
> 
> I've tried that, but BIND correctly complains about an incorrect
> address :)

to the extent that you're willing to do the inventory control work of finding 
out who is advertising AAAA's that make their services less reachable, your 
highest-leverage goal would be: telling these folks to fix their IPv6 or to 
douse their AAAA until they've fixed their IPv6.

but i suspect that in many cases the inability to reach someone's IPv6 service 
will be pairwise rather than sourcewise or destinationwise. that is, the 
people whose IPv6 services you can't reach might well be reachable by many 
others besides you, and you might be able to reach many other IPv6 services 
besides that one. here, the purist answer is the same, spend your time fixing 
the pairwise problems. but, the case can definitely be made that using RPZ as 
a form of "DNS whiteout" would improve services. the danger is that the RPZ 
data becomes stale, and is still in use many years after the pairwise problems 
have been repaired. (UUCP path reoptimizers, i'm looking at *you*.)

the "happy eyeballs" folks have been working hard in this specific area:

http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-05

i think the approaches described in that draft are better than "DNS whiteout".

paul



More information about the DNSfirewalls mailing list