[Pdns-users] ENUM NAPTR queries

Klaus Darilion klaus.darilion at nic.at
Tue Feb 14 14:24:45 UTC 2023


Hi Alexis!

One thing: If a number is not found in ENUM you should check if returning NXDOMAIN or NODATA (empty answer section). Because there may be a number below the asked one and then NXDOMAIN is wrong and may lead to problems if the DNS client (recursing name server) implements RFC8020.

regards
Klaus 

> -----Ursprüngliche Nachricht-----
> Von: Alexis Fidalgo <alzrck at gmail.com>
> Gesendet: Montag, 13. Februar 2023 16:02
> An: Klaus Darilion <klaus.darilion at nic.at>
> Cc: pdns-users at mailman.powerdns.com
> Betreff: Re: [Pdns-users] ENUM NAPTR queries
> 
> No worries, I’m working now in a combination between mongo and redis and
> compiled regexp’s to deal with it, looks promising :)
> 
> Thanks again for your help
> 
> Enviado desde dispositivo móvil
> 
> > El 13 feb. 2023, a la(s) 09:28, Klaus Darilion <klaus.darilion at nic.at> escribió:
> >
> > Probably things are different when using a dynamic backend vs. a DB backend.
> Unfortunately I am not familiar with the remote backend.
> >
> > regards
> > Klaus
> >
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Alexis Fidalgo <alzrck at gmail.com>
> >> Gesendet: Montag, 13. Februar 2023 15:20
> >> An: Klaus Darilion <klaus.darilion at nic.at>
> >> Cc: pdns-users at mailman.powerdns.com
> >> Betreff: Re: [Pdns-users] ENUM NAPTR queries
> >>
> >> 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