[dnsop] Re: WGLC on draft-ietf-dnsop-bad-dns-res-03.txt
On Wed, Dec 01, 2004 at 05:48:24PM +0100, Peter Koch [EMAIL PROTECTED] wrote a message of 332 lines which said: Shouldn't the root servers also shuffle the NS RRset, as most of them (K and the NSD instance of H don't) do for the '.'? Hmmm, is it specified somewhere? People could say that it is a function of the cache/forwarder server, not of the authoritative server. . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
[dnsop] draft-kurtis-tld-ops-00.txt: too drafty
I've read draft-kurtis-tld-ops-00.txt and I find it disappointing. My main problem is that it says: This document tries to analyze and define the operational requirements for the second tier in the DNS lookup hierarchy. But it just describes *solutions* (redundant power supply, backups), not actual *requirments* (availability, correction, response time, etc). I would love to see a document which first describes the requirments, *then* gives possible solutions to meet these requirments. Otherwise, the tree hides the forest. A good example is the Redundant power feeding: the real requirment is to have at least one name server available. It is better to have five nameservers without redundant power supply, but in various places, than only one name server with a super power supply. Otherwise: Backups: The slave-server systems should be backed up regularly. This includes zone data, Well, this is a strange advice, the zone data alone is almost useless. You should backup the original database, not the zone data. May be it is intended to be in 5.3 Registry operations? No mention is done of the *correction* of the name server configuration, something that SHOULD be automated with tools like Zonecheck (http://www.zonecheck.fr/) or even the simple check_soa. A broken nameserver is much more dangerous than a dead one! I also share the concerns of the people who said that the distinction between TLD and SLD is artificial: google.com is probably more strategic than a TLD like BD or JM. In short, this document is really a draft of draft and it is too soon to comment it in depth. Security considerations is completely missing, while it is an fundamental topic and so is Registry/Registrar interface (I hope that EPP will not be regarded as best practice). . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
[dnsop] Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications
On Thu, Oct 20, 2005 at 12:55:36PM +0200, Harald Tveit Alvestrand [EMAIL PROTECTED] wrote a message of 57 lines which said: I couldn't find any discussion of this draft on the mailing list, but the draft says that it should be discussed here, Yes, but DNSop would be more adapted, no? . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
[dnsop] Re: Delegation inconsistency clarification
On Mon, Apr 24, 2006 at 04:48:33PM -0500, John Kristoff [EMAIL PROTECTED] wrote a message of 33 lines which said: ;; ANSWER SECTION: king.com. 172800 IN NS ns.fjordnetwork.com. king.com. 172800 IN NS ns.midasplayer.com. You do not provide the value of the 'aa' flag (Authoritative Answer) which is important here. The delegation NS (in the parent zone) are not authoritative. If in doubt, believe what is in the delegated zone. First, the NS RRset has differing TTL values at the parent and child. Strictly speaking I thought this was a configuration error. Is it? For the value of the NS records, IMHO, yes, it would be an error, but a common one. Some people change the zone without telling the above registry and some registries are so slow/unreliable to change anything that you sometimes do no care to tell them of a change. For the TTL, I hesitate to label it as an error since no registry I know allow the registrant to choose the TTL of the delegation records... (RFC 3731 - EPP - or RFC 3632 - RRP - do not seem to allow the client to set a TTL.) Registry people can check the data model of their database: I believe the TTL is always a global variable and never a per-domain variable. If so, what are the potential issues in such a TTL mismatch that may cause problems with this zone? Not a lot, I hope so, because it is common :-) . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
[dnsop] Re: comments on draft-ietf-dnsop-reflectors-are-evil-00
On Fri, May 19, 2006 at 01:05:22PM -0400, Joe Abley [EMAIL PROTECTED] wrote a message of 255 lines which said: to act as open resolvers, BTW, open resolvers or Open Recursive Nameservers was, it seems, the most common term but the draft calls them PRN (Public Recursive Nameservers). Why the change? . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
[dnsop] Re: I-D ACTION:draft-ietf-dnsop-reflectors-are-evil-01.txt
On Sun, Jul 09, 2006 at 01:24:17PM +0300, Pekka Savola [EMAIL PROTECTED] wrote a message of 46 lines which said: The attacker could just use whatever 3rd party DNS records that already exist, right? Existing actual records do not typically provide a good amplification, they are often too small. So, you are right, this step is no *necessary* but in practice is very common. . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
[dnsop] Re: I-D ACTION:draft-ietf-dnsop-reflectors-are-evil-02.txt
On Tue, Sep 19, 2006 at 03:50:02PM -0400, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote a message of 93 lines which said: Title : Preventing Use of Recursive Nameservers in Reflector Attacks Author(s) : J. Damas, F. Neves Filename: draft-ietf-dnsop-reflectors-are-evil-02.txt I've read it and I find no issues in it and I support it going forward. . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
[dnsop] Re: WGLC for draft-ietf-dnsop-reflectors-are-evil-02.txt
On Thu, Nov 09, 2006 at 01:51:23PM +0200, Pekka Savola [EMAIL PROTECTED] wrote a message of 22 lines which said: My comments from July 7 have not been addressed or responded; it seems these are still relevant in the -02 version. Let's see them: 1) The attacker could just use whatever 3rd party DNS records that already exist, right? I replied to it (the variant you describe is possible but does not seem to be the main concern right now). 2) If the attacker always used its own LRECORDs, the attack would be traceable just by looking at who owns the zone, right? But as the attacker may also use 2rd party LRECORDs, the owner of LRECORD doesn't help in figuring out who was responsible for the attack. Correct. But, in practice, it may be difficult to find the owner of mysubsubzone.subzone.zone.example. 3) I'd also add reference to BCP84 It seems OK. So, I would say that your comments are valid but should not block the document. As it is, it describes the *current* problem, and may be completed in the future by a more general document. . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
[dnsop] Re: WGLC for draft-ietf-dnsop-reflectors-are-evil-02.txt
On Thu, Nov 09, 2006 at 03:59:13PM +0200, Pekka Savola [EMAIL PROTECTED] wrote a message of 18 lines which said: Yes, I saw that, but I believe whether it's the main concern or not is irrelevant -- the question to ask should be, is this variation of attack relevant to the scope of the document? My opinion is No. If we decide it is relevant, the document will take several more months of work to cover a whole class of attacks. . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
[dnsop] Re: Rathole exit? Was: Doug's attack scenarios without SPF
On Thu, Nov 16, 2006 at 07:21:01AM -0800, Douglas Otis [EMAIL PROTECTED] wrote a message of 31 lines which said: SPF is like using scripts, rather than bitmaps, to describe fonts offering any number of features, such as flashing text, moving arrows, and winking smiley faces. I typically never replies to Otis' emails or I-Ds because it is obvious he is just motivated by a personal anti-SPF drive but this presentation of digital typography is ridiculous: using scripts instead of bitmaps for fonts have much more advantages, the most obvious one being the ability to scale the text. If Otis knows about DNS as much as about typography, I understand a lot of things... . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
