Re: [FRnOG] [TECH] EDNS Client-Subnet et empoisonnement de cache

[Codimp via frnog]

On 04/12/2020 00:05, Xavier HINFRAY wrote:
> As tu essayer de faire un subnet par défaut dans ta base de geoloc
> (0.0.0.0/0) ?
Oui, j'ai oublié de le préciser mais j'ai essayé et ça fait exactement 
la même chose en empoisonnant le cache avec cette réponse par défaut.


En fait dans ce cas là il semble bien garder en cache le fait que ça 
soit lié à un subnet mais si je pose une question qui peut correspondre 
à un subnet /8 et un /24 alors il choisi de répondre la réponse relative 
à /8, alors que je veux qu'il réponde celle du /24 (je ne comprend pas 
pourquoi répondre le plus court prefix au lieu du plus long du coup)


--
Codimp


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] EDNS Client-Subnet et empoisonnement de cache

[Codimp via frnog]

Bonjour la liste,

je viens aujourd'hui avec un problème qui me prend la tête depuis un moment.

J'ai une infrastructure DNS qui gére des zones internes (ici 
example.com) avec un résolveur Unbound (10.1.0.3) et un serveur faisant 
autorité Knot (10.1.0.2).


Knot est configuré pour servir une zone interne avec le module geoip en 
mode "subnet" contenant ces données :


example.com:
  - net: 10.1.1.0/24
A: 10.1.1.1
  - net: 10.1.2.0/24
A: 10.1.2.1

Et en fallback le fichier de zone de example.com contient ceci :

;; Zone dump (Knot DNS 2.8.5)
example.com.  	3600	SOA	ns.example.com. admin.example.com. 
2020060303 43200 900 1209600 60

example.com.3600NS  ns.example.com.
ns.example.com. 3600A   10.1.0.2
example.com.3600A   127.0.0.1


Du côté de Unbound, j'ai activé EDNS Client-Subnet pour cette zone :

server:
# Disable DNSSEC validation for internal domains
domain-insecure: "example.com"
# EDNS-client-subnet
module-config: "subnetcache validator iterator"
client-subnet-zone: "example.com"
# Stub-zones
stub-zone:
name: "example.com"
stub-addr: 10.1.0.2


Avec ce genre de configuration quand j'interroge depuis un subnet 
renseigné dans le module geoip ça marche bien :


$ dig @10.1.0.3 example.com +subnet=10.1.1.0/24 +short
10.1.1.1
$ dig @10.1.0.3 example.com +subnet=10.1.2.0/24 +short
10.1.2.1

Par contre si je demande depuis un subnet qui n'est pas dans ma 
configuration geoip :


$ dig @10.1.0.3 example.com +subnet=10.1.3.0/24 +short
127.0.0.1
$ dig @10.1.0.3 example.com +subnet=10.1.1.0/24 +short
127.0.0.1
$ dig @10.1.0.3 example.com +subnet=10.1.2.0/24 +short
127.0.0.1

il me sert la réponse du fichier de zone ce qui est normal pour la 
première requête hors configuration geoip, mais le résolveur met cette 
réponse en cache et la sert à toute autre demande concernant ce domaine 
sans du coup tenir compte du subnet. Mon cache se trouve comme 
empoisonné par cette réponse par défaut.


J'ai tenté plusieurs choses : dire à Unbound de ne pas faire de cache 
pour cette stub-zone (stub-no-cache), essayer en forward-zone plutôt que 
stub-zone, etc mais rien n'y fait.


Du coup je me demande si quelqu'un ici connait ce cas et pourrait savoir 
ce que j'ai pu mal configurer.


--
Codimp


---
Liste de diffusion du FRnOG
http://www.frnog.org/