Re: [DNSOP] Asking TLD's to perform checks.
On 11/12/2015 01:30 AM, Tim Wicinski wrote: > > (as chair) > > I was the one who told Mark I liked the document but we needed to do > less badgering of TLDs (my words, not his) and more on giving them > advice on the best practices. > +1 I'd like to add that they may be badgered just as hard from the other side not to do too much in this regard; i.e. registrars telling them "Don't tell me how to do my work, even if you think it's wrong". Sure, BCPs may help, but we stopped doing pre-delegation checks for a reason. As Antoin and others have already mentioned, we still do checks, and we inform on a number (but not all) of them. One thing we found (at least that has been my conclusion) is that 'they are doing it better' works *much* better than 'you are doing it wrong'. Removing delegations because of a lame delegation is highly likely to be out of the question. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-00.txt
On 2017-04-05 16:50, Mukund Sivaraman wrote: >> Also, it is weird that a draft that is about having a fallback if a hash >> algorithm becomes weakened uses the RSASSA-PKCS1-v1_5 signature scheme, >> given that PKCS1 1.5 is already known to be weakened. > > It was to allow simple addition of the algorithm to existing > implementations. However, in light of your comment, we'll discuss > revising it. > We can certainly discuss alternative schemes, RSASSA-PSS is a potential alternative, which I understand is considered (much?) better. It has a big drawback though, in that it requires salt, which can be a big issue for large deployments. An advantage would be that then we not only have an alternative within the RSA family for SHA2, but also for the signature scheme itself. Speaking of the use-case to pick up this work; IMO having more cryptographic algorithms ready for use is generally a good thing; we don't have to wait until the existing ones are completely broken :) Jelte signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for
Joe Abley wrote: > > > I think what is interesting to me is to examine EDNS0 availability > amongst the class of queries that can reasonably be answered. I don't > much care whether queries that can't be answered support EDNS0. > > But others may be interested in different things :-) > How important is the actual size advertised in the EDNS0 field? I remember a small but noticeable number of hosts having EDNS0 enabled but set to 512 octets, when i did some stats research a while ago (data has probably aged too much to say anything about it now, just thought i'd mention it). It's still better than no edns0 because it means the code is there and it's probably a configuration thing, but still. Jelte signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gervase Markham wrote: > Florian Weimer wrote: >> * Jamie Lokier: >> Yes. I think Ebay suffers from these issues. > > Indeed. This is one of the reasons that livejournal switched from > www.livejournal.com/name to name.livejournal.com. It prevented rogue > code on user sites stealing the cookies of other users. > won't they run into the very same problem if only tld's (and their sld's) are marked as don't-set-cookies-here? Or is livejournal.com also supposed to get on the list of public suffixes? And will they care? (well, livejournal might, but i could imagine some others not to care enough to get themselves on it) Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIT4+T4nZCKsdOncURAqZkAKCOxkwMs6By3zxef2AhKU7nP9+0qgCbBJZd sEApH+yga8r+DXQVN76qpMQ= =SP/N -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
Jaap Akkerhuis wrote: > On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote: > > > it in their products or services. Peter Koch did provide an > interesting > > data point that warrants further investigation (20-35% of queries > having DO > > bit on seems a bit high to me) and someone else responded privately > that > > I seem to remember that some time back (two years or so?) RIPE-NCC > also published data points and they were in about the same range. > > Title: Measuring the resource requirements of DNSSEC > Author: Olaf Kolkman > > The URL for this: ftp://ftp.ripe.net/ripe/docs/ripe-352.pdf. > > Already three years ago, time flies > We also did another one for ripe a little bit later, but still more than two years ago: http://nlnetlabs.nl/downloads/publications/dnssec/dnssec-effects.pdf Jelte signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] suggestion for 4641bis: key algorithm rollover section
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, during some work on DNSKEY maintenance, I think i found a potential operational issue. If we are going to do new work on DNSSEC Operational Practices, I would like to suggest to add a text similar to that attached to this message. The issue lies in the combination of algorithm downgrade protection and caching, and can result in a small window of time (depending on TTLs), where all data in a zone could be considered bogus by validators. RFC4035 states the following (section 2.2): There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. While this poses no problem when an admistrator rolls a key with an algorithm that is already present in the keyset, it can do so when introducing new or removing old algorithms. Caches may have both the old keyset and the old rrsets with signatures stored. When a new keyset is introduced, and the keyset happens to expire in the cache before the signatures do, the cache will retrieve the new keyset. Since it still has the rrsets with old signatures, it will see no reason to update those. Now the validator will encounter a key with an algorithm for which there are no signatures. This is prohibited by the earlier statement in RFC4035, resulting in rejection of the data. When removing an old algorithm, the same problem can occur when the signatures expire in the cache before the keyset. This can be prevented by not adding or removing both the keys and the signatures at the same time. Proposed addition to rfc4641diff attached in the hopes that the text is not mangled by my mail client. It might need a bit more of the problem description though. Any thoughts? Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki/r2YACgkQ4nZCKsdOncU9FACgoDkXP0PUjrdZTiJmiXNpxJ8X oMEAoJBougDT51O6MacOpzoV8/5ZsUyg =ab7S -END PGP SIGNATURE- When rolling key algorithms (either adding a new algorithm, removing an old algorithm, or both), additional steps are needed to retain integrity during the rollover. Because of the algorithm downgrade protection in RFC4035 section 2.2, you may not have a key of an algorithm for which you do not have signatures. When adding a new algorithm, the signatures should be added first. After the TTL has expired, and caches have dropped the old data covered by those signatures, the DNSKEY with the new algorithm can be added. When removing an old algorithm, the DNSKEY should be removed first. To do both, the following steps can be used. For simplicity, we use a zone that is only signed by one zone signing key. 1 Initial 2 New RRSIGS 3 New DNSKEY SOA0SOA1 SOA2 RRSIG1(SOA0)RRSIG1(SOA1) RRSIG1(SOA2) RRSIG2(SOA1) RRSIG2(SOA2) DNSKEY1 DNSKEY1DNSKEY1 RRSIG1(DNSKEY) RRSIG1(DNSKEY) DNSKEY2 RRSIG2(DNSKEY) RRSIG1(DNSKEY) RRSIG2(DNSKEY) 4 Remove DNSKEY 5 Remove RRSIGS SOA3SOA4 RRSIG1(SOA3)RRSIG2(SOA4) RRSIG2(SOA3) DNSKEY2 DNSKEY2 RRSIG1(DNSKEY) RRSIG2(DNSKEY) RRSIG2(DNSKEY) In step 2, the signatures for the new key are added, but the key itself is not. While in theory, the signatures of the keyset should always be synchronized with the keyset itself, it can be possible that RRSIGS are requested separately, so it might be prudent to also sign the DNSKEY set with the new signature. After the cache data has expired, the new key can be added to the zone, as done in step 3. The next step is to remove the old algorithm. This time the key needs to be removed first, before removing the signatures. The key is removed in step 4, and after the cache data has expired, the signatures can be removed in step 5. The above steps ensure that during the rollover to a new algorithm, the integrity of the zone is never broken. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Andrews wrote: > It's not a issue. You remove the DS's which have that > algorithm then once they have expired from caches you can > remove the DNSKEY. That could still leave the zone itself in an inconsistent state... I'm not talking about the DS<->child apex case, but the apex<->zone data case. The DNSKEY that is removed or added doesn't have to be one that is pointed to by a DS. Merely being present in the apex implies that there should be signatures of that algorithm in the zone. If you don't add/remove all keys at the same time, the first or last DNSKEY couldn't even be a KSK; since those keys aren't used to sign the zone data, having a KSK as the only key of a certain algorithm number would always violate section 2.2. Unless of course I am misreading that MUST there :) Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki/444ACgkQ4nZCKsdOncVoEACg2XThBDfSoUosRQBUTDcL2jYg bKkAoKNU4hLa/s5/xPlGVQp6XKXV7Uyv =TLej -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Resending my message because of the ietf mailing list problems - Original Message Subject: Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section Date: Fri, 05 Sep 2008 10:32:35 +0200 From: Jelte Jansen <[EMAIL PROTECTED]> To: Mark Andrews <[EMAIL PROTECTED]> CC: dnsop@ietf.org References: <[EMAIL PROTECTED]> Mark Andrews wrote: >> No. The DS / published trust anchor indicates support for >> the algorithm. Just having a DNSKEY at the apex does not >> indicate support for a algorithm. > We must be reading this part differently... There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). What I'm getting from this is that the keyset at the apex must (at least) be signed by each algorithm in the DS referral, and every rrset in the zone must be signed by each algorithm in the apex keyset. Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwVz34nZCKsdOncURAskUAKCyD/4RFmp5urc2aJjP1sZfdxcSTQCfVcWj kN7cm1ZnZqOqi8HfB16ECeo= =Z2Mw -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
I'll take the liberty to resend Mark's messages too; Resending Mark's reply to Dean Anderson's message Original Message Subject: Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section Date: Fri, 05 Sep 2008 09:35:43 +1000 From: Mark Andrews <[EMAIL PROTECTED]> To: Dean Anderson <[EMAIL PROTECTED]> CC: Jelte Jansen <[EMAIL PROTECTED]>, dnsop@ietf.org > On Thu, 4 Sep 2008, Mark Andrews wrote: > > > > > It's not a issue. You remove the DS's which have that > > algorithm then once they have expired from caches you can > > remove the DNSKEY. > > Of course, you can replay them, resulting in a DOS. (I'll call > this attack 6) Wait for the signatures to also expire. The replayed DS RRset will then be rejected. Pick your paranoia level. Mark -- 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] suggestion for 4641bis: key algorithm rollover section
And Mark's reply to my previous message: Original Message Subject: Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section Date: Fri, 05 Sep 2008 18:39:49 +1000 From: Mark Andrews <[EMAIL PROTECTED]> To: Jelte Jansen <[EMAIL PROTECTED]> CC: dnsop@ietf.org > Mark Andrews wrote: >>> No. The DS / published trust anchor indicates support for >>> the algorithm. Just having a DNSKEY at the apex does not >>> indicate support for a algorithm. > > > We must be reading this part differently... > >There MUST be an RRSIG for each RRset using at least one DNSKEY of >each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset >itself MUST be signed by each algorithm appearing in the DS RRset >located at the delegating parent (if any). > > > What I'm getting from this is that the keyset at the apex must (at > least) be signed by each algorithm in the DS referral, and every rrset > in the zone must be signed by each algorithm in the apex keyset. > which is referred to by a DS / trust anchor. DNSKEY's are never referenced in isolation. There is always a DS / trust anchor which specifies which algorithms are in use. Mark -- 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] suggestion for 4641bis: key algorithm rollover section
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Andrews wrote: > > What I'm getting from this is that the keyset at the apex must (at > least) be signed by each algorithm in the DS referral, and every rrset > in the zone must be signed by each algorithm in the apex keyset. > >> which is referred to by a DS / trust anchor. > >> DNSKEY's are never referenced in isolation. There is always >> a DS / trust anchor which specifies which algorithms are >> in use. > is that actually said anywhere in the DNSSEC RFCs? Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwliF4nZCKsdOncURAqMFAKDHV8eQ9E8zLnr5FsSvBL+wkWPgtQCgln2n xKvYKLTX8DkH9A5QMvoDgTE= =szS2 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AD bit set by authoritative servers [was: Re: More solicitation for feedback on dns64]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Edward Lewis wrote: > At 1:28 +0100 3/27/09, Holger Zuleger wrote: > >> So why doesn't an authoritative name server set the AD bit on answers >> to queries with the DO flag set? > > Good question. Perhaps the authoritative server does not have DNSSEC > enabled? > > (BIND specific - in recent versions of BIND, since Feb 2007, if > dnssec-enabled is not yes, it doesn't do DNSSEC processing.) > I would say that AA=1 already gives you more information than AD would; you can't really get more authenticated than being authoritative for the data (from a sender's point of view). So setting it or not wouldn't add any information. Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknMf+gACgkQ4nZCKsdOncVWSACfRoVu2QBy5UlmRf/bIGWdocmI wyIAoLinx0yHJNs+VreNafyZ9F2/tOaQ =UDOT -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Key sizes was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Hoffman wrote: > > At 11:32 AM -0400 4/24/09, Paul Wouters wrote: >> So it seems to me that using 1024 bit RSA keys for ZSK, and 2048 bit >> keys for KSK, assuming RFC 4641 rollover periods, are still many orders >> of magnitude safe for our use within the DNSSEC realm. In fact, it >> seems RFC4641, as written in 2006, is still extremely conservative in >> its estimates two and a half years after its publication date. > > That is fine, but so is 1024 bit KSKs. The text in RFC 4641bis makes it clear > that KSKs should be rollable in case of an emergency; the effort to do so is > greater, but not that much greater, than rolling a ZSK. > > The WG should decide which seems better to recommend: > > a) KSKs longer than ZSKs because KSKs are thought of as needing to be stronger > > b) KSKs the same strength as ZSKs because neither should be weak enough to be > attacked > > I prefer (b), but (a) keeps coming up in this discussion. > The dimension I'm usually missing in these discussions is the lifetimes of keys and the lifetimes of the signatures created with those keys (although it is mentioned above). I always understood the reason for having two key types is so that one of them can be rolled more often, and have shorter signatures lifetimes, while the other one lives longer, and is needed less often. So the first one would not need to be as strong as the second one. So on the one hand, neither key should be weak enough to be attacked at all. But on the other hand, if they are equally strong, they're gonna attack the one that has the longest lifetime and/or the longest signature lifetimes. It seems to me that it would then make sense to roll/resign with the KSK as least as often as you roll/resign with the ZSK (since they are equally strong). It's probably the friday talking, but in that case, why even have a KSK at all? Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknx9v4ACgkQ4nZCKsdOncWuXwCfdQt+Ht1FvcUbracXxi6AKrV8 DWEAoLPkxvUwUrL55ymLIuEv5IyFZ9mn =n92f -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Ralf Weber wrote: No redirection on SERVFAIL seems to be a strange recommendation. Wouldn't this be a very good reason to provide a diagnostics page, especially if there's been a DNSSEC validation failure? This sounds like an excellent idea to help DNSSEC adoption and is something that should go into the draft. then a SERVFAIL will also result in an e-mail bounce that says connection refused instead of DNS error (assuming there's no e-mail sink on the host that is redirected to). Fun times for the helpdesk. I have the impression that even though it tries not to, the document still assumes that web==internet, mentioning problems 'non-web clients' only as a small side-effect, while imho it should be one of the main concerns (the www-case is the easy one). Also, I don't see how the ISP trust anchor for DNSSEC would work (not knowing the actual zone that it is supposed to cover in advance); it might be a better idea to simply disable all redirects on DO==1. Then again, I am of the persuasion that messing with a core protocol on the fly is simply asking for trouble, and disabling redirection should be top priority for everyone. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Florian Weimer wrote: * Jelte Jansen: Ralf Weber wrote: No redirection on SERVFAIL seems to be a strange recommendation. Wouldn't this be a very good reason to provide a diagnostics page, especially if there's been a DNSSEC validation failure? This sounds like an excellent idea to help DNSSEC adoption and is something that should go into the draft. then a SERVFAIL will also result in an e-mail bounce that says connection refused Not a hard 5xx error? not unless there's also a specific 5xx error generator listening on the host that is redirected to, i guess. instead of DNS error (assuming there's no e-mail sink on the host that is redirected to). Fun times for the helpdesk. Only if the mail server falls back to the A record if the MX lookup results in SERVFAIL, which seems like a questionable approach to me. is it? (i'm asking, i don't know; even the updated smtp rfc seems a bit unclear about that) Anyway, I think DNS rewriting is mainly for folks who also block 25/TCP in- and outgoing or list the address space on the PBL and similar DNSBLs, so the SMTP argument is not really valid anymore. well in that case it might be worth adding a section that your own services should definitely not have the same resolvers that you have set up for your customers, and that a separate non-lying resolver should be set up for those. But this is just an example of an unintended side effect from assuming that only web browsers ask for A/. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] nameserver control protocol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
i had asked for a small AOB slot at the dnsop meeting, but only just before, so
either it was forgotten or simply skipped because we were already late, so i'll
just misuse the mailing list instead. My apologies :)
A while back, a requirements document for a nameserver control protocol was
written. I've been told this document is as good as done. There was also a draft
document on an actual protocol, which by now has expired.
I'm interested in restarting work on this. Since this is actually a protocol, it
doesn't suit the charter of the dnsop wg. However, the people in the dnsop group
are the ones who might be interested in this, so i want to know if there is
interest and/or energy to get that work done outside of dnsop. Perhaps we can
even create a new working group for that (one that defines some work, gets it
done (or declares failure), and disbands like they're supposed to ;) ).
I think there might be some interest in this, but i don't know. So if you are
interested, or have some ideas or thoughts about this ('this' being getting the
work done, not contents of the drafts), please let me know (tackle me in the
hallway or drop me a line off-list).
Thanks,
Jelte
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkr6WBgACgkQ4nZCKsdOncUrEwCeLcyWqnecH9NHCliikKJYQifa
u5IAnjghgvfmGJ21KYTWm82kcRFres5y
=jS/y
-END PGP SIGNATURE-
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] what i said at the mic (re: dnssec-key-timing)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, the slide that mentioned algorithm rollover mentioned it at a diagram of double-signature rolls, which will probably not be sufficient for that, see http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-01#section-4.2.4 (btw i agree with olaf that some form of collaboration between these documents might be nice) as for the current section on algorithm rollover, i simply don't understand it. But that might be because my brain tries to shut down at the part mentioning different TTLs there). I think a reference to 4641bis and a scheme to match the text there would be nice Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr6eRIACgkQ4nZCKsdOncVaOQCfVn12/XrqedbgI4YUgJ/sML6w YbsAnAhuPRy7jCw3bZk8w4kKAAmy6/N6 =CueD -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what i said at the mic (re: dnssec-key-timing)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johan Ihren wrote: > > I don't remember exactly what I said, but what I meant was not that > "double signature" is sufficient to accomplish an algorithm rollover, > only that it was needed as part of one. So I think you and I agree hee. > I think so too, mostly :) I would dub what I proposed for algorithm rollovers 'reverse double signature' >> (btw i agree with olaf that some form of collaboration between these >> documents >> might be nice) > > Of course there will be, although I'm still skeptical about circular > dependencies. > Of course, though i rather see a circular dependency than an inter-rfc inconsistency. I was thinking more of collaborative documents :) > > This falls down into the question about whether to cover all the > rollover "methods" or make a recommendation and only cover that > alternative. My take away from the WG was that the key timing doc should > not make recommendations, but describe all the alternatives. > Well, since I am the proud owner of the humble opinion that algorithm rollover requires a substantially different method, I would personally like to see that method covered as well. >> I think a reference to 4641bis and a scheme to match the text there >> would be nice > > My primary issue with that is that as soon as we refer to 4641bis there > is a circular dependency and then the two documents must be published > together. My secondary issue is that I maintain my position that the key > timing document is "theory" while 4641bis is "practice". Therefore, as > the key timing document covers a more narrow topic in greater depth, > there is just no way to avoid references from 4641bis to us. > Ah, now there may lie the (a?) problem. I was thinking of 4641bis as the defining rfc (ie. what to do), and key timing as a mathematical description of (some of) the methods mentioned in the former (ie. how to do it). Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksDCtEACgkQ4nZCKsdOncVzlACgnpChOSLEoQ5jeIzbOVWRusEY GIEAoKKi9RxVxbFHoo56IEoT68jZxT5Q =ZVam -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] my jabber question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, so audio lag + jabber lag + trying to get a question into one line for relaying does not a easygoing discussion make :) My question was this; in the presentation I saw a list of issues that are considered resolved and a list of issues that are still open, but one of the 'new' things in 4641bis is: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll (now section 4.2.4 in the ID, not 4.2.5) And I just wanted to know what the perceived status is (I guess this one is still open). Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuqeWQACgkQ4nZCKsdOncUQRgCgkN2Jstvotyr8vRJEwAYjxV/5 rB0AnAkXTho7rcHE7xokqvgpMqdtOmp0 =GGrL -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] grave erroneous statement in draft 4641bis-03
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 the introduction suggests that the root has not been signed yet. Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAkxOp3AACgkQ4nZCKsdOncXkGQCYolq1E11tEZzafc34fiiNqI7L 7ACeJUEh+I0mNijb6h9CFl3EW1Ijcwk= =9Gyp -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] FYI: New Non-WG Mailing List: nscp -- DNS Nameserver control/configuration protocol discussion list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, forwarding this announcement here, since this list contains a lot of people likely to be interested in the effort; if you also follow ietf-announce, my apologies for the double message. There is now a mailinglist for nameserver control protocol work; n...@ietf.org. Since it is protocol work, it falls out of scope for dnsop. The initial goals of the list are to come to a full problem statement, determine the scope, and create a charter for a working group (or, possibly, come to the consensus that one is not needed, but at this point, I think we do). Please come and join the fun :) Jelte - Original Message Subject: New Non-WG Mailing List: nscp -- DNS Nameserver control/configuration protocol discussion list Date: Tue, 14 Sep 2010 13:29:03 -0700 (PDT) From: IETF Secretariat To: IETF Announcement list CC: n...@ietf.org, je...@isc.org A new IETF non-working group email list has been created. List address: n...@ietf.org Archive: http://www.ietf.org/mail-archive/web/nscp/ To subscribe: https://www.ietf.org/mailman/listinfo/nscp Description: This list is intended for initial discussion relating to the development and implementation of a control and configuration protocol for DNS nameservers. This work is a followup of the requirements stated in draft-ietf-dnsop-name-server-management-reqs-04 (currently being processed for RFC publication). An initial draft that proposes a solution is draft-dickinson-dnsop-nameserver-control-00, but this draft expired after it was deemed out of scope for the dnsop working group. The immediate goal of this list is to come to a full problem statement, and the creation of a charter for a working group. For additional information, please contact the list administrators. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyTVdgACgkQ4nZCKsdOncX0PwCfQugU0/VQRjHeMenHyy/pH/6y smwAoJsYhzVijfZeJ4KIhgNz2liN+TIf =V+uM -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on RFC4641bis
On 11/09/2010 02:33 AM, Roy Arends wrote: 4.2.1 KSK Compromise (2nd paragraph) A compromised KSK used by an attacker can also sign data in the zone other than the key set. An attacker does not need to follow the definitions of KSK vs ZSK. I wonder how different implementations handle this case.. I have tested chains of trust (with BIND9 and unbound) in the past and noticed that its validity did not depend on the SEP bit being clear or set. If they did, they would not follow the spec ;) A SEP key can be a ZSK too. The only value of the SEP flag is for operators and/or tools, validators should ignore it. Whether or not a key is a ZSK, a KSK, or both, is, from the validator's point of view, defined by whichever signatures you see. So yes, if you can make arbitrary signatures with a compromised key, you can 'change' its KSK/ZSK status, and no validator should be able to notice. But well, you can make arbitrary signatures anyway... Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSCP Pros and Cons: draft-dickinson-dnsop-nameserver-control
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2010 12:36 PM, Stephen Morris wrote: > At the WG meeting in Beijing, the somewhat inconclusive discussion on a > nameserver control protocol was ended by the suggestion that the authors of > the two drafts discussed should write a short piece discussing the pros and > cons of their proposals and post it to the list. This is that piece for > draft-dickinson-dnsop-nameserver-control. > > > Pros > 1) A standard data model > This was one of the requirements identified in > draft-ietf-nameserver-management-reqs and is the core of NSCP. If a > sufficiently complete model covering a reasonable number of nameservers can > be identified, it will be possible for even basic clients to perform a useful > set of functions. > It has been said (perhaps by you) that perhaps we ought to think about splitting up the data model and the protocol. I'm not sure about the advantage of that (well, apart from doc length), but thought i'd mention it. > 2) Use of a standard protocol > Use of NETCONF provides the necessary protocol superstructure to support > remote management of nameservers. Amongst other things it provides: > > Cons > 1) No mechanism for automatically copying configuration from one nameserver > to another. > especially missing for that is a classification of what is considered 'local' and 'general', if such a classification can be made at all > > Work Required > At present, the data model is still rudimentary. Detailed attributes still > need to be defined for each entity, in particular for the "DNSSEC Policy" > object. As a way forward, the first step should be to concentrate on refining > the data model. > +1 Two more things, I've also heard complaints about Netconf/yang being overkill, do we know if this is about netconf, yang, or both? Related to that, someone proposed a RESTful protocol, but noone made a specific proposal for that. Should we try to get someone to do that? :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0F3nsACgkQ4nZCKsdOncX+LwCgwGDSWkIVLl8ZRRZj/zS+0js4 P3EAn2ewDxv4zmXvogi0Sue6QFZPc5r3 =hX74 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSCP Pros and Cons: draft-dickinson-dnsop-nameserver-control
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/26/2011 06:58 PM, Stephen Morris wrote: > To restart the dormant discussion on NSCP... > keeping it on life-support :) > On 13 Dec 2010, at 08:51, Jelte Jansen wrote: > >> It has been said (perhaps by you) that perhaps we ought to think about >> splitting >> up the data model and the protocol. I'm not sure about the advantage of that >> (well, apart from doc length), but thought i'd mention it. > > In part it is document length, but also to allow the development of NSCP to > proceed without getting side-tracked by discussions on whether NETCONF should > be used as the underlying protocol. > So would the 'data-model' be completely abstract or still represented in an existing language (or both, where the language serves 'as an example'?) > >> Two more things, I've also heard complaints about Netconf/yang being >> overkill, >> do we know if this is about netconf, yang, or both? > > I've also heard mutterings along those lines, but nothing definitive. > > NETCONF was proposed as the underlying protocol for the reasons outlined in > the draft. I don't think it is overkill, as anything that implemented NSCP > would need to supply a lot of the functionality that comes with NETCONF. > Right. It was also specifically made for things like this, although 'back in the day' there weren't much ready-to-use libraries for it. I hear things are better now but I must confess I haven't looked :) > With regards to YANG, that was in development around the time NSCP was being > developed. As it was being promoted as a data modelling language for NETCONF, > it made sense to use it for a NETCONF-based application. However, it is new > and the specification, RFC 6020, is over 170 pages long; perhaps that it > putting people off? If we don't use YANG for NSCP, what should be used? > no idea... > >> Related to that, someone proposed a RESTful protocol, but noone made a >> specific >> proposal for that. Should we try to get someone to do that? :) > > If someone would like to formally propose a RESTful approach, that would be a > useful contribution to the discussion. But whatever the underlying protocol, > we still need to get agreement on the data model. > If someone is actually looking into or working on this, please give a ping, even if it isn't much formed yet Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1KihMACgkQ4nZCKsdOncXb8gCfbE3R0cjs0zoffhcaKX6IV4R2 s/AAoJmxK28zc8EbStIK/K9SmvXiYEzi =zw7f -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Rough Draft of minutes from IETF88
On 11/12/2013 09:20 AM, Tim Wicinski wrote: > > I've uploaded the minutes, with an initial editing pass. There are > located here: > > http://www.ietf.org/proceedings/88/minutes/minutes-88-dnsop > I wasn't there, and wasn't able to follow remotely this time, but I assume that "Evan Hunt: csync is push, competitor (dynamic update, see Mark Andrews) is pull." was actually the other way around. And a side note about a later topic, PCP to update Dynamic DNS, I had actually seen that draft, and object to the statement that 'SRV http is not yet supported by a lot of browsers'. I haven't been following the http specs recently but last time I checked, SRV wasn't defined for http, so browsers *shouldn't* 'support' it. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 03/03/2014 09:25 AM, Norbert Bollow wrote: > Warren makes a strong argument in favor of .alt I think. > > Another related aspect is that if something like onion.notreallydns.org > is used, with notreallydns.org registered for the specific purpose of > providing a home for one or more non-resolving dns-like names, it > is very non-trivial to guarantee that whoever has registered the > notreallydns.org name will continue paying the yearly fees forever. If > the registration lapses, an attacker could become the new holder of the > notreallydns.org domain and use it to snoop and/or serve malware... > more generally, even if one person/institution holds that name forever, they/it can change their mind about catching the data there (and/or responding to it). So your protocol/security tradeoffs change when this approach is chosen compared to reserving it for explicit non-use. While the reservation can be pulled anyway, IMO it would be a much greater barrier should one try to do so. (not leaning either way myself at this point) Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 03/03/2014 01:43 PM, Ted Lemon wrote: > On Mar 3, 2014, at 1:32 PM, Tony Finch wrote: >> As well as Joe's AS112 argument there is also the question of DNSSEC >> validation - but perhaps we don't want non-DNS names to make any kind of >> sense in this respect... cf. .local > > Indeed, it doesn't make much sense to me that special-use names that are not > intended to be resolved using the DNS should be validateable via DNSSEC. If > they can be validated, it would have to be using whatever protocol is being > used for name resolution (if any). > +1 This is something I asked about at the app session, and have been wondering; (why) are we worried about non-dns names at all? More importantly, where do we draw the line? "A domain by any other name?" Is anything sequence of characters that happens to maybe contain a dot a domain name? Is it that it *might* end up in some code path that tries to resolve it, even though the normal use doesn't use (the global) DNS at all? To make a crazy example; the left-hand side of an e-mail address also contains dots, but we're not worried about those somehow ending up in a resolution call. Neither were we worried about 'command.com' being resolved (and it does). I'd think that a domain name is only a domain name when whatever protocol it is defined in defines it as a domain name (or whatever undefined protocol uses it in actual dns resolution). What a non-domain name looks like shouldn't matter. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 03/03/2014 02:03 PM, Andrew Sullivan wrote: > On Mon, Mar 03, 2014 at 01:56:20PM +0000, Jelte Jansen wrote: >> I'd think that a domain name is only a domain name when whatever >> protocol it is defined in defines it as a domain name (or whatever >> undefined protocol uses it in actual dns resolution). What a non-domain >> name looks like shouldn't matter. > > Are NetBIOS names domain names? How about mDNS names? I think yes, > but neither is part of the DNS as such. > I was wondering whether I should have stated that a bit more carefully, but 'part of the DNS' might be a different thing than 'could use DNS'. I wasn't suggesting there shouldn't be any reservations, but 'looks like a domain name' is way, way too wide a definition. In that case we need to reserve any possible TLD. Including all existing gTLD and ccTLD's. As for mDNS, I do not know; you tell me :) Is there a problem in anything that is *not* either a definite bug in a program or a user copy-pasting the name in a browser window? Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my dnse vision
On 03/05/2014 01:27 PM, Francis Dupont wrote: > > Personally I don't like the idea of DNS encryption but because I > don't want to give a reason to ISPs to filter port 53. > This is something I worry about too. If we consider the resolver itself out of scope, and only protect the wire, all the more reasons for ISPs to try and force you to use theirs (perhaps even after some friendly coercion from the nearest three-letter agency (four in the netherlands as well)). In which case we'd need even better channel encryption, to the point where you can't tell it's DNS, so it can be tunneled out of the network (and that is an avenue only reserved for us geeks, I wager). Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] some random dnse-triggered thoughts
On 03/05/2014 02:40 PM, João Damas wrote: > > perhaps there is a need to separate the problem into tractable > chunks. For the part of the problem about authenticating the > recursive resolver (the fake 8.8.8.8 problem) we probably a > different solution than for the metadata snooping problem (who is > asking for what). Perhaps it might be the case there are already > existing features that can be used to get what we need (e.g. SIG(0) > for the recursive resolver, wild!) and, as Roy Arends was > mentioning over a few drinks, onion-like routing to separate the > who from the what in questions in an effective manner. These could > be even user-triggered on demand for certain traffic types (For > instance as a consequence of turning on private browsing in a > browser), so the overhead penalties are only incurred for the > desired subset of traffic. > +1. I don't want to fight about requirements for 10 years, and it does look like there are different and competing views as to what constitutes confidentiality here. So a split into several problems, which can have shared or separate solutions, seems like a good start. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my dnse vision
On 03/06/2014 02:39 PM, Stephane Bortzmeyer wrote: >> all the more reasons for ISPs to try and force you to use theirs >> (perhaps even after some friendly coercion from the nearest >> three-letter agency (four in the netherlands as well)). In which >> case we'd need even better channel encryption, to the point where >> you can't tell it's DNS, so it can be tunneled out of the network > > If we follow this line of reasoning, why do we deploy more security, > then? With this argument, we would never have deployed HTTPS > either. (Or SSH: most hotspots and many ISP block SSH.) > And lo and behold, you do see forced breakage of SSL, and 'friendly' MITM attacks forced on people. But I'm not saying we shouldn't do anything. I'm saying that I'm worried that if we blindly splat some channel encryption on, we may actually lower security for a number of people, in which case we need to go even further and hide the fact that DNS data is being sent in the first place. Now this may very well have been solved (VPN/SSL tunneling, one of the existing specific-to-dns channel solutions), but in that case we should probably be explicit about it. But really I was working up to my next message, that was a +1 on splitting up the various problems, and fix (or not fix) those separately. That might even include not trusting your resolver in the first place. > We promised in Vancouver to seriously strengthen the Internet against > surveillance. Was it an empty promise, politician-style? > I think we are all trying to do exactly that. Or, to be a bit more precise and/or cynical: Of course it was, but we are trying to do it anyway. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...
On 04/01/2014 03:39 PM, Phillip Hallam-Baker wrote: > > Yes, I agree, but you are proposing a different DNSSEC model to the one > they believe in. > > The DNS world has put all their eggs into the DNSSEC from Authoritative > to Stub client model. They only view the Authoritative to Resolver as a > temporary deployment hack. > > So they resisted the idea of an authenticated Stub-client <-> Resolver > protocol and they dumb down the crypto so their model will work. > > > Weakening the crypto algorithms to make the architecture work is always > a sign that the wrong architecture is being applied. > Oh come on. If anything, one would expect that doing the validation on the end machines is *easier* despite needing more cycles to do so, since there is much less work to do and generally much more cycles to spare. So I don't see your reasoning about 'them' follow up into this conclusion here. The way I read it, Olafur is asking for people to consider other sizes, and operational issues, rather than simply saying "double 'em up, yeeha". One may disagree (I do too, as it happens, for different reasons), or one can consider it and still come to the conclusion that 2048/4096 are the only right sizes (for now, we'll need better algos soonish I guess). Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
On 05/16/2014 02:18 PM, Andrew Sullivan wrote:
>
> First, if resolvers have expectations about consistency of zones and
> so on, then they're broken. The DNS has only ever been loosely
> coherent. You're simply _not allowed_ to make that assumption from
> any point in the network except inside the authoritative server and,
> maybe for certain kinds of consistency, in the slaves of the same
> zone.
>
There are always assumptions; For every little bit that doesn't happen
to be specified (of which there were an awful lot back in 103X), you
assume an interpretation (or one of a select set). We try to minimize
them by exhaustive specification, but that doesn't always work.
Furthermore, sometimes there are views and models derived from the
actual rules, which can be seen as rules because they are not
contradicted in the current set of specifications. Changing something so
that those are no longer valid can be done, but the implications need to
be considered. This to me is also why there are Considerations chapters
in RFCs.
Some assumptions are considered broken ("DNS packets always < 512 bytes,
and firewalls should drop larger ones"), some are not ("any order of A
records in an rrset is equally valid so always just pick the first
one"). On yet others the verdict isn't always clear ("SERVFAIL means a
server isn't authoritative for the queried zone").
In this case, an assumption that changes is what 'loosely coherent'
actually means, and whether or not you can, in fact, cache answers, and
hand the same out to whomever sends them the same question. They may not
make any assumptions about the content they pass on, but they certainly
do make a few about its validity and timeframe (namely, that it doesn't
change until the TTL expires, and that it is the same for everyone).
To implement client-subnet means to implement a form of views within
your resolver in the form of split caches. If you don't implement it at
all there is no problem, but it certainly does change the model of the
world that resolvers have for those that do.
I don't think this is necessarily a problem, and as far as CDN's go, I
think the proposed draft is quite nice, and actually addresses this
problem. But things like that should certainly be considered. To name
something, what is the effect on forwarders? (what are forwarders in the
first place? what are their assumptions, do we consider those wrong? are
there any in deployment? is it a problem?)
Jelte
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On 05/18/2014 07:58 AM, Patrik Fältström wrote: > >> It might be worth actively pushing the CDN folks to go the SRV direction. >> Even if ENAME were a good idea, which is not clear to me, it's an idea that >> would require significant infrastructure changes, whereas SRV records appear >> to be functional now, with no DNS software changes. > > As I have stated several times I disagree with any statement that claim > "significant infrastructure changes". > > This usage is the reason I did define the URI resource record, so that one > could get a "redirect" already in DNS instead of escaping to HTTP. > > example.com. IN URI 1 2 "https://foo.hosting.bar/example.com/startpage/en"; > So can that be used instead of specifying something where the initial proposal casually mentions "This would require a dnssec algorithm bump"? Not saying this to move it from dnsop to any other list or group, but that line alone implies there's a significant protocol change. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On 05/20/2014 12:12 AM, David C Lawrence wrote: > > Looking at a random high-traffic DNS server on our network, I see > practically no use at all of _http._tcp SRV requests. Over 6 days of > logs on this machine, they are just over 0.7% of all requests. > (Yes, that decimal point is right.) Exactly 90% of them are for the > same hostname, with a name that implies to me that one application, > not a web browser, is responsible for all of them. > That's technically 0.7% too many, as the SRV RFC specifically mentions not to use it for protocols if there's isn't a document stating how to exactly use it with that protocol (mainly, as Ohta-san already mentioned, what to do with apparent data conflicts and a security considerations section), so right now browsers are not supposed to use SRV for http requests. That certainly doesn't mean we shouldn't go forwards and try to introduce such a document together with the http people. I never did find out why Mark's proposal didn't take. Regardless of whether we should go forwards with ENAME, btw. I think having SRV for http would be nice anyway. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qname-minimisation
On 01/05/2015 05:55 PM, Bob Harold wrote: > Does anyone have actual data on how common it is, so we can make an > informed decision? > > I would expect "www.something..." to be in the same zone as > "something..." in most cases, so I think it is actually very common to > have more than one level on the same DNS. > Would you? I'd expect 'www' there to be in 'something', and 'something' to be in a TLD (assuming context of a 3-label domain, not counting root) So for www to be in the same as something would mean it'd be in the TLD... Not saying that it might still not be common, but 'www' is not a good example, IMHO. The other question is not whether it is common, but whether the optimization is actually as benificial as one might think. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
