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

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 3166

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 contri

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

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 t

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 sta

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 series

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 p

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 DNSOP@ie

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 w

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 ... e

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 just

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 suite being deplo

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

Stephane Bortzmeyer writes: > On Wed, Dec 21, 2016 at 10:05:03PM +0100, Jaap Akkerhuis > 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 classes are. I seem to remember it

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] 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 is

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 awa

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] 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" pref

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] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

"John R Levine" writes: > They're not assigned, they're not unassigned, they're not reserved, > they're not formerly assigned, they're not anything. > > For about $40 one can buy a copy of ISO 3166-1:2013. It's not clear from > the TOC if it's any more informative. The rules are in Sect

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 an

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 (http://www.iso.org/iso/iso-

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,

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.

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. > >

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" > wrote: > > >3. (ICANN) Two letter Latin characters that have not yet been assigned by > >the ISO 3166 maintenance agency but might be in th

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 dir

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 somethin

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 exceptio

Re: [DNSOP] Terminology: country

Tony Finch writes: > They are country-code TLDs because they use the country codes from ISO > 3166. "Country codes" is the title of part 1 of ISO 3166. > http://www.iso.org/iso/country_codes.htm > > There are also the IDN ccTLDs which do not use country codes but which > are allocated base

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 >

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

Paul Hoffman writes: > "Country" is a term of art in politics. There are definitions that most > people agree to, at least when it suits them. RFC 1591 purposely does not define what a country is. ISO 3166-1 contains a definition what constitutes a country. jaap ___

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

Ted Lemon writes: > On Mar 18, 2015, at 7:01 AM, Jaap Akkerhuis wrote: > > Following this discussion from a distance, I cannot help wondering > > whether this is special names stuff might in violate RFC 2860 section 4.3. > > I don't see it. It looks like 2860 e

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 dee

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 keyin

Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt

I'm still trying to figure out how I could tell whether prefetch makes things better or worse, since the main thing I've learned from the few DNS cache simulations I've done is that intuition is not a good guide. The net effect it will have is that the average latency querying fo

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 implem

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 b

Re: [DNSOP] draft-liman-tld-names-04

How can you define upper case of 'y' with diaeresis' in Dutch context where (lowercase y with diaeresis), ij and Y, IJ are identical. Your mileage varies. They are sometimes condidered identical, sometimes they aren't. The Dutch alphabet has a variable number of characters

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] 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 DNSOP@ietf.org

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 > ___

Re: [DNSOP] automatic update of DS records

Antoin says: So there's one more logical entity involved; most likely this way: vvv v dns_op(parent)-registry-registrar-reseller-registrant-dns_op(child) The dns_op(child) might alternatively have a direc

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 inform

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 addres

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 go

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 DNSOP@ietf

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

[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 replac

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] draft-ietf-dnsop-name-server-management-reqs-01.txt

At the IETF WG meeting I said I had some comments to this draft. It turns out that these were very minor an only editorial and can just as easy handled later. I've send them to the editor (Wes) anyway. So I do think that this draft is ready to go. jaap _

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] 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))

> Given this, does anyone see any DNS security and/or stability concerns > if a miracle were to happen and the root were to be signed tomorrow? Well,it will introduce a lot of large RRs, which may cause problems. No, it won't. As David already pointed out, people not intere

Re: [DNSOP] AS112 for TLDs

> > We investigated that situation on request and found some F-root > instances were receiving very high volume of queries for invalid TLD. I'm wondering why those ip's aren't distributing their queries across all the roots. Not all resolvers are equal. Some lock on on se

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

[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] DNS resolver loop for a ccTLD .bg

Hi David, Given the interest in deploying DNSSEC more generally, it would be really interesting to determine if this were the case. I think Paul means that DNSSEC is the reason that auth01.ns.uu.net is lame. That guy runs an old bind 8.3 or so and the other and is not in the nameserver