[DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP

There are two major reasons for an organization to not want roaming users to trust locally-assigned DNS servers. Open recursive servers doesn't help in against man in the middle attacks. If you want to avoid that use VPN's or (for DNS) TSIG. I seem to remember that the ID actually

Re: [DNSOP] New Draft Charter

On 11-Mar-2008, at 10:37, Dean Anderson wrote: So root and gTLD DNS server operations supervision is off the charter? I'm not sure it was ever on the charter. It is in the current charter ... jaap ___ DNSOP mailing

Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))

Also, a well behavng resolver has way less request to the root servers then to other servers. Why, do you think, that servers other than the root servers won't reply with oversized messages? Don't twist my words. I never said that. jaa

Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))

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

Re: [DNSOP] Microsoft updates RFC 2606

I just discovered that Microsoft registered tempuri.com (and .org) and apparently promotes them for use in documentation and examples, ignoring RFC 2606. Actually, if you read the text at that link, it is for using in experimental XML namespaces. jaap

[DNSOP] numeric labels

I haven't read the draft yet, but the discussion whether numeric labels are allowed seems to get slightly out of hand. Anybody can use them and apparently people are. That is easily proved but running something like: for i in `seq 1 1 1000`; do echo $i; dig +short $i.com; done and

Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt

does this mean my chances for ^B. are nil? :) Go for it! I claim ^S jaap ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt

Does not ISO3166 solve that problem for us with regards to allowed characters in the TLD label? No. The alpha-2 used for ccTLD labels (and also the alpha-3) codes are restricted to the set A-Z. jaap ___ DNSOP mailing list

Re: [DNSOP] Priming query transport selection

What does a DNSSEC-protected priming query gain you? I was about to ask the same question. Accepting any old priming query and having a root SEP configured, if the query is right all things work. If the query is wrong/forged you won't get anywhere any how. (Without

Re: [DNSOP] Priming query transport selection

Well having TCP used for all priming queries would make me feel better as TCP traffic is harder to forge. So let's forget about dnssec an do everything over TCP? But seriously DNSSEC signed and validated data should protect the the resolver from going to the forged

Re: [DNSOP] automatic update of DS records

either have a bof (formal) or a small lunch mtg during the week of IETF77? I'd be glad to attend. ... going to be there and he agreed to attend the BoF. Note, it is way past the time to request a BOF so I geuss the only option is something informal.

Re: [DNSOP] automatic update of DS records

On Wed, Mar 03, 2010 at 11:28:36AM +0100, Jaap Akkerhuis wrote: Antoin says: So there's one more logical entity involved; most likely this way: jaap ___ did i miss something? Antoin

Re: [DNSOP] m.root-servers.net DNSSEC TCP failures

m.root-servers.net is now serving DNSSEC, but does not have TCP, so the following queries all fail They works for me but not behind the linksys router of the meeting I'm currently in. jaap ___ DNSOP mailing list

Re: [DNSOP] Updated DNS Redirect Draft

Didn't I also a 00 draft about DNS Redirect and malware protection passing by? jaap ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on Negative Trust Anchors

... More pragmatically, while I understand the theory behind rejecting NTAs, I have to admit it feels a bit like the IETF rejecting NATs and/or DNS redirection. I would be surprised if folks who implement NTAs will stop using them if they are not accepted by

Re: [DNSOP] on Negative Trust Anchors

On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote: More pragmatically, while I understand the theory behind rejecting NTAs, I have to admit it feels a bit like the IETF rejecting NATs and/or DNS redirection. I would be surprised if folks who implement NTAs will stop using

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

When a DNS operator first signs their zone, they need to communicate their keying material to their parent through some out-of-band method to complete And changing opening sentence to: The first time a DNS operator signs the zone, they need to communicate the keying

Re: [DNSOP] RFC 6761 discussion (“special names”)

Tim Wicinski writes: The WG has several documents that we need to spend time in Dallas moving towards completion. But we also believe the RFC 6761 drafts should not be given short shrift. Accordingly, we are tentatively planning a Virtual Interim Meeting to dive a little deeper

Re: [DNSOP] Interim Meeting on Special Names and RFC 6761

Jaap Akkerhuis writes: Oops, wrong message went out. Tim Wicinski writes: This is a multi-part message in MIME format. --010907040103080303070203 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit All

Re: [DNSOP] Interim Meeting on Special Names and RFC 6761

Tim Wicinski writes: Jaap Akkerhuis was the Arranger of the room. Too much honour. I was indeed arranging a room (for somthing else) and then Kaveh Ranjbar suggested to arrange a room for dnsop as well. I Initially thought a polycom type thing could cause a muddle of voices. But I'm

Re: [DNSOP] EU ISO-3166 code (was Re: I-D Action: draft-ietf-dnsop-dns-terminology-01.txt)

Patrik Fältström writes: But instead ICANN have, and still am, referring to EU be on the reserved list (and now exceptionally reserved) as a reason to allocate as a ccTLD. If one read the board resolution approving EU as a (cc-)TLD, one will notice that this is really an exception [1]

Re: [DNSOP] EU ISO-3166 code (was Re: I-D Action: draft-ietf-dnsop-dns-terminology-01.txt)

Andrew Sullivan writes: I still think that defining TLD is useful, and I suspect in that definition we'd want to add the sentence, TLDs are often divided into ccTLDs and gTLDs; the division is a matter of policy in the root zone, and beyond the scope of this document. Or something like

Re: [DNSOP] Top level names -- precision re categories and where are are the uncertainties?

Steve Crocker writes: Folks, I`ve been watching the dialog on this list regarding to level names. Attached is my attempt to clarify the state of affairs and identify the loose ends. Both PDF and pptx versions attached, the latter in case someone is moved to edit the slides

Re: [DNSOP] Thoughts on the top level name space

Steve Crocker writes: For the alpha 3-code the complete user assigned set is: AAA-AAZ, QMA-QZZ, XAA-XZZZ and ZZA to ZZZ so one could argue that the delegations for TLD xyz (and maybe xxx) is a actually against the rules in ICANN�s Application Guide Book. It's my

Re: [DNSOP] Thoughts on the top level name space

Steve Crocker writes: xq 'pq' is a better example. 'xq' is classified as User Assigned, which means it has been assigned for use by anyone for their own purposes. 'pq' is (using Wikipedia�s term) unassigned. Thanks. I didn't check the tables before writing. I was

Re: [DNSOP] Thoughts on the top level name space

Not taking a stand on this, but some more remarks on these thoughts. Edward Lewis writes: On 7/5/15, 7:26, DNSOP on behalf of Steve Crocker dnsop-boun...@ietf.org on behalf of st...@shinkuro.com wrote: 3. (ICANN) Two letter Latin characters that have not yet been assigned by the

Re: [DNSOP] Thoughts on the top level name space

David Conrad writes: In the past, ISO-3166/MA maintained a color-coded decoding table that clearly identified the user assigned 2-letter ISO codes. However, for reasons that I'm sure made sense to someone, they stopped publishing the decoding table

Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)

Warren Kumari writes: This number comes from Evan :-) Less flippantly, it is in this email: https://www.ietf.org/mail-archive/web/dnsop/current/msg13004.html I don't think that we have a really good motivation for a week, other than that is feels sort of like a good, human

Re: [DNSOP] Looking for IANA registry for --xn

Robert Edmonds writes: > Donald Eastlake wrote: > > Sure, you can consider the root zone to be the registry for TLDs but the > > point is the xn-- labels are recommended to be interpreted specially at the > > user interface at all levels... > > Nor would this say anything about "CCHH"

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

David Conrad writes: > > I'd really like to say yes, but ISO-3166/MA appears to have removed > references > to "User Assigned" in their official ISO-3166 two letter code w= > webpage. Only the the standard is normative. > I'm trying to understand if they've changed their mind, but no

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

Stephane Bortzmeyer writes: > > As you can imagine, I disagree. > > > Domain names are written left to right. > > In english, yes, not in general. They are always written from the > beginning to the end (obviously) and the final label can be at the > left in a RTL script. There is no

Re: [DNSOP] DNSSEC operational issues long term

Mikael Abrahamsson writes: > So if it's manufactured the day before a new key is publically released, > when is the key material it has built in no longer viable to have > successful DNSSEC validation? A properly designed device will discover that its preconfgured trust anchor differs from

Re: [DNSOP] DNSSEC operational issues long term

Philip Homburg writes: > >Did you see my original response? Proposals for automatic DNSSEC trust > >anchor updating *do* exist. > > Is there any document that deals with the situation where a device has > been in a box for 10 years and then has to bootstrap automatically? > > I'm not

Re: [DNSOP] Fwd: [homenet] WGLC on "redact" and "homenet-dot"

Ray Bellis writes: > On 14/12/2016 20:14, Jaap Akkerhuis wrote: > > Any reason why homenet shuld use a TLD? What is wrong with something > > like homenet.arpa (or thuisnet.arpa, or bob.arpa). > > Which hat? > > It's not considered user-friendly enough.

Re: [DNSOP] Fwd: [homenet] WGLC on "redact" and "homenet-dot"

Ted Lemon writes: > I hope it was obvious that I was pretty confident that you actually had a > reason. :) > > The issue what what you are saying is that sometimes it is technically > correct for a name to not be validatable. The reason we want an unsecured > delegation for .homenet

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

Stephane Bortzmeyer writes: > What did we publish on classes? If you refer to > draft-sullivan-dns-class-useless, it was never published (which is > bad). As part of the IDNA discussion there is an RFC (or parts of it) pointing out how uesless classes are. I seem to remember it was from the

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

Stephane Bortzmeyer writes: > On Wed, Dec 21, 2016 at 10:05:03PM +0100, Jaap Akkerhuis > <j...@nlnetlabs.nl> wrote a message of 16 lines which said: > > > As part of the IDNA discussion there is an RFC (or parts of it) > > pointing out how uesless class

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Jim Reid writes: > > > > On 21 Mar 2017, at 14:09, Paul Wouters wrote: > > > > Can we tell from the queries or a timeline of query quantity if this > > is generic .home pollution that predates the homenet protocol suite, > > or actually the result the homenet protocol

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Petr Špaček writes: > > > An example: RFC 4033 clearly states what should be done if result of > validation is "Bogus". Nonetheless, Unbound has "val-permissive-mode: > yes" which enables admin to pass bogus answers. > Note that the default setting is "val-permissive-mode: no". It is

Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

Warren Kumari writes: > "Throughout this document, we are using A to refer to an Address > record (either 'A' or '') " -- having "A or " scattered all > over the document makes it now flow as nicely... Just for fun, turn that around: "Throughout this document, we are using ...

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

Warren Kumari writes: > > i *seem* to remember something happening with .de a few years back -- > IIRC, slaves did a zone transfer, ran out of disk and truncated the > file, and so only had a partial zone file to serve - something like > 2/3ds of the .de zone "disappeared". A zone checksum

Re: [DNSOP] RFC7720 and AXFR

Mukund Sivaraman writes: > There's no requirement for AXFR and some root letters don't serve > AXFR. E.g., L and M don't whereas F does. > For AXFR from L, see jaap ___ DNSOP mailing list

Re: [DNSOP] On .ZZ

Paul Wouters writes: > > > > > On Nov 21, 2019, at 15:18, Alexander Mayrhofer > > wrote: > > > > > > ..ZZ would remind me of long beards and loud motorcycles for the rest > > of my life.. https://de.wikipedia.org/wiki/ZZ_Top > > English speaking people can’t even agree on how to

Re: [DNSOP] on private use TLDS

Doug Barton writes: > I don't doubt Jaap. Thank you. > What I doubt is that any organization as political > as ISO (or ICANN) will hold preferences stable in the absence of a > controlling policy. Here are some more facts from the trivia corner. The ISO was started from 1947. The first

Re: [DNSOP] On .ZZ

Shane Kerr writes: > Hm... this is an interesting point. > > I just checked the ISO 3166 glossary: > https://www.iso.org/glossary-for-iso-3166.html > > And it says: > > "User-assigned codes - If users need code elements to represent country > names not included in ISO 3166-1, the

Re: [DNSOP] On .ZZ

Bill Woodcock writes: > Again, this is an argument from principle rather than an argument based > on the specific case at hand. I just think that we have a > well-established precedent that all two-letter TLDs are derived from ISO > 3166 Alpha-2, and it's bad form to cross back over and

Re: [DNSOP] On .ZZ

Erwin Lansing writes: > > Beware of assumptions. I would never have imagined in my wildest > dreams for St. Maarten to be assigned SX. It was on request of Dutch Sint Maarten. The argued that they where know for the airport code for the well-known Princess Juliana International Airport But

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

Tim Wicinski writes: > > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. Reviwed and yes, this is suitable. It addresses operational problems. > > Please also indicate if you are willing to

Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

Let me make some pedantic remarks about the terms used in this discussion. Joe Abley writes: > 1. Certain ISO-3166-2 codepoints are designated as being for private > use by ISO and will not be assigned for use by countries, economies, etc; What you mean here is the ISO 3166 Part 1 (ISO

Re: [DNSOP] NOTIFY: How to locate the target

Michael Bauland writes: > Therefore you need to know what endpoint of the registry you need to > send the NOTIFY to. This would just be a service listening for NOTIFYs > to re-initiate the scanning, but it's not a name server at all. Setting > this endpoint in the TLD zone's SOA record as