Proposal: optimized rev-DNS operations
Dear RIPE NCC Services-WG, please have a look at a new proposal: _Purpose: optimize Reverse-DNS operations_ 1. Assumption: There is a ton of negative reverse-DNS replies (no PTR-record/NXDOMAIN) returned from the RIPE NCC rev-DNS-Servers, for all not-yet-delegated address-blocks they are responsible for (also called “lame” delegations ?). 2. Question: How could this be optimized or at least encouraged to be fixed? Proposal: The RIPE NCC ops starts collecting statistics per member/LIR account of negative reverse-DNS queries for a respective address block (which is not yet delegated) and reports those statistics optionally to the LIRs, sorted by amount (i.e. top10 or top20 list in a fixed interval - say 1/month). There should be NO information about WHO requested rev-DNS values or when. Just a simple, aggregated summary of top requested addresses/blocks. 3. In case a member opts-in to view such statistics, one could decide to actively reply to such reverse-DNS requests and instead offer “good results” for requests, the address owners would never would see. 4. As a result: better performance, less errors through better infomation for RIR-members. I propose to run a test with a given address-block, which are not yet reverse-delegated and check if this approach is feasable, or where breakpoints might be, if this needs to work at a larger scale (across all rev-DNS Servers, operated by RIPE NCC for many members ideally). Best regards, Kurt Kayser
On Oct 24, 2019, at 2:22 PM, Kurt Kayser <kurt_kayser@gmx.de> wrote: 1. Assumption: There is a ton of negative reverse-DNS replies (no PTR-record/NXDOMAIN) returned from the RIPE NCC rev-DNS-Servers, for all not-yet-delegated address-blocks they are responsible for (also called “lame” delegations ?). 2. Question: How could this be optimized or at least encouraged to be fixed?
Doesn’t negative caching enabled by NSEC3 largely take care of this? At least as far as keeping most of the queries away from the authoritative in-addr servers? -Bill
On 24 Oct 2019, at 22:22, Kurt Kayser <kurt_kayser@gmx.de> wrote:
please have a look at a new proposal:
Purpose: optimize Reverse-DNS operations
1. Assumption: There is a ton of negative reverse-DNS replies (no PTR-record/NXDOMAIN) returned from the RIPE NCC rev-DNS-Servers, for all not-yet-delegated address-blocks they are responsible for (also called “lame” delegations ?).
Nope. A lame delegation occurs when the parent has NS records for some child zone and the targets of those NS records are not authoritative for the child zone. If you’re getting NXDOMAIN responses, these are coming from authoritative servers. Therefore those answers cannot be the result of lame delegations.
2. Question: How could this be optimized or at least encouraged to be fixed?
First you need to define the problem you think needs to be fixed. Then what you mean by optimise. Neither of these things are clear.
There should be NO information about WHO requested rev-DNS values or when. Just a simple, aggregated summary of top requested addresses/blocks.
Fair enough, but why? Producing more statistics is generally a good thing, provided it serves a useful purpose that people need/want or fixes a genuine problem. That purpose seems to be missing from your suggestion. At best it’s unclear.
3. In case a member opts-in to view such statistics, one could decide to actively reply to such reverse-DNS requests and instead offer “good results” for requests, the address owners would never would see.
That’s a bad idea. Sorry. First off, who is going to opt-in to view such statistics and why? What practical good will it do them? Of course it’s nice to know zone A gets X queries and zone B gets Y. But what real-world benefits does that provide? And why only for NCC members? They’re by no means the only people doing lookups on reverse zones that are co-ordinated by the NCC or hosted on the NCC's DNS servers. Next, are you *really* suggesting people should specially configure their name servers to give bogus answers (or “good results”) for reverse zones held by someone else? Please think of the consequences and the potential for mischief. Not to mention the extra administrative and operational overheads someone will have provisioning and maintaining their (faked) private copies of those zones. It’s hard enough for many address holders to do reverse DNS properly for their own address space. Do you think they’d choose to do that for somebody else’s address space? And get it right? You should also consider that some address holders have made a conscious decision to leave their reverse zones empty, especially for v6 space. Why second guess their motives? If those reverse zones/delegations are signed, your locally-faked zones are not going to validate. That could create serious operational problems. In such circumstances an NXDOMAIN from the real name servers instead of a SERVFAIL from the fake ones would a much, much better outcome. To get around that I suppose you could create even worse configuration and provisioning problems by faking trust anchors for the pretend copies of someone else’s zones. Yuk!
4. As a result: better performance, less errors through better infomation for RIR-members.
Nope. At best you might shave ~50ms off an initial lookup from a local resolver which goes to a local (bogus) name server instead of a real one sitting in someone else’s network. After that, the usual DNS benefits of caching and negative caching will kick in. I'm not sure what errors would be reduced either or why that matters. An NXDOMAIN response is not necessarily an error. It says “the name/qtype/class you looked up doesn’t exist”. Which might well be the truth rather than a mistake by some DNS administrator. That definitive response from the true source may well be more important than a faked answer from a non-definitive DNS server. BTW, what’s your definition of "better information”? That’s not clear either. There don’t appear to be any useful performance benefits or worthwhile reasons to take this idea forward. At least, not yet. Therefore I do not support this proposal. That said, there might be some value in asking the NCC to produce more statistics about its reverse DNS infrastructure. Maybe that could be a topic for a separate policy proposal. If you are minded to pursue your idea, I suggest you start in the DNS Working Group. That will be the best place to get help on how to define problem statements and use cases and then analyse possible solutions for DNS-related stuff. Once that is done, you might end up with something concrete that could be turned into a policy (either here or in the DNS WG) for the NCC to implement. RIPE’s DNS expertise is concentrated in the DNS WG, though some of it lurks in this WG. IMO there’s nothing in your proposal for the NCC Services WG to consider. At present it’s far too immature. A lot more work needs to be done first, some of it in the DNS WG. Note too that many of the questions above are rhetorical. You don’t need to immediately answer them here. Though they will need to be answered and clarified if/when there’s further work on your suggestion and a clearer policy proposal starts to emerge.
Hi,
RIPE’s DNS expertise is concentrated in the DNS WG, though some of it lurks in this WG.
From my own point of view, I'd be interested in learning if this is a
Yes, I suggested as much to my illustrious NCC Services co-chairs when this message arrived yesterday evening. problem that needs to be solved before we went about trying to solve it, and the RIPE NCC DNS team are the people to help quantify that. Cheers, Rob
Jim Reid wrote on 25/10/2019 00:19:
First you need to define the problem you think needs to be fixed. Then what you mean by optimise. Neither of these things are clear.
it's not completely clear that there is a problem here. If people don't want to set up reverse DNS for their IP address allocations, then is it really the responsibility of the RIPE NCC to pester them about this? Nick
Nick, very simple: Since the IPv6-blocks are quite large, one member might be interested towards areas that have active reverse requests coming in (but those are only visible up to the RIPE NCC servers, if they are not delegated for *all* IPv6 address space, which I doubt will ever happen. If they would have a means to know those top-areas they could (optionally) start analyzing and a delegation process and deliver answers for such addresses. Regards, Kurt Am 25.10.2019 um 11:25 schrieb Nick Hilliard (Network Ability Ltd):
Jim Reid wrote on 25/10/2019 00:19:
First you need to define the problem you think needs to be fixed. Then what you mean by optimise. Neither of these things are clear.
it's not completely clear that there is a problem here. If people don't want to set up reverse DNS for their IP address allocations, then is it really the responsibility of the RIPE NCC to pester them about this?
Nick
Kurt Kayser wrote on 25/10/2019 13:39:
Since the IPv6-blocks are quite large, one member might be interested towards areas that have active reverse requests coming in (but those are only visible up to the RIPE NCC servers, if they are not delegated for *all* IPv6 address space, which I doubt will ever happen.
If they would have a means to know those top-areas they could (optionally) start analyzing and a delegation process and deliver answers for such addresses.
but is it really the RIPE NCC's business to chase this down for resource holders? If the resource holder wants to know, they can get the dns delegated and investigate this themselves. If they don't want to know, that's kinda their business. Nick
Hello Nick, It's not about "chasing down" from RIPE NCC towards their members. It's rather: how should the resources holders KNOW about rev-DNS requests targeted for their space? It would require FIRST a delegation and THEN see those requests coming in. But for - say internally used adresses - one might not want to delegate all address space. My hope with this proposal was to provide a service in order to (optionally) signal interested members what specific areas of rev-DNS areas there are, in order to know which reverse-delegation should make sense and considered for rev-delegation. Therefore I decided to get statistics first from the RIPE NCC DNS-Servers, but I am not fully aware how and where I could start this investigation. Hence I halt the proposal in the meantime, until I have solid figures and base it not just on assumptions. .kurt Am 25.10.19 um 15:21 schrieb Nick Hilliard (Network Ability Ltd):
Kurt Kayser wrote on 25/10/2019 13:39:
Since the IPv6-blocks are quite large, one member might be interested towards areas that have active reverse requests coming in (but those are only visible up to the RIPE NCC servers, if they are not delegated for *all* IPv6 address space, which I doubt will ever happen.
If they would have a means to know those top-areas they could (optionally) start analyzing and a delegation process and deliver answers for such addresses.
but is it really the RIPE NCC's business to chase this down for resource holders? If the resource holder wants to know, they can get the dns delegated and investigate this themselves. If they don't want to know, that's kinda their business.
Nick
Hello Jim, et al, thanks for your reply. And I figure also some misinterpretation of my intentions. Truely, I need be clearer. Let me take one step back and officially ask the RIPE NCC to provider solid figures for the following statistics (hence I base my proposal on them and until now it was just an assumption): Total number to reverse_DNS requests for RIPE NCC addressblocks for a given timeframe hitting NCC servers (say for a test: 1 week). a. Ratio of successful NS replies to correctly delegated zones (independently if they might be correctly setup) of our members b. vs. replies that are not (yet) delegated zones (and yes, you were correct, they are NOT called lame-delegations) - which are the ones I am actually interested in for the proposal. c. vs. any other (say errors or RR that won't play a role here currently) I am also happy to take this proposal discussion the DNS-WG, but at the end I intended to let the RIPE NCC deliver an additional service to their members. Best regards, Kurt Kayser
On 25 Oct 2019, at 13:31, Kurt Kayser <kurt_kayser@gmx.de> wrote:
I am also happy to take this proposal discussion the DNS-WG, but at the end I intended to let the RIPE NCC deliver an additional service to their members
In that case, please move the discussion to the DNS WG. The additional service you’d like to see needs to be carefully considered and analysed by RIPE’s DNS experts. That can’t realistically be done here.
Hi Jim, thanks for the advice. I always had a different picture of the PDP in my mind, other than Jim telling me just "no" and "go away". It sounds now more like an PRP to me - the new "policy rejection process"... regards, Kurt PS: Please other WG-members tell me your opinions! Am 25.10.19 um 15:34 schrieb Jim Reid:
On 25 Oct 2019, at 13:31, Kurt Kayser <kurt_kayser@gmx.de> wrote:
I am also happy to take this proposal discussion the DNS-WG, but at the end I intended to let the RIPE NCC deliver an additional service to their members In that case, please move the discussion to the DNS WG.
The additional service you’d like to see needs to be carefully considered and analysed by RIPE’s DNS experts. That can’t realistically be done here.
On 27 Oct 2019, at 09:51, Kurt Kayser <kurt_kayser@gmx.de> wrote:
I always had a different picture of the PDP in my mind, other than Jim telling me just "no" and "go away".
Apologies if you got that impression Kurt. Because it’s not correct. I said nothing of the sort. Nobody’s said anything remotely close to "no" or "go away” - absolutely not. I said that if you want to proceed with your proposal, you should bring it to the DNS WG. Because that’s where you’ll find the expertise to analyse and work on it. They’re far better placed to do that work and help you with the gaps in your proposal than the NCC Services WG. One of this WG’s co-chairs suggested you go to the DNS WG too. I gave you pointers to lots of the questions that need to be resolved and explained key elements -- problem statement, use cases, definitions, etc. -- were missing. The DNS WG could help you work with you on these. That advice was given to *help* you to come up with a clearer policy proposal than the one you posted because that’s not ready to go through the PDP. You agreed on Friday your proposal need further work:
I figure also some misinterpretation of my intentions. Truely, I need be clearer.
You were also told that once you had a policy proposal that was more mature than the one you posted, it could go through the PDP from either the DNS WG or the NCC Services WG. I did say that I didn’t support your proposal in its current state because it lacked clarity and was generally immature. That isn’t a "no" or "go away” either. Others have asked if your proposal has identified a problem that needs fixing. It’s a pity you haven’t yet tried to answer their questions. That’s part of the PDP too. A policy proposal can’t get adopted until it gets consensus in a WG. It's not possible to get consensus when a proposal has unresolved questions or lacks clarity. These are things the policy’s proposer(s) need to address with the help of the appropriate WG(s).
_Purpose: optimize Reverse-DNS operations_
1. Assumption: There is a ton of negative reverse-DNS replies (no PTR-record/NXDOMAIN) returned from the RIPE NCC rev-DNS-Servers, for all not-yet-delegated address-blocks they are responsible for (also called "lame" delegations?).
As others have pointed out, this is not a "lame" delegation. That would be a situation where authority for a zone is delegated to a set of name servers, but one or more of them are not configured to serve the zone in question. And, further, NXDOMAIN isn't really an "error", it's a code indicating that the queried-for name doesn't exist in the DNS.
2. Question: How could this be optimized or at least encouraged to be fixed?
Is this really an operational problem? If you think so, I think you need to explain in more detail why this is so, because it's far from obvious. As has been asked by others, doesn't proper "aggressive negative caching using DNSSEC" as per RFC 8198 take care of the "optimization"? And ... a member wanting to see these stats for address space they "own", they can just get the corresponding zones delegated and inspect this themselves... I'm with what others have said here: the proper venue for discussing this issue is the DNS WG. Regards, - Håvard
And, further, NXDOMAIN isn't really an "error", it's a code indicating
2. Question: How could this be optimized or at least encouraged to be fixed? Is this really an operational problem? If you think so, I think you need to explain in more detail why this is so, because it's far from obvious. As has been asked by others, doesn't proper "aggressive negative caching using DNSSEC" as per RFC 8198 take care of the "optimization"? And ... a member wanting to see these stats for address space they "own", they can just get the corresponding zones delegated and inspect this themselves... Sure, this is the current way of operations. I see some potential to inform address space owners about rev-DNS interested area that could get attention after being visible in some statistics. Those are not available yet from the RIPE NCC servers and I trying to start looking at
Hello Harvard, thanks for your comments. Please let me comment on two items: that the queried-for name doesn't exist in the DNS. Fully agreed, but we could think about if a rev-DNS request to a non-allocated RIR_Address-space could receive a slightly different response than a non-delegated zone (due to whatsoever reason). (i.e. NXDOMAIN = does not exist vs. NXDELEG = is not delegated yet) the numbers which could be included in the LIR_Portal or other prominent service summaries (i.e. the monthly mailing to the LIR about the status of the LIR).
I'm with what others have said here: the proper venue for discussing this issue is the DNS WG.
True, I have moved the topic over to the other WG. Regards, Kurt
participants (6)
-
Bill Woodcock -
Havard Eidnes -
Jim Reid -
Kurt Kayser -
Nick Hilliard (Network Ability Ltd) -
Rob Evans