[Pdns-users] ENUM NAPTR queries

Alexis Fidalgo alzrck at gmail.com
Mon Feb 13 14:20:24 UTC 2023


Bur Mongo db is not seen at all from pdns , is hidden by my code used by the remote backend via http. My app is the one acceding mongo and responding to this http to remote backend.

The question was how to avoid this big loop of questions since the first one has a correct answer, and zone information was answered before the naptr query, I want only one query if possible. 



Enviado desde dispositivo móvil 

> El 13 feb. 2023, a la(s) 09:12, Klaus Darilion <klaus.darilion at nic.at> escribió:
> 
> Before PowerDNS answers the query, it has to find the authoritative zone. Therefore it loops over the labels to find the zone apex.
> 
> But this behavior was changed with 4.5 when https://doc.powerdns.com/authoritative/settings.html#zone-cache-refresh-interval was introduced. So maybe you have disabled the zone-cache, using an old PowerDNs version, or this feature is not supported with MongoDB.
> 
> regards
> Klaus
> 
> -- 
> Klaus Darilion, Head of Operations
> nic.at GmbH, Jakob-Haringer-Straße 8/V
> 5020 Salzburg, Austria
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Pdns-users <pdns-users-bounces at mailman.powerdns.com> Im Auftrag von
>> Alexis Fidalgo via Pdns-users
>> Gesendet: Montag, 6. Februar 2023 13:49
>> An: pdns-users at mailman.powerdns.com
>> Betreff: [Pdns-users] ENUM NAPTR queries
>> 
>> Hello all, good morning.
>> 
>> Im working developing a http app to be used with remote backend, this
>> app uses a mongodb backend in order to read Local Number Portability
>> records (around 400MM) queried to powerdns auth server using NAPTR type.
>> 
>> Everything works ok but im facing a kind of no go now. Up to now, the
>> pdns auth server is getting around 20/30 qps because is under test. Next
>> step is to deploy the pdns auth inside a docker swarm, set 10/15
>> replicas and start receiving 1500qps and grow up to 20/25k qps.
>> 
>> a normal query is like this
>> 
>>>> alz at nuc  ~  dig @localhost 6.8.0.7.0.0.9.9.3.2.lesi.com.ar NAPTR
>> 
>> ; <<>> DiG 9.16.33-Debian <<>> @localhost
>> 6.8.0.7.0.0.9.9.3.2.lesi.com.ar NAPTR
>> ; (2 servers found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21129
>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>> ;; WARNING: recursion requested but not available
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 1232
>> ;; QUESTION SECTION:
>> ;6.8.0.7.0.0.9.9.3.2.lesi.com.ar. IN NAPTR
>> 
>> ;; ANSWER SECTION:
>> 6.8.0.7.0.0.9.9.3.2.lesi.com.ar. 1 IN NAPTR 100 10 "u" "E2U+SIP"
>> "!^.*$!sip:+2399007086 at ims.mnc790.mcc313.3gppnetwork.org!" .
>> 6.8.0.7.0.0.9.9.3.2.lesi.com.ar. 1 IN NAPTR 100 10 "u" "E2U+pstn:tel"
>> "!^.*$! tel:2399007086;npdi;rn=2324832232!" .
>> 
>> ;; Query time: 1507 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> ;; WHEN: Mon Feb 06 09:34:15 -03 2023
>> ;; MSG SIZE  rcvd: 205
>>>> 
>> in the remote backend i can see the query
>> {"method": "lookup", "parameters": {"local": "0.0.0.0", "qname":
>> "6.8.0.7.0.0.9.9.3.2.lesi.com.ar.", "qtype": "ANY", "real-remote":
>> "172.17.0.1/32", "remote": "172.17.0.1", "zone-id": -1}}
>> 
>> answered
>> 
>> {"result":[{"qtype":"NAPTR","qname":"6.8.0.7.0.0.9.9.3.2.lesi.com.ar.","
>> content":"100 10 \"u\" \"E2U+SIP\"
>> \"!^.*$!sip:+2399007086 at ims.mnc790.mcc313.3gppnetwork.org!\"
>> .","ttl":1},{"qtype":"NAPTR","qname":"6.8.0.7.0.0.9.9.3.2.lesi.com.ar.",
>> "content":"100 10 \"u\" \"E2U+pstn:tel\" \"!^.*$! tel:2399007086;npdi
>> <tel:2399007086;npdi> ;rn=2324832232!\" .","ttl":1}]}
>> 
>> but after that i can see
>> {"method": "lookup", "parameters": {"local": "0.0.0.0", "qname":
>> "8.0.7.0.0.9.9.3.2.lesi.com.ar.", "qtype": "ANY", "real-remote":
>> "172.17.0.1/32", "remote": "172.17.0.1", "zone-id": -1}}
>> answered: {“result": false}
>> 
>> then
>> {"method": "lookup", "parameters": {"local": "0.0.0.0", "qname":
>> "0.7.0.0.9.9.3.2.lesi.com.ar.", "qtype": "ANY", "real-remote":
>> "172.17.0.1/32", "remote": "172.17.0.1", "zone-id": -1}}
>> 
>> and so on.
>> 
>> I dont need all those queries, if the first one (the complete phone
>> number which is 2399007086) has no porting information, that’s it, no
>> more queries. i can’t afford x10 queries on the database with no use at
>> all.
>> 
>> All are phone calls in setup stage (at least trying to) and time is
>> important (beside processing, etc)
>> 
>> 
>> How can i stop this kind of loop recursion?
>> 
>> 
>> Thanks in advance.
>> BR
>> 
> 


More information about the Pdns-users mailing list