Re: [dns-operations] [dns-privacy] OARC 43 - Call for Contribution

[Rubens Kuhl via dns-operations]

--- Begin Message ---

A distinct possibility is that it will happen in Santa Marta, Colombia, and 
will be colocated with LAC DNS Week and ICANN DNS Symposium. 

Previous editions websites:
https://dnsweek.lat/en
https://www.icann.org/ids


Rubens




> Em 17 de abr. de 2024, à(s) 12:00, Petr Špaček  escreveu:
> 
> The Programme Committee is seeking contributions from the community.
> 
> This workshop will be a hybrid event.
> 
> Date - likely in the week of 23-27 September 2024, details will be confirmed 
> later
> 
> Location - South America, exact location will be confirmed later
> 
> Time zone - approximately 09:00-17:00 UTC-5
> 
> Co-located with - related industry events, will be confirmed later
> 
> Deadline for Submissions - 2024-06-23 23:59 UTC
> 
> For further details please see
> https://indico.dns-oarc.net/event/51/abstracts/
> 
> Petr Špaček, for the DNS-OARC Programme Committee
> 
> ___
> dns-privacy mailing list
> dns-priv...@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy



signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Upcoming Registry Service Provider Evaluation Program

[Rubens Kuhl via dns-operations]

--- Begin Message ---


> Em 22 de fev. de 2024, à(s) 14:25, Gaurav Kansal  
> escreveu:
> 
> Hi Rubens,
> 
> Is it mandatory for the ccTLD to get its RSP evaluated ? Or they have the 
> freedom to choose the RSP without evacuation purpose.
> 
> Please ignore my lack of knowledge here.

ccTLDs can use whichever RSP they see fit, without interference from ICANN. 
That said, most ccTLDs either run their own infrastructure or contract with an 
RSP that likely also provides services for gTLDs, so movements in the gTLDs RSP 
market have impact on ccTLDs. 


Rubens



signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Upcoming Registry Service Provider Evaluation Program

[Rubens Kuhl via dns-operations]

--- Begin Message ---

> 
> I did some of the technical evaluations in the previous round, and we
> saw that the vast majority of applications used about five back end
> providers. Prequalifying those providers would have made the whole
> process much faster.
> 
> R's,
> John

https://ntldstats.com/backend
new gTLD Statistics by Backends
ntldstats.com
 lists 37 back-ends for gTLDs. I don’t think there is a readily available list 
for ccTLDs. 


Rubens




signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Upcoming Registry Service Provider Evaluation Program

[Rubens Kuhl via dns-operations]

--- Begin Message ---

> 
> I did some of the technical evaluations in the previous round, and we
> saw that the vast majority of applications used about five back end
> providers. Prequalifying those providers would have made the whole
> process much faster.
> 
> R's,
> John

https://ntldstats.com/backend
new gTLD Statistics by Backends
ntldstats.com
 lists 37 back-ends for gTLDs. I don’t think there is a readily available list 
for c


Rubens




signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Upcoming Registry Service Provider Evaluation Program

[Rubens Kuhl via dns-operations]

--- Begin Message ---

Gaurav,

If an applicant so prefers it can have its own RSP evaluated at the same time 
its application is evaluated, so it’s not restricted to the list of 
pre-approved RSPs.  



Rubens



> Em 22 de fev. de 2024, à(s) 00:57, Gaurav Kansal via dns-operations 
>  escreveu:
> 
> 
> De: Gaurav Kansal 
> Assunto: Re: [dns-operations] Upcoming Registry Service Provider Evaluation 
> Program
> Data: 22 de fevereiro de 2024 às 00:57:47 BRT
> Para: andy.new...@icann.org
> Cc: dns-operations@lists.dns-oarc.net
> 
> 
> Hi, 
> Whether only selected RSPs will be allowed to run gTLD operations, or winning 
> bidder will have a freedom to choice the TLD operator outside of this list 
> also ?
> 
> Please forgive my ignorance if any on this topic.
> 
> Regards 
> Gaurav Kansal
> 
>> On 22-Feb-2024, at 03:51, andy.new...@icann.org wrote:
>> ICANN will soon be launching its next round of gTLD applications. As part 
>> of the program to launch new gTLDs, ICANN will be evaluating and publishing 
>> a list of Registry Service Providers (RSPs). These organizations fulfill the 
>> critical, technical services necessary to implement and operate a gTLD. RSPs 
>> evaluated through ICANN’s program will be eligible to offer these services 
>> to one or more gTLDs.
>> 
>> The RSP Evaluation program will support evaluating DNS and DNSSEC RSPs 
>> (typically known as DNS providers) allowing gTLDs to select them.
>> 
>> All organizations are eligible to become an RSP, regardless of past 
>> experience with gTLD services. ICANN plans to publish RSP application 
>> materials for public comments early March, and final versions in May. The 
>> RSP application process is expected to begin in the last quarter of 2024.
>> 
>> If you are interested in becoming an RSP (for DNS, DNSSEC, or any other 
>> critical registry function), please consider participating in the 
>> conversations taking place within the ICANN process.
>> 
>> The details of the RSP evaluation program are currently under discussion 
>> within the Subsequent Procedures Implementation Review Team (IRT) 
>> (https://community.icann.org/x/pQM5Dg). To participate in the IRT, complete 
>> his form: https://forms.gle/GF1VoywZ2FGKbzNQA. Additionally, ICANN plans to 
>> publish the RSP application materials for public comment 
>> (https://www.icann.org/en/public-comment) in March 2024.
>> 
>> 
>> -- 
>> Andy Newton
>> Principal Engineer
>> GDS Technical Services, ICANN
>> 
>> ___
>> dns-operations mailing list
>> dns-operations@lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> 
> 
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNS Operations

[Rubens Kuhl via dns-operations]

--- Begin Message ---

What’s your popularity metric ? 
Installations ? 
Number of queries served ? 
Number of zones served ? 
Number of OS distributions that include it in the base system ? 


Rubens


> Em 15 de fev. de 2024, à(s) 12:33, Turritopsis Dohrnii Teo En Ming via 
> dns-operations  escreveu:
> 
> 
> De: Turritopsis Dohrnii Teo En Ming 
> Assunto: DNS Operations
> Data: 15 de fevereiro de 2024 às 12:33:25 BRT
> Para: "dns-operations@lists.dns-oarc.net" 
> Cc: "c...@teo-en-ming-corp.com" 
> 
> 
> Subject: DNS Operations
> 
> Good day from Singapore,
> 
> Could you please provide information on the current dominance and market 
> share of ISC BIND DNS server? Is it widely recognized as the most popular DNS 
> server globally?
> 
> Thank you.
> 
> Regards,
> 
> Mr. Turritopsis Dohrnii Teo En Ming
> Targeted Individual in Singapore
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Why is DNS still hard to learn?

[Rubens Kuhl via dns-operations]

--- Begin Message ---
Wireshark is a good DNS teacher unless DoT/DoH is in play.

Resillience of the DNS system is why most people know little about it. People 
just take it for granted.

Rubens

⁣

Em 29 de jul. de 2023 09:20, em 09:20, Stephane Bortzmeyer  
escreveu:
>As usual, a good practical article by Julia Evans:
>
>https://jvns.ca/blog/2023/07/28/why-is-dns-still-hard-to-learn/
>___
>dns-operations mailing list
>dns-operations@lists.dns-oarc.net
>https://lists.dns-oarc.net/mailman/listinfo/dns-operations
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] DNSSEC transition

[Rubens Kuhl via dns-operations]

--- Begin Message ---

HI there. 

I am considering a DNSSEC transition in the following scenario:

- Org 1 operates both the parent domain, with a delegation-only server, and the 
child domain, with a set of authoritative servers. A zone cut is present. 
- Org 2 operates only authoritative servers 
- Child domain is currently signed by Org 1, with a DS record matching DNSKEY 
and RRSIGs served by the authoritative servers.
- Child domain is moving from the authoritative servers of Org 1 to the 
authoritative servers of Org 2. Org 1 will keep running the parent domain. 
- Org 2 will now run the child domain, with no DNSSEC

Simple way is to remove the DS from the parent, wait for the DS TTL to be over, 
and then change the delegation at the parent domain. But this makes the change 
to wait for that DS TTL. 

I wonder if there is a way to make this transition to happen faster from an 
outside POV, even if under the hood there is still work in progress during the 
DS TTL. Is there a way to tell "hey, 
DNSSEC is longer available to this domain, and I can prove that with RRSIG 
record" that resolvers would trust ? Because other than that, the next option 
would be to act as a recursor querying the new name servers, and on the fly 
signing the responses. 




Rubens





--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] .mx issues

[Rubens Kuhl via dns-operations]

--- Begin Message ---

Is anyone seeing issues resolving .mx domains ? Not working from here and 
DNSViz seems to have issues with some of the authoritatives but not all of them:
https://dnsviz.net/d/citas.sre.gob.mx/dnssec/


• mx zone: The server(s) were not responsive to queries over TCP. 
(192.100.224.1)
• mx zone: The server(s) were not responsive to queries over UDP. 
(200.23.1.1, 200.94.176.1)
• sre.gob.mx zone: The server(s) were not responsive to queries over TCP. 
(200.33.163.51)
• sre.gob.mx zone: The server(s) were not responsive to queries over UDP. 
(200.33.160.51)



Rubens



signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Browser Public suffixes list

[Rubens Kuhl via dns-operations]

--- Begin Message ---

The list of malicious websites in browsers is constantly updated without having 
to follow the release cycle... where there's a will, there's a way.


Rubens


> On 27 Aug 2022, at 22:43, Jothan Frakes  wrote:
> 
> I am really frustrated that the materials developed for IANA to share to 
> avoid things like this were not distributed, as awareness would have led to 
> earlier request, which in turn would have diminished the propagation timing 
> gap with the browser side.
> 
> Not saying all the planets would have lined up, but the odds would have 
> improved.
> 
> "Browsers gonna browse" - love that Vixie quote.
> 
> The performance of the combined 'omnibox' that mashed up search and location 
> was also a driver, although screen real estate on mobile/tablet certainly 
> made this a practical argument for omnibox vs them sweet, sweet search dollas
> 
> Anyways, as far as the propagation timing goes, PSL is just a drop in 
> component that is *relatively* static, and we're quite mindful of keeping the 
> file size modest for a number of reasons.  I am glad that the team at ISOC.IL 
>  were able to find waldo within Mozilla and Google.  I think 
> with Safari it is important to note that updates to it are typically done at 
> the time of their OS upgrades as a 'whole cloth' update, and it seems Apple 
> likes to make modest update frequency, so Safari internals are one of the 
> train cars attached to the OS Train but not the train itself, and this is 
> just an efficiency thing.
> 
> The performance benefit is the best argument I have been presented as to why 
> there is a static list baked in on the browser.
> 
> Generally speaking, the PSL being used as a static list incorporated into 
> software kind of perpetuates the hosts.txt dilemma that DNS started to 
> distribute better, and the DBOUND began a good direction but we ended up with 
> a low 'juice to squeeze' ratio and could not quite work out what flavor 
> either.
> 
> There is some activity inside of the W3C WhatWG kind of as a parallel 
> evolution to DBOUND (bridge being built from other side of canyon).
> 
> Crucially, there are a number of ways in addition to administrative 
> boundaries that overlap, and there are other projects like DKIM DMARC HSTS 
> etc that have a lot of overlap in ways a common project might be helpful in 
> allowing an administrator of a namespace for a domain name in having some 
> means to express to the internet how they would prefer their domain name be 
> interacted with.
> 
> -Jothan
> 
> 
> On Sat, Aug 27, 2022 at 11:26 AM Paul Vixie via dns-operations 
> mailto:dns-operati...@dns-oarc.net>> wrote:
> 
> 
> 
> -- Forwarded message --
> From: Paul Vixie mailto:p...@redbarn.org>>
> To: DNS Operations List  >
> Cc:
> Bcc:
> Date: Sat, 27 Aug 2022 11:20:53 -0700
> Subject: Re: [dns-operations] Browser Public suffixes list
> 
> 
> Viktor Dukhovni wrote on 2022-08-27 11:06:
> > On Sat, Aug 27, 2022 at 10:48:46AM -0700, Paul Vixie wrote:
> >>  ...
> >> see: https://www.ietf.org/mailman/listinfo/dbound 
> >> 
> >
> > Another aspect of the problem, is that the browsers unified the address
> > bar and the search bar in order to "improve" (make simpler than
> > possible) the browser user interface.  This creates a fundamental
> > ambiguity about user intent.  Did the user type a URL sans scheme prefix
> > or a search term?  Using the PSL to "disambiguate" is a hack.
> 
> browsers gonna browse. there's nothing we can do about that in the
> protocols. time was, any character-by-character current value in the
> browser bar which was syntactically valid as a domain name (by regex
> without reference to a PSL or any other dictionary) would be sent to the
> DNS resolver. apparently this wasn't monetizing enough. we march on.
> 
> --
> P Vixie
> 
> 
> 
> 
> -- Forwarded message --
> From: Paul Vixie via dns-operations  >
> To: DNS Operations List  >
> Cc:
> Bcc:
> Date: Sat, 27 Aug 2022 11:20:53 -0700
> Subject: Re: [dns-operations] Browser Public suffixes list
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net 
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations 
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net 
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations 
> 


signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
dns-operations mailing list

Re: [dns-operations] Browser Public suffixes list

[Rubens Kuhl via dns-operations]

--- Begin Message ---
> 
> So bottom line, browser behavior is not based on DNS resolving, nor by any 
> IANA list, but rather on the PSL.
> As I wrote earlier we have already merged the diff into the list.
> The next update of firefox and hopefully chromium based browsers (sept 26), 
> should contain the updated list.
> The only browser we could not find any documentation on this matter is 
> Apple's safari.
> p.s It has nothing to do with right to left scripts.

In my experience launching gTLDs, it takes a few months for Safari to reflect 
published PSL. It seems they add that at the beginning of a release cycle, 
instead of the tail-end like Firefox and Chrome.
If you have any Apple device with AppleCare contract, you can use that to open 
a support case for that platform (Mobile Safari and Desktop Safari have 
different release cycles). That won't speed things up, but can provide you 
emotional comfort.



Rubens



signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] DNS resolution issue for Google services

[Rubens Kuhl]

At Vivo in Brazil, AS 27699 for the broadband service using AS 10429 resolvers, 
recursive DNS (powered by Akamai / Nominum) can't resolve some Google services:

$ dig +noall +question +answer lh3.googleusercontent.com @200.204.0.10 #
Vivo recursive DNS
;lh3.googleusercontent.com. IN A

$ dig +noall +question +answer lh3.googleusercontent.com @200.204.0.138 #
Vivo recursive DNS
;lh3.googleusercontent.com. IN A

$ dig +noall +question +answer lh3.googleusercontent.com
@2001:12e0:0:1025:a080::2 # DNS recursivo da Vivo
;lh3.googleusercontent.com. IN A

$ dig +noall +question +answer lh3.googleusercontent.com
@2001:12e0:0:1025:a080::3 # DNS recursivo da Vivo
;lh3.googleusercontent.com. IN A

$ dig +noall +question +answer lh3.googleusercontent.com @8.8.8.8 # Google
Public DNS
;lh3.googleusercontent.com. IN A
lh3.googleusercontent.com. 21449 IN CNAME
googlehosted.l.googleusercontent.com.
googlehosted.l.googleusercontent.com. 149 IN A 172.217.172.129

$ dig +noall +question +answer lh3.googleusercontent.com @1.1.1.1 #
Cloudflare
;lh3.googleusercontent.com. IN A
lh3.googleusercontent.com. 9983 IN CNAME
googlehosted.l.googleusercontent.com.
googlehosted.l.googleusercontent.com. 67 IN A 172.217.29.161

$ dig +noall +question +answer lh3.googleusercontent.com @208.67.222.222 #
OpenDNS
;lh3.googleusercontent.com. IN A
lh3.googleusercontent.com. 79231 IN CNAME
googlehosted.l.googleusercontent.com.
googlehosted.l.googleusercontent.com. 300 IN A 216.58.202.129

Tests from RIPE Atlas in Brazill (links [1]
and [2]) show more AS27699 (TELEFÔNICA BRASIL S.A.) users getting
NXDOMAIN for lh3.googleusercontent.com.

If someone from Akamai could relay the message, it would be appreciated.


(Original Portuguese message at 
https://eng.registro.br/pipermail/caiu/2020-March/065373.html)

[1]
https://atlas.ripe.net/measurements/24326914/

[2]
https://atlas.ripe.net/measurements/24326917/



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Rubens Kuhl]

Not exactly what you asked, but a registrar example: Openprovider requires 
registrant to provide the DNSKEY, not DS, to activate and manage DNSSEC.


Rubens

> On 22 Jan 2020, at 19:13, Tony Finch  wrote:
> 
> Are there any registries that configure secure delegations from DNSKEY
> records (and do their own conversion to DS records) rather than accepting
> DS records from the registrant? I think I have heard that .de is one.
> Looking at OpenSRS as an example of a registrar that supports lots of
> TLDs, I see that they don't support DNSSEC for .de
> http://opensrs.help/chart and their API only supports DS records
> https://domains.opensrs.guide/docs/set_dnssec_info
> 
> Also, I am uncomfortable with the endianness of their support domain names...
> 
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> responsible stewardship of the earth and its resources
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Rubens Kuhl]

> Em 11 de dez de 2019, à(s) 10:20:000, Jim Reid  escreveu:
> 
> 
> 
>> On 11 Dec 2019, at 12:51, Stephane Bortzmeyer  wrote:
>> 
>> IMHO, this is by far the biggest issue with your proposal: TLDs change
>> from one technical operator to another and, when it happens, all name
>> servers change at once.
> 
> That’s not correct.
> 
> In principle, they could all change at once, In reality, they don’t. When 
> making a change of this nature, established wisdom is to change half of the 
> NS records (or their glue), wait a few days to see that all is well and then 
> change the other half. I think IANA would try to persuade a TLD to do that if 
> they came with a proposal to change all of the TLD's NS records in one 
> transaction. Though if the TLD insisted, IANA would respect their choice.
> 
> Come to think of it, changing all of the NS records at once is generally a 
> bad idea for any zone. That would probably only make sense when all of the 
> existing name servers were dead or no longer serving the zone.
> 


Jim,

That's not of what RSPs (Registry Service Providers), ICANN GDD and ICANN IANA 
have been doing in RSP transitions. What has been working best is to double DS 
the zone with losing KSK and gaining KSK, have both RSPs sign each other ZSKs 
and NSs, and replace all DNS servers at gaining RSP, then losing RSP, then IANA.

One of such transitions in 2019 was .natura and the root zone history can show 
how it was done. I am polishing out a few tidbits in that change process and 
will publish the change process of that case as a template that serves well 
single-registrant TLD transitions.

Rubens




signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Rubens Kuhl]

> On 30 Nov 2019, at 14:31, Keith Mitchell  wrote:
> 
> On 11/29/19 8:32 PM, Rubens Kuhl wrote:
> 
>> including making studies that other parties can't reproduce due to
>> being limited to DITL data.
> 
> DITL data is available to any party who signs an OARC Data Sharing
> agreement.


Keith,

DITL data is the gold standard for such analysis. What I mentioned is that the 
RZM publishes studies that can't be reproduced due to use of other data(not 
DITL) only accessible to the RZM, and also try implying that DITL data doesn't 
capture reality due to being short lived, which is kinda like "I know better 
but I can't tell you why". 





Rubens





___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Rubens Kuhl]

>> 
>> The data could have monetary value.  Passwords that are otherwise
>> difficult to come by might be leaking.
> 
> Hi Florian,
> 
> I can assure you that Verisign does not monetize the root server data.  If
> any other operators do, I'm not aware of it.
> 
> We do utilize root server data for research purposes from time-to-time.
> Recent examples include the KSK rollover and name collisions.  Less recent
> examples include understanding TTL/caching behavior and preparing for the
> root ZSK size increase.  When DDoS attacks happen, we often analyze the
> data to see if we can understand how and why it happened, and to be better
> prepared for the next one.


Note that the two paragraphs above contradict each other. The current RZM is 
known to use root server data as anti-competitive measures against new TLD 
operators with the label of name collision studies, including making studies 
that other parties can't reproduce due to being limited to DITL data. 


Rubens


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Root and critical dns server caching

[Rubens Kuhl]

> On 9 Nov 2019, at 03:00, Mehmet Akcin  wrote:
> 
> Hey there
> 
> I am trying to improve the performance of tlds in various parts of the world 
> as part of a project.
> 
> Besides PCH, who else I can get a hold of these days to have local caches of 
> DNS? I am focusing on Brazil, Argentina, Peru, Colombia and Chile

Mehmet,

NIC.br  already runs .br instances in a dozen cities in Brazil, 
at the same it sponsors server equipment for ICANN to run L-Root in almost the 
same locations (remember your previous life ? ;-). 
Verisign (http://www.verisigninc.com/rirs ) 
also has a few locations in Brazil, and considering root zone, .br and VRSN 
TLDs, most DNS traffic of interest to Brazilians can be resolved locally. 



Rubens



___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

[Rubens Kuhl]

> On 12 Oct 2019, at 10:03, Keith Mitchell  wrote:
> 
> On 10/11/19 6:30 PM, Shumon Huque wrote:
> 
>> It might be much more important for diagnostic and measurement services
>> like DNSviz though. At the moment, if you run IPv6 DNS servers on
>> networks that are singly connected to Cogent, it will probably
>> incorrectly flag those servers as unavailable. For such services,
>> perhaps it would be better if they were not single-homed to either
>> Cogent or HE.
> 
>> (To be clear, I'm happy that DNSviz is housed at OARC. So, I guess I
>> might be suggesting that the community might consider how to fund a
>> second ISP connection for OARC).
> 
> Thank You :-) That would be most welcome if anyone is prepared to step
> up (and/or open to other potential solutions) ? FWIW, we are at HE's
> Fremont2 facility, and peer at SFMIX.


If someone from Cogent is reading, that's their opportunity to step up and 
provide at least a partial feed to OARC. 
Unless they want to do the better thing which is to end this peering war and 
stop messing IPv6 Internet... 



Rubens


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] 5s TTL on IANA /8s

[Rubens Kuhl]

% dig @a.in-addr-servers.arpa. 12.in-addr.arpa. ns
...
12.in-addr.arpa.5INNScmtu.mt.ns.els-gms.att.net.
12.in-addr.arpa.5INNSdbru.br.ns.els-gms.att.net.
12.in-addr.arpa.5INNScbru.br.ns.els-gms.att.net.
12.in-addr.arpa.5INNSdmtu.mt.ns.els-gms.att.net.

% dig @b.in-addr-servers.arpa. 1.in-addr.arpa. ns
1.in-addr.arpa.5INNSns1.apnic.net.
1.in-addr.arpa.5INNSns2.lacnic.net.
1.in-addr.arpa.5INNSns3.apnic.net.
1.in-addr.arpa.5INNSns4.apnic.net.
1.in-addr.arpa.5INNSsec1.authdns.ripe.net.
1.in-addr.arpa.5INNSapnic1.dnsnode.net.
1.in-addr.arpa.5INNStinnie.arin.net.

• 200.in-addr.arpa.   5   IN  NS  sec1.authdns.ripe.net.
• 200.in-addr.arpa.   5   IN  NS  ns-lacnic.nic.mx.
• 200.in-addr.arpa.   5   IN  NS  ns3.afrinic.net.
• 200.in-addr.arpa.   5   IN  NS  a.arpa.dns.br.
• 200.in-addr.arpa.   5   IN  NS  ns.lacnic.net.
• 200.in-addr.arpa.   5   IN  NS  sec3.apnic.net.
• 200.in-addr.arpa.   5   IN  NS  ns2.lacnic.net.
• 200.in-addr.arpa.   5   IN  NS  tinnie.arin.net.
• ;; Received 256 bytes from 2001:67c:e0::1#53(2001:67c:e0::1) in 225 ms
•  


I tried to think on operational reasons to keep TTLs so low for these resources 
but couldn't think of anything... any ideas ? 


Rubens


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] about anti-ddos DNS hostings

[Rubens Kuhl]

 Em 11/06/2015, à(s) 10:45:000, Kumar Ashutosh kumar.ashut...@microsoft.com 
 escreveu:
 
 @Kevin
 See if this interests you
 http://azure.microsoft.com/en-us/services/dns/


Services with per-query charges are not what the original poster is looking 
for. Azure, AWS and similar offerings can cause both technical and financial 
denial-of-service... at least if flat-rate based providers you only get kicked 
out and restart searching for another DNS provider. 




Rubens



___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] bug in Apache handling of real FQDNs

[Rubens Kuhl]

 
 Firefox (Linux, Mac) are broken. Safari is broken. Some versions of curl 
 work, 
 some don't.

Same behaviour in Chrome for Mac OS X. With the added bonus of HSTS moving 
access to HTTPS for a good number of domains. 


Rubens


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Best Resources for Deep Dive Understanding of DNS

[Rubens Kuhl]

 On Dec 31, 2014, at 11:05 AM, Alexander Neilson alexan...@neilson.net.nz 
 mailto:alexan...@neilson.net.nz wrote:
 
 I am a relatively new operator of DNS servers and have inherited a rather 
 messy existing system.
 
 In the past year I have been learning more about the operations of DNS 
 servers and some of the aspects that hadn’t been addresses before in our 
 system.
 
 Some of the changes implemented in the last year:
 * Recursive resolvers now verify DNSSEC

Are recursives also restricting queries to the IP address space they should 
serve ? The line below could be it or something else:


 * Improved ACL configuration to protect from attacks

 We operate several DNS servers, new ones are either Recursive or 
 Authoritative however we also have an older server deployment that does both 
 at once. We are working on splitting these roles apart by migrating the 
 Authoritative zones off to the new authoritative group.

Keep doing that. Running the same server for both, even if the software allows 
it, showed to be not a best practice over time. 

 
 What I am looking at is peoples advice as to where I can next study up to 
 understand the deeper aspects of DNS. Particularly looking at performance 
 tuning and resilient architecture however any good resources that provide a 
 good understanding of the deeper details of the operation of DNS.

Most DNS resiliency out there is achieved by stateless equal-cost multi-path 
distribution. Put the IP Address clients know in loopback interfaces, use a 
routing daemon to announce it to a router, it will automatically fail-over if a 
machine goes down. You can then further improve on it by each machine doing 
health check on its own service and killing the announcement. 
 
 * prioritisation of root servers (my analysis of my server queries shows a 
 high proportion of queries to a.root-servers.net http://a.root-servers.net/ 
 however I have identified that this is one of the lowest response performance 
 root server from where I am located), I would like to prefer the 6 root 
 servers with the best response time (I have found 6 with RTT of less than 5ms 
 and the rest show RTT ~180-200)
 
 * Design considerations / advantages of pre loading the root zone (obviously 
 I have root hints however what is the benefits of pre loading the root zone 
 statically or just rely on resolving via the hints)

AXFR the root zone and the draft mentioned. Note that root hints and the root 
zone are different content; root hints are the address of the root servers, 
while the root zone contains the delegation information for the TLD servers. 

 
 * Architecture advantages / disadvantages for building resilient systems 
 (i.e. are there advantages to building a system with a “hidden” master with 
 the public authoritative servers as slaves to this master,

Yes, hidden masters are good for your health. Besides using garden variety DNS 
software for hidden masters, there are hidden-master-only DNS software like
http://registro.br/dnsshim http://registro.br/dnsshim (recommended if you use 
BIND or NSD)
http://atomiadns.com/ http://atomiadns.com/ (recommended if you use Power DNS)

That can offload some management effort. 

 are DNS views recommended for resolving “internal” DNS results or is it just 
 at risk of a fat finger errors to provide internal addresses to management 
 teams)

DNS views are a good thing, just be sure that they are the child of actual 
existing SLDs. Using something.internal.company.com 
http://internal.company.com/ (where company.com http://company.com/ is 
registered to you) is a good thing; using something.internal is a bad thing. 

 We use Bind as our server at the moment however I prefer to have a deep 
 understanding of both the protocol and process defined in the RFC’s (and real 
 world practice / interpretation) plus how individual implementations handle 
 it.

For now keep the same software so you have less variables, but when you finish 
up splitting recursives and authoritatives and making other changes, consider 
other software options for your recursives like Unbound and Power DNS Recursor, 
and other options for your authoritatives like NSD, Power DNS, Yadifa, Knot. 


Rubens


 

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] hong kong workshop, day 2, live link

[Rubens Kuhl]

Paul,

Complementing what Edmon Chung mentioned that root-servers was already reserved 
in the last new gTLD round, here follows the complete list of reserved names:

AFRINIC
IANA-SERVERS
NRO
ALAC
ICANN
RFC-EDITOR
APNIC
IESG
RIPE
ARIN
IETF
ROOT-SERVERS
ASO
INTERNIC
RSSAC
CCNSO
INVALID
SSAC
EXAMPLE
IRTF
TEST
GAC
ISTF
GNSO
LACNIC
WHOIS
GTLD-SERVERS
LOCAL
WWW
IAB
LOCALHOST
IANA
NIC

So, it could be a good option for using instead of the delegated and at times 
poisoned root-servers.net ... 

BTW, are there archives of the workshop available ? 


Rubens



 Em 08/12/2014, à(s) 23:16:000, Paul Vixie p...@redbarn.org escreveu:
 
 stream:
 
 https://www.youtube.com/watch?v=cMKvI-Hk7Uw
 
 draft agenda:
 
 https://docs.google.com/spreadsheets/d/1ssXQE5gGoWC93oFHquY2oZL4pDOv1bPDVjPoGYGdeSs
 
 -- 
 Paul Vixie
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] An simple observation

[Rubens Kuhl]

 
 Registrars making it difficult to add  addresses.  Inertia.
 CDN's not supporting IPv6 nameservers.
 
 Yes. they need more incentive to update their system.
 
 Actually, I firstly pay attention to the dual-stack in DNS is the setting to 
 keep the independence of DNS transport and DNS records(RFC4472).  I think 
 this setting in a way provide a reason for Registrar/Registry/CDN not doing 
 so.

Newest ICANN gTLD registrar contract, RAA 2013, require IPv6 support from 
registrars. As their old contracts (RAA 2009) expire over the course of the 
next 3 years, they will have to. All new gTLD contracts required IPv6 glue and 
IPv6 delegation support from start, and most previous gTLDs (if not all) and 
ccTLDs have both IPv6 glue and delegation support at this time, whether 
required or not. 

Some CDNs (like Cloudflare) provide IPv6 by default, while some (cof... cof... 
something that ends with mai) require clients to upgrade. 



Rubens



___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?

[Rubens Kuhl]

 
 It was curious to see that a to-be-unnamed TLD registry, a newcomer to
 the scene many years after the holy wars that ended up defining the
 current RFCs, writing completely new code, mentioned that they found
 attributes to be a better option, but decided to go with host objects
 due to registrar support. This doesn't prove which way is better, but
 for me it indicates that the role in the value chain can play a part in
 which option is preferred.
 
 Nominet is another example along those lines: alongside the .uk namespace
 change they have switched to a more standard EPP implementation.
 
 http://registrars.nominet.org.uk/namespace/uk/registration-and-domain-management/registrar-systems/epp
 http://registrars.nominet.org.uk/content/what-are-differences-between-nominet-epp-and-standard-epp


Commonplace is different from standard. Both are standards, and I disagree with 
their naming of it. 


Rubens


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD

[Rubens Kuhl]

Em 11/09/2014, à(s) 22:58:000, Joshua Smith juice...@gmail.com escreveu:

 Probably something I should know. But what's the best way to get notified of 
 new TLDs coming online to help arm the NOC?



Two ways: signing up to https://mm.icann.org/mailman/listinfo/gtldnotification 
where you know a contract has been signed (which predates root delegation by 
some weeks) or monitoring https://newgtlds.icann.org/newgtlds.csv for the same 
information. CSV will also indicate delegation, but that is not as real time as 
IANA information. 


Rubens




___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?

[Rubens Kuhl]

 From the point of view of data management, I think it is an unalloyed
 good.  I always thought the nameserver-as-attribute approach was
 dramatically worse.  Particularly for internal host objects, the
 enforced consistency of the glue for every domain that's using it is a
 giant help.


It was curious to see that a to-be-unnamed TLD registry, a newcomer to the 
scene many years after the holy wars that ended up defining the current RFCs, 
writing completely new code, mentioned that they found attributes to be a 
better option, but decided to go with host objects due to registrar support. 
This doesn't prove which way is better, but for me it indicates that the role 
in the value chain can play a part in which option is preferred. 


Rubens


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Validating or not validating (ICANN controlled interruption)

[Rubens Kuhl]

What I can tell you is that registries and applicants suggested ICANN to not 
require DNSSEC-signign of wildcard controlled interruption due to likely 
differences in resolver behaviour, including some known bugs. 

Rubens

On Sep 3, 2014, at 4:00 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote:

 BIND validates A nimportequoi.otsuka and yields an answer with AD bit
 set.
 
 Unbound gives back the answer but without the AD bit.
 
 [Try it yourself, 'dig @unbound.odvr.dns-oarc.net A
 nimportequoi.otsuka' and 'dig @bind.odvr.dns-oarc.net A nimportequoi.otsuka']
 
 In some cases (difficult to pinpoint, depending on the resolver's
 state), both BIND and Unbound return SERVFAIL.
 
 Who's right?
 
 PS: dnsviz claims that names like eb2dz5xm4s.otsuka are secure,
 non-existent while they elicit an answer.


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] First new gTLD using ICANN's Name Collision Occurrence Management Framework

[Rubens Kuhl]

Em 29/08/2014, à(s) 12:40:000, David Conrad d...@virtualized.org escreveu:

 Hi,
 
 On Aug 28, 2014, at 11:59 PM, Patrik Fältström p...@frobbit.se wrote:
 On 29 aug 2014, at 07:04, SM s...@resistor.net wrote:
 At 14:13 28-08-2014, Rod Rasmussen wrote:
 I note that these documents speak to many of the issues being exposed here 
 (and yes, full disclosure, I wrote a small portion of the text/reviewed 
 them):
 
 Was there a response to those issues?
 
 For details of ICANN’s efforts related to name collisions, please see 
 https://www.icann.org/resources/pages/name-collision-2013-12-06-en.
 
 Some, but also referrals to issues still under a disclosure policy not made 
 public.
 
 For clarification:
 
 During the analysis associated with name collision, JAS Global Advisors 
 discovered a vulnerability. In keeping with ICANN’s “Coordinated 
 Vulnerability Disclosure Reporting” policy, JAS notified ICANN and the 
 affected vendor(s). The exact nature of the vulnerability has not yet been 
 released as the vendor(s) work to mitigate the potential impact of the 
 vulnerability.
 
 Full disclosure: I was on contract to JAS during their name collision efforts 
 and have since joined ICANN.


David,

Does the affected vendor(s) have an expected forecast to address the 
vulnerability so JAS/ICANN can come forward with the issue ? 


Rubens


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Hello from the dns.watch project!

[Rubens Kuhl]

On Aug 16, 2014, at 11:32 PM, Ken Peng o...@dnsbed.com wrote:

 
 Thanks for the info.
 I have two another questions,
 
 1st, does the .watch tld owned by your company fully?

Nope, .watch TLD registry operator is Donuts, Inc:
http://donuts.co



Rubens

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Call for Presentations - DNS-OARC Fall Workshop, October 2014

[Rubens Kuhl]

On Jul 20, 2014, at 6:00 PM, Sebastian Castro sebast...@nzrs.net.nz wrote:

 Call for Presentations - DNS-OARC Fall Workshop, October 2014
 
 Next OARC Fall Workshop will take place in Los Angeles, California, USA
 on October 11th to the 13th, the weekend before ICANN51. On Monday
 October 13th there will be a joint session with ICANN Tech Day. OARC is
 requesting proposals for presentations, with a preference for DNS data
 analysis tools and techniques.

Is the venue for DNS-OARC defined, will be the same as ICANN51 ? 



Rubens

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Current thinking on internal corporate/campus domain names

[Rubens Kuhl]

 
 RFC 2606 seems to suggest using a registered domain.  That¹s great except
 that split-brain inevitably creeps into the equation.  Is this a case of
 choosing the ³least worst² option?


Register a domain, but delegate it to DNS servers that are not in your network 
and always contains a null-zone. Most registrars will provide you such service 
for free. 

Rubens

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Official WHOIS redirector for TLDs

[Rubens Kuhl]

Em 19/03/2014, à(s) 14:30:000, Florian Weimer f...@deneb.enyo.de escreveu:

 Is there are offical, documented WHOIS redirector for TLDs with some
 long-term interface stability.  WHOIS.IANA.ORG might do the job, but I
 couldn't find official documentation pointing to it.

Do you mean WebWHOIS ?All new gTLDs are required to have whois.nic.TLD for 
port 43 services, and it's usual for that URL to also have WebWHOIS. The tricky 
part is knowing who is implementing http://whois.nic.TLD and who is 
implementing https://whois.nic.TLD.



Rubens


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Official WHOIS redirector for TLDs

[Rubens Kuhl]

Em 19/03/2014, à(s) 14:52:000, Florian Weimer f...@deneb.enyo.de escreveu:

 * Rubens Kuhl:
 
 Em 19/03/2014, à(s) 14:30:000, Florian Weimer f...@deneb.enyo.de escreveu:
 
 Is there are offical, documented WHOIS redirector for TLDs with some
 long-term interface stability.  WHOIS.IANA.ORG might do the job, but I
 couldn't find official documentation pointing to it.
 
 Do you mean WebWHOIS ?
 
 No, the good old port 43 protocol.
 
 All new gTLDs are required to have whois.nic.TLD for port 43
 services, and it's usual for that URL to also have WebWHOIS. The
 tricky part is knowing who is implementing http://whois.nic.TLD
 and who is implementing https://whois.nic.TLD.
 
 You also need to know what is a new TLD.

Everything that is listed at 
http://newgtlds.icann.org/en/program-status/delegated-strings

Or almost everything that is listed at 
http://publicsuffix.org/list/effective_tld_names.dat and is not a 2-letter TLD. 

I think it's a safe guess that if TLD is unknown to the code, it could try 
whois.nic.TLD. It will address most cases yet to come. 

But if the idea is keeping up to date, 
http://mm.icann.org/pipermail/gtldnotification/ mailing list provides every 
contract signing for a TLD that ICANN makes. After subscribing, parsing of 
received alerts can be automated. 



Rubens


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is it illegal to query the .berlin TLD servers?

[Rubens Kuhl]

Em 13/01/2014, à(s) 12:52:000, Alexander Mayrhofer alexander.mayrho...@nic.at 
escreveu:

 Florian Streibelt wrote:
 # dig +short txt berlin
 ;; Truncated, retrying in TCP mode.
 The .berlin-zone is protected through the German Copyright-Law.  Beyond it
 is protected by criminal law and data protection law.  Unauthorised entry 
 to
 the zone is prohibited.  All rights, in particular the right of 
 duplication,
 circulation or usage, belong exclusively to nic.berlin, unless you have an
 explicit written agreement with nic.berlin.
 
 As the backend operator for .berlin, we have now removed the respective 
 record from our zone generation logic. As far as I understand, the original 
 intent of the record was to attach a legal notice to the zone that survives a 
 zone transfer, and - as far as i know - the intent was also that this 
 disclaimer would only apply to the zone as a whole. A similar record has been 
 in use under .at for ages, and never caused any technical nor administrative 
 issues. 


There's also been a dot less A record for .dk for ages, but even then ICANN 
prohibited those on gTLDs and IAB considered them harmful. 
 


Rubens

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is it illegal to query the .berlin TLD servers?

[Rubens Kuhl]

Em 10/01/2014, à(s) 19:05:000, Miek Gieben m...@miek.nl escreveu:

 [ Quoting rube...@nic.br in Re: [dns-operations] Is it illegal ... ]
 the zone is prohibited.  All rights, in particular the right of 
 duplication,
 circulation or usage, belong exclusively to nic.berlin, unless you have an
 explicit written agreement with nic.berlin.
 
 Actually this is a compliance issue, as only NS, DS and glue records should 
 be present at the zone... 
 
 .wien seems to have the same 'issue'.
 
 I don't really care about this, but it does seem a bit silly to have such a 
 TXT
 record in a DNS zone.


Same back-end registry. 


Rubens

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] nameservers being attacked

[Rubens Kuhl]

Em 26/11/2013, à(s) 00:22, Mark Andrews ma...@isc.org escreveu:

 
 In message 5293fa31.9030...@dnsbed.com, Dnsbed Ops writes:
 Hello,
 
 My nameservers currently have been meeting the attacks.
 All  these queries are against one special domain, from the seemed fake IPs.
 And those eat up the bandwidth quickly since I run the nameservers with 
 hosting servers.
 Can you help? Thanks in advance.
 
 The logs actually look like the queries are from recursive servers
 following normal recursion looking at the mixture of flags and that
 they are directed at a official server for the zone.
 
 ns6.cloudwebdns.com.  3600IN  A   116.251.209.248
 ns6.cloudwebdns.com.  3600IN  A   192.208.187.242
 
 I suspect something is trying to detect whether there is nxdomain
 redirection occuring by prepend a random string to www.byw.so.


Which follows the known Chromium (main Google Chrome component) pattern of a 
few  random 10-character requests for every search query to make such detection.


Rubens



___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] chrome's 10 character QNAMEs to detect NXDOMAIN rewriting

[Rubens Kuhl]

 
 Is whatever Google doing documented somewhere?  I didn't see anything
 with https://www.google.com/search?q=chromium+nxdomain+detection+dns
 and one or two similar searches.


Yeap, in the source code. Some discussions on those:
http://productforums.google.com/forum/#!topic/chrome/dQ92XhrDjfk
https://code.google.com/p/chromium/issues/detail?id=47262
http://serverfault.com/questions/235307/unusual-head-requests-to-nonsense-urls-from-chrome
http://www.forensicswiki.org/wiki/Google_Chrome#Start-up_DNS_queries


Rubens


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] summary of recent vulnerabilities in DNS security.

[Rubens Kuhl]

 
 Which brings me to the topic of resolver-behind-upstream attacks which were 
 not commented upon.
 As you know, one of the recommendations of experts and Internet operators, 
 following Kaminsky attack, was `either deploy patches or configure your 
 resolver to use a secure upstream forwarder`, e.g., OpenDNS was typically 
 recommended. The security is established since the resolver is hidden from 
 the Internet and sends its requests only via its upstream forwarder.
 This configuration is still believed to be secure and is recommended by 
 experts.

Would DNSCrypt, supported by OpenDNS, be a possible mitigation to this issue ? 
 
 As you know we found vulnerabilities in such configuration, and designed 
 techniques allowing to find the IP address of the hidden resolver, and then 
 to discover its port allocation (the attacks apply to per-destination ports 
 recommended in [RFC6056] or to fixed ports).
 This attack can be extremely stealthy and efficient, and applies to networks 
 where communication between the resolver and upstream forwarder is not over 
 TCP, and therefore can be fragmented (fragmentation of a single byte 
 suffices).

Would IPSEC between resolver and upstream forward be a possible mitigation to 
this issue ? 


Rubens

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] summary of recent vulnerabilities in DNS security.

[Rubens Kuhl]

Em 22/10/2013, às 18:06:000, Michele Neylon - Blacknight escreveu:

 
 On 22 Oct 2013, at 20:28, Jared Mauch ja...@puck.nether.net
 wrote:
 
 
 It's difficult because there is not universal support amongst registrars.  
 Once again the wheel gets stuck when the technical side meets the business 
 side.  
 
 It's not entirely business that causes the issues .. 

.nl and .cz got massive registrar adoption to DNSSEC offering business 
incentives, so it seems business side accounts for most of it. 

 
 Registry operators do not have a consistent or uniform way of implementing 
 DNSSEC, which makes integration more complex for registrars.

Do you mean sec-DNS 1.0 (RFC 4310) x sec-DNS 1.1 (RFC 5910)?  DS or DNSKEY ? 
Both ? My guess is that sec-DNS 1.1 with DS and DNSKEY would work for all 
DNSSEC-signed EPP TLDs... 

 
 If, as a registrar, we only offered .com then it would be one thing, but 
 that's not the case .. 

Considering RFC 5910 is mandatory for all new gTLDs, and with that requirement 
being extended to gTLD renewals (.info, .biz, .org), it seems implementing RFC 
5910 cuts it. Even ccTLDs like .br (and others for sure) follow RFC 5910. 


Rubens







___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] summary of recent vulnerabilities in DNS security.

[Rubens Kuhl]

Em 22/10/2013, às 20:40, Jim Reid escreveu:

 On 22 Oct 2013, at 22:53, Rubens Kuhl rube...@nic.br wrote:
 
 .nl and .cz got massive registrar adoption to DNSSEC offering business 
 incentives, so it seems business side accounts for most of it. 
 
 So where are the incentives for resolver operators? If they switch on DNSSEC 
 validation and get extra calls to customer support as a result, who pays? How 
 many calls does customer support get before this wipes out an ISP's profit 
 margin? This is another hurdle that has to be overcome somehow if DNSSEC is 
 to be adopted.
 
 It's all well and good that registries offer bribes^Wincentives to their 
 sales channel, but the demand side (ie validation) needs incentives too and 
 their needs are very different from someone who sells domain names and DNSSEC 
 signing services.

What I observed on a local level was connectivity providers that were once hit 
by DNS attacks, whether those attacks could be mitigated by DNSSEC or not, to 
rush into deploying DNSSEC. So besides profit margins, potential liability 
costs (like I was trying to use my Internet Banking and was defrauded) are 
also economic incentives to deploy DNSSEC-validating resolvers. 

Talking to connectivity providers indicated they would see more value in DNSSEC 
if both more domains and the most used domains were DNSSEC-signed. We addressed 
the first part and are coming close to half a million DNSSEC domains in .br 
(without offering bri^H^H^Hincentives to sales channels), but most Top-N sites 
are still not signed with DNSSEC, so they still have an excuse. That 
contradicts a cost-based view of the issue, as having more DNSSEC-signed 
popular domains will only lead to more support calls with resolution issues, so 
either they won't do it either way, or they are indeed acting on a value-based 
view of the issue. 


Rubens






___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Should medium-sized companies run their own recursive resolver?

[Rubens Kuhl]

Em 14/10/2013, às 13:08:000, Paul Hoffman escreveu:

 A fictitious 100-person company has an IT staff of 2 who have average IT 
 talents. They run some local servers, and they have adequate connectivity for 
 the company's offices through an average large ISP.
 
 Should that company run its own recursive resolver for its employees, or 
 should it continue to rely on its ISP?


Every answer to this question will be qualified with IMHO I guess, but IMHO the 
company should run a single recursive server and offer both its own server and 
another server of its choosing to its users. Most platforms these days will 
take two servers and ask both of them for that information, so agility can be 
achieved by a fast internal recursive server, and if that server goes down, the 
slower external server will still be answering requests. 

The choice of external server may prove somewhat tricky; they might want to 
restrict to servers that perform DNSSEC validation like 8.8.8.8 if their own 
server is doing validation. 

https://code.google.com/p/namebench/ is a very straightforward tool to evaluate 
recursive DNS choices, and I'm not afraid to recommend it to average or below 
average IT personnel. If one of the committers in this project is reading this, 
my only feature request would be to also test for DNSSEC 
(https://code.google.com/p/namebench/issues/detail?id=124). 



Rubens

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Capturing 8.8.8.8 Traffic

[Rubens Kuhl]

If you get a Google cluster to be installed in your network, 8.8.8.8 could 
become local without the need for hijacking... but civilized way to deal with 
this is talk to customer about the issues that using a far-away DNS server will 
have. 

Rubens

Em 25/02/2013, às 14:26:000, Graham Beneke escreveu:

 I discovered the other day that a large customer of $dayjob has decided
 that it is a good idea to outsource the LAN support for their head
 office and NOC to a mom-and-pop IT shop. While I question the wisdom in
 that, I was far more concerned by the fact that this mom-and-pop shop
 had configured Google Public DNS as the resolver for everything on their
 LAN.
 
 Now on my corner of the planet Google DNS is 190ms away. Never mind the
 mess we have with all the CDNs mapping their traffic to a different
 continent.
 
 So what are you thoughts on capturing these queries and answering them
 on local resolvers that are 10ms away?
 
 The folks at Google are certainly not going to encourage us to spoof
 responses from their servers but are there any other potential pitfalls
 with doing this to save the customers from themselves?
 
 -- 
 Graham Beneke
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Fingerprinting stub resolvers

[Rubens Kuhl]

Em 04/01/2013, às 14:05:000, Matthew Pounsett escreveu:

 
 A friend of mine at an ISP asked me recently whether I had any suggestions 
 for fingerprinting stub resolvers.  They've got pcaps from the downstream 
 side of their caching servers and are looking at trying to pull more 
 interesting statistics than query counts out of them.  I didn't have any good 
 suggestions, but it seems like an interesting question to ask of one's name 
 server.   Has anyone else tackled this before?  Do tools exist?


One could try looking for queries similar to the ones fpdns does:
https://github.com/kirei/fpdns

fpdns uses very unusual, borderline queries, to try to identify the servers, so 
it might not find much samples in the usual traffic. 


Rubens

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Summary: Anyone still using a Sun/Oracle SCA6000 with OpenSSL?

[Rubens Kuhl]

On Oct 17, 2012, at 2:14 PM, Tony Finch d...@dotat.at wrote:

 On 15/10/2012, at 3:10 AM, Ondřej Surý ondrej.s...@nic.cz wrote:
 
 Just a question - would anyone would be interested in joining a
 project to build an OpenHardware FPGA-based HSM with focus on DNSSEC?
 
 One interesting possibility might be to wire the keys into the FPGA
 configuration, so it has to be re-flashed to change keys.

That would require partially reconfigurable FPGA in order not to disrupt 
operations, so then 2x cells, but both are achievable nowadays. 



Rubens


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Massive DNS poisoning attacks in Brazil

[Rubens Kuhl]

 
 Much better and very detailed analysis (by the same author!) So, it
 was not DNS poisoning at all but a change in the DNS settings of the
 router, after the box was cracked. (DNSchanger-style)
 
 http://www.securelist.com/en/blog/208193852/The_tale_of_one_thousand_and_one_DSL_modems
 __


DNSSEC alone wouldn't have provided much relief on this, but DNSSEC+DANE+HSTS 
could. Most of it due to HSTS, but we need to cover the rogue CA attack-vector.


Rubens




___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] best practices for restaring internal DNS servers

[Rubens Kuhl]

 
 I'm not sure if I phrased my question correctly. It's not about
 redundancy, but about keeping the queries to root/g(TLD) name servers
 to a minimum.
 
 In your example, if 127.0.0.1 was the resolver that just came up again
 after a restart, it wouldn't return a failure for a query that it has
 not yet cached. Or perhaps I just didn't understand your answer.

If your recursive DNS server runs Unbound, you can use

unbound-control dump-cache  filename 

prior to restarting
and then

unbound-control load-cache  filename

I don't recall such an option being available with BIND 9, and it's probably a 
feature to suggest to BIND 10. 


Rubens

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] How to transfer DS records to parent zone?

[Rubens Kuhl]

Em 13/07/2012, às 18:19:000, Jason Gurtz escreveu:

 My parent is .com and in searching around I found a whole lot about what a
 DS record is, but nil on the operational aspects of it.
 
 May a zone administrator transfer their DS record to the parent zone to
 establish the chain of trust, or is it such that only the registrar can do
 this on behalf of the zone admin? My registrar's doc is saying something
 about working with Tucows openHRS platform to enable this transfer but not
 yet and use dlv...
 
 I guess I'm looking for some process at Verisign similar to the nice
 little dlv registry thingy that ICS set up (which is working splendidly,
 thanks) :)
 

ICANN has a list of DNSSEC-enabled registrars here:
https://www.icann.org/en/news/in-focus/dnssec/deployment

For .com, they list AB Name, Domaininfo, Gandi, GoDaddy, Key-Systems, OVH and 
SinnerG as registrars you could transfer your domain to and then upload  a DS 
record. 

Note that Verisign doesn't have process to deal directly with registrants, they 
only interface to registrars. 

Rubens


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs