Re: [DNSOP] AS112 for TLDs
On Fri, Apr 04, 2008 at 11:19:58AM -0400, Andrew Sullivan wrote: On Fri, Apr 04, 2008 at 07:37:31AM -0700, David Conrad wrote: ... I can just imagine the hue and cry that would happen when new top level domains don't work for everybody. Or in a future, actually very far from today, when DS records are not updated during a rollover. Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: Considerations for the use of DNS Reverse Mapping
I have read this document and have no objection to its publication. That said, I share Jinmei's concern that the recommendation against depending on reverse mapping is too weak in the context of the rest of the document. I'm in favor of much stronger language saying don't depend on reverse mapping being available. While I appreciate the spirit of the text proposed by Ed Lewis, the below paragraph seems a bit confusing: The number of address records in an PTR set before tripping the upper limit on what can fit on even a TCP carried DNS message is approximately 4000 for A RR only and about 2000 for RR only. I believe that adding explicit mention of the dangers of too many PTR RRs at a name will help emphasize the you really shouldn't depend on reverse mapping, which is a good thing. -- Sam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsops-name-server-management-reqs Mail delivery problems
On Fri, 4 Apr 2008, Alfred H?nes wrote: I wanted to send comments on draft-hardaker-dnsops-name-server-management-reqs-01 in private communications to the author, but the message has been bounced after 3 days of persistent errors: ... Similar experiences? Can someone there help? Sadly, yes, many similar experiences. Instead use: [EMAIL PROTECTED]. An alternate address for me is in the From line, also. -- Sam___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Apr 4, 2008, at 8:30 AM, Frederico A C Neves wrote: On Fri, Apr 04, 2008 at 11:19:58AM -0400, Andrew Sullivan wrote: On Fri, Apr 04, 2008 at 07:37:31AM -0700, David Conrad wrote: ... I can just imagine the hue and cry that would happen when new top level domains don't work for everybody. Or in a future, actually very far from today, when DS records are not updated during a rollover. A self-correcting problem. The folks that are affected are the ones using the non-updated server and no one else. Ideally, there would be a way to use standard zone transfer semantics to refresh the zone, but the hue and cry would likely serve to put the lackadaisical caching server operator on notice that they'd screwed up. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
Andrew, On Apr 4, 2008, at 10:08 AM, Andrew Sullivan wrote: A self-correcting problem. The folks that are affected are the ones using the non-updated server and no one else. The problem is that those folks are _exactly_ the people who don't understand any of this Internet plumbing anyway. All they know is, This thing isn't working, or, The Internet is down, or something similar. The idea that they're going to put pressure on someone to fix it entails a great deal of optimism about what naive users might know about how the Internet functions and who can solve their problems. If the Internet is down, those folks are going to whine to their provider. I refer you to Vijay Gill's statements about the impact of a single support call. While it is admittedly in a different context, I'd still argue it is in the best interests of the name service provider to fix things to minimize the amount of gnashing of teeth they'd be subjected to. However, with that said, I would agree that it would be far better to minimize the chances of stale data in a copied root. I'd think having a way of automating the copying, via oh say zone transfer using regular zone transfer semantics would be the right way to go (Mark Andrews: hint, hint). Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: Considerations for the use of DNS Reverse Mapping
At Thu, 3 Apr 2008 22:34:29 -0400, Andrew Sullivan [EMAIL PROTECTED] wrote: or something else? In either case, does this mean we don't have to provide reverse mappings for addresses that are NOT referenced in a forward mapping? No. We added this text exactly to address your previous objection that the text appeared to be requiring that every IP address anybody uses has to have a reverse map, which is absurd since every IP address in use doesn't need to have a forward map. I'm still not sure...The No seems to say this temporary address is still covered by this sentence, but the following sentence seems to indicate the opposite. Sorry, I see the problem now with my response. No, the temporary address does not need to have a reverse mapping, for exactly the same reason that it does not need a forward one. I will attempt to come up with a sentence that makes this clearer, given that it obviously isn't so far. Okay, thanks. Then I think I can basically agree on this draft on top of this understanding. But I'd still like to make several clarifications and possibly wording changes before publishing it. I'll try to make these points clearer in subsequent responses. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
Hi all. I fully agree with Andrew that the cause is far worse than the disease. I don't think the disease is life threatening. I keep hearing about the Problem of bogus queries to the root. It is certainly messy and ugly but from my perspective as an operator it is more of irritant than anything else. The capacity building for root operators, at least in our case, is not built around those bogus queries, it's build around other problems such as the number of hosts with weak security that are available for use in DDOS attacks. In % terms the 90%+ of bogus queries is irritating, moving those queries out to the ISPs doesn't stop them, just shares the pain a little and probably hides the problem somewhat. For now I still believe the best answer is to keep answering with NXDOMAIN and hoping that one day, this is where I am delusional, that those do the querying will fix their end of the problem... John Crain On 04/04/2008 08:19, Andrew Sullivan [EMAIL PROTECTED] wrote: On Fri, Apr 04, 2008 at 07:37:31AM -0700, David Conrad wrote: leakage to the root servers is enormous. This sounds to me like a cure that is quite possibly worse than the disease. In what way? It rather depends on how much the root zone changes. The targets of run your own root copy are the people who don't know how to capture and appropriately isolate (or don't care to do it) their bogus traffic. The proposed solution is to tell them to get a copy of the root zone and run that. What makes us think that they'll keep that copy up to date, do sensible things with it, c? I am familiar with one largeish zone that had its infrastructure on the wrong end of an expensive link between it and the largest ISP in the country. Their answer to this was to transfer the zone to the ISP. Unfortunately, nobody at the ISP was monitoring the log files, and someone failed to keep the TSIG keys in sync, so their copy of the zone gradually came to be wrong. Since none of this copying-of-zone-around was documented anywhere, it took some time to debug the problem, during which time large sections of that domain were unavailable to a substantial population in the country in question. I can just imagine the hue and cry that would happen when new top level domains don't work for everybody. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Fri, Apr 04, 2008 at 07:37:31AM -0700, David Conrad wrote:
On Apr 4, 2008, at 7:02 AM, Andrew Sullivan wrote:
On Fri, Apr 04, 2008 at 02:16:32PM +1100, Mark Andrews wrote:
er, it (the bogus ttraffic) still reaches the root.
just your copy of the root, not mine.
Yep. This should be seen as a good thing. The information
leakage to the root servers is enormous.
This sounds to me like a cure that is quite possibly worse than the
disease.
In what way?
Mark made the claim that a local copy of the root would stop the
traffic, which is false. a local copy of the root simply diffuses
the traffic.
the down sides to local copies of the root as seen from the
peanut gallery:
) coherence of the avowed single namespace. There have been
a few threads over the past decade on bit rot in the root-hints
data. Local copies of the root zone will have the same bit-rot
characteristics
) the IANA sanctioning alternate roots/namespaces ... let a
thousand roots bloom...
) just how is the poor application/end user supposed to know
or discriminate some local, walled garden root varient from
the one true ICANN root varient?
I said COPY. I did not say THEIR OWN ROOT. A copy needs to
be kept up to date or it ceases to be a copy. It becomes a
snapshot.
zone . {
type slave;
masters { addresses of root servers; };
};
Mark
but you, no doubt, see a much clearer picture. please convince
me that my doubts are groundless... that bit-rot won't happen,
It is possible to check the masters similarly to the way
we check the roots servers today.
that the avowed single namespace will remain intact,
It will if you keep the copy up to date.
and that
there will be trival ways for end users to discover the root of
the namespace they are using...
dig NS .
if the recommendation to run your own copy of the root is approved.
Note the zone will expire if you don't keep the masters up
to date unlike failures to keep the root hints up to date.
Mark
--bill
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: Considerations for the use of DNS Reverse Mapping
Hello, again, Thanks for the detailed response. I now understand what I was concerned about more clearly, and hopefully I can be clearer on that point this time. At Sun, 30 Mar 2008 11:42:34 -0400, Andrew Sullivan [EMAIL PROTECTED] wrote: As a meta (and most substantial) level, this version still doesn't answer the fundamental question I asked a year ago: why *should* one provide reverse mappings for all IP addresses they manage? (despite the cost of the provision)?. (see http://www.ietf.org/mail-archive/web/dnsop/current/msg05411.html) In the current version, we have attempted to address this question in two ways. I think I basically understand the intent, but the subtle wording of this document makes me unsure about it without knowing the background discussions like this one. The current document reads (to me): 1. list cases where people say they are using, the reverse tree, and it's useful to them, with notes that it's unknown to add any security, unreliable, and neither necessary nor sufficient for abuse (sapm) detection. 2. and recommend IP addresses should have reverse mapping unless strong counter-considerations exist (and an example of such considerations is something that doesn't apply for many ordinary end operators). 3. on the other hand, encourage the reverse mapping users to think carefully before adopting such tests (= the cases given in bullet #1 above). This is not convincing to me in the following two points: A. it's unfair. If this is based on the spirit of reciprocity (referring to Bill), which I'd respect, IMO it should be a fair deal. It's not very fair to me to request someone to do something while just encouraging others to think about it (even if carefully). And, as I mentioned in the previous message, I'm not just ethically complaining about it; I'm afraid the unbalanced fairness will worsen poor interoperability. To make it fair, I can think of two approaches: X. weaken the requirement for the provider of the mapping. This is what I proposed in my first message in this thread. Y. tighten the note to the naive users, e.g., should not use any test of reverse delegation, particularly when that test is intended to improve security, unless there is a strong counter-considerations such as a statistical proof that it improves the security without false positives. I can live with either way, but proposed X first considering peoples' views so vary that we cannot easily agree on tightening the recommendations. But, if proposal X is not acceptable due to the opinion that weakening it makes the document effectively die, is there any reason we cannot adopt approach Y? B. if the unfairness is on purpose, it's then not very convincing in that the only reason is that some people say it's useful and they want to use it, despite the list of why it's not a very good idea. If the only justification is that some people want to use it that way, I'd rather request we respect the fairness. Whether others agree on my view or not, I hope I'm clear about my concern this time. I'm going to make the following response based on this meta-level point. First, we do list a number of cases where people say they are using the reverse tree, and it's useful to them. As Brian Dickson says elswhere in this thread, the simple fact is that there is no way to tell whether there is existing or matching reverse without querying for it. To the extent that the reverse tree can be valuable, it requires that people populate it and keep it up to date. That's basically fine. Second, the current version includes the following text in Section 4.2; it is intended to address your objection, at least in part. It is nevertheless worth considering that not all benefit from an administration practice accrues to the administrator of a network. The consumers of reverse mapping data are often not the operators of the network that provides the reverse mappings. Users of reverse mapping data report that it is valuable to them. (note that there's a typo in the published version: accrue rather than accrues. I just fixed it in my local copy, now.) The idea here is to remind people that the reason you _should_ do this is because other people say they find the reverse map useful. It is true that there is an asymmetry of cost and benefit here; that's the reason that we need the draft at all, I think. As indicated by the word asymmetry, this sounds unfair to me, and I don't see why we cannot be fair. Since this document does not provide a convincing answer (at least to me) for the question of why I should, I, as an operator, will still only provide reverse mappings as a best effort basis (i.e., I may not provide them even if there is no *strong* counter-considerations). For example I won't provide reverse mappings if I simply cannot
