Re: [dns-operations] A request for "data"

[Joe Abley]

On 27 Apr 2024, at 03:37, Warren Kumari  wrote:

>>> For the record, the last time a ccTLD published a revoked SEP key was April 
>>> 9, 2019 (this was not the revocation of the root zone KSK but a TLD's KSK), 
>>> so I know that none of the TLDs have completed an Automated Updates roll 
>>> since then.
> 
> 
> I don't really understand under what conditions I'd want to have a 
> trust-anchor for any (public) zone.

Every zone administrator has the problem of key distribution if relying parties 
who want to validate signatures exist (if it can be established that none 
exist, why sign your zone). There are multiple approaches that can be used, of 
which publishing key material in your parent zone is just one. Just because we 
might think that's the right method for most people and most zones doesn't mean 
it's the only method.

Different zones and different zone administrators can reasonably make different 
assessments of risk when it comes to trust anchor distribution. There is 
nothing to stop a particular zone administrator making the local assessment 
that they don't like the practices associated with their parent zone, or their 
parent's parent, for example, especially if their concerns are concentrated 
around validation by a known set of relying parties. Zones exist which are not 
discoverable by referral responses (you have to know where the auth servers 
are), which means secure referrals are not available, and such zones want to 
offer validation they need other methods for key distribution.

It's a big Internet. There is a lot of surprising stuff in it. I find it's 
usually a mistake to imagine that anybody knows how all of it works just 
because they know how some of it works. Thinking the opposite and turning over 
rocks can reveal some interesting things.


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

Re: [dns-operations] Mysteries of DNSSEC

[Joe Abley]

On 30 Mar 2024, at 19:18, John Levine  wrote:

> The first surprise I found is that once I turned it on, nearly every
> query, like 99%, asks for DNSSEC. Is this typical or do I have an odd
> set of clients?

If you mean almost all queries had EDNS(0) and DO=1 then I think that's typical.

> Another surprise is that I'm getting a lot of repeated DNSKEY queries
> even though the TTL is an hour. One repeat customer is Cloudflare,
> another is pfsense22.plan-gis.net, at some random company in Germany.
> My theories are A) a bunch of different caches behind a load balancer,
> B) a too small cache, C) buggy software.

I am not very familiar with 1.1.1.1's internals, so I could guess but that 
doesn't seem very helpful. If you'd like an introduction to the people who run 
it I can make one. 


Joe
 

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

Re: [dns-operations] DNS Operations

[Joe Abley]

Op 2 mrt 2024 om 14:13 heeft Lee  het volgende geschreven:

> How about the most popular DNS server software that end-users chose to
> run at home?

So I think you need to qualify whether you are talking about authoritative 
servers or recursive servers or forwarders, and what you mean by popular, and 
which homes. It seems possible that by some measures the most popular DNS 
software that end-users choose at home is 8.8.8.8.

But I think more fundamentally I'm wondering what any of these questions have 
to do with DNS operations.


Joe

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

Re: [dns-operations] DNS Operations

[Joe Abley]

On 2 Mar 2024, at 05:26, Lee  wrote:

> On Sat, Mar 2, 2024 at 1:53 AM Turritopsis Dohrnii Teo En Ming via 
> dns-operations  wrote:
> 
>> As I checked with ChatGPT, it says ISC BIND DNS Server is the most popular 
>> DNS server software in the world.
> 
> I'm guessing that "most popular" is what most home users use - which
> seems to be pi-hole

We don't have to guess!

> What is the most popular DNS software in the world? Please qualify your 
> answer by explaining what measure of popularity you used, including 
> references where possible.

Determining the "most popular" DNS software can be challenging as it depends on 
the criteria used for measurement. However, one common metric used to gauge 
popularity is market share, which can be inferred from various sources such as 
surveys, internet usage statistics, and data from authoritative sources within 
the industry. As of my last update in January 2022, while BIND (Berkeley 
Internet Name Domain) historically held a significant market share and was 
widely regarded as one of the most popular DNS software solutions, the 
landscape might have evolved since then.

To provide a more current and accurate assessment, it's advisable to consult 
recent industry reports, surveys, and data from authoritative sources such as:

DNS-OARC (DNS Operations, Analysis, and Research Center): DNS-OARC provides 
valuable insights into DNS software usage through its workshops, presentations, 
and research publications. Their data could offer a glimpse into the 
distribution of DNS software among top-level domains (TLDs) and major DNS 
operators.
Internet Infrastructure Surveys: Organizations such as W3Techs, Netcraft, and 
BuiltWith periodically conduct surveys and analysis on internet infrastructure, 
including DNS software usage trends. These surveys often provide statistics and 
insights into the distribution of various DNS software solutions across 
websites and internet infrastructure.
Vendor Reports and Surveys: DNS software vendors may release reports or conduct 
surveys among their user base to understand the preferences and usage patterns 
of their customers. Reports from vendors like ISC (Internet Systems 
Consortium), the organization behind BIND, may offer insights into BIND's 
market share and its standing relative to other DNS software.
Industry Analyst Reports: Analyst firms like Gartner, Forrester, and IDC may 
include assessments of DNS software market trends, including market share 
analysis and vendor comparisons, in their reports and research publications.
By consulting these sources and considering their methodologies and data, one 
can better understand the current landscape of DNS software popularity and 
identify the most prevalent solutions in use today.___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN Community Forum

[Joe Abley]

On 15 Nov 2023, at 23:01, Barry Raveendran Greene  wrote:

> The irony - having a DNS workshop in Puerto Rico where DNS Resiliency 
> failures aggravated recovery during Hurricane Maria. 
> 
> My recommendation is to have an entire session on DNS resiliency in the face 
> of disaster. 

There has been a lot of this kind of content hosted by the ccNSO on the "tech 
day" agenda in the past -- lots of really good, transparent reports from 
operators who have suffered outages during disasters, natural and otherwise. I 
encourage everybody to go and dig it out and re-watch it. 


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

Re: [dns-operations] differ

[Joe Abley]

On 12 Nov 2023, at 19:58, Randy Bush  wrote:

> it occurred to me that it migh tme wise to have a rancid like
> (https://shrubbery.net/rancid/) equivalent for critical domains.
> i.e. to git record changes and warn of radical diffs.
> 
> is there any foss tooling in this space?

It seems like it ought to be a small amount of work to create a dnslogin and 
equipment type "dns" so that exactly rancid could be used. TSIG (algorithm, 
name, secret) tuples and master server addresses could live in .cloginrc.

For signed zones this would generate a lot of noise. Maybe some .cloginrc 
options to suppress notification of deltas that were are just signature 
refreshes would be helpful (I see your "radical diffs" above).

I was actually going to hack something together and send a patch to the list by 
way of reply, but then I remembered that rancid is written in perl.


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

Re: [dns-operations] cloudflare-dns.com doesn't have reverse DNS

[Joe Abley]

Op 23 sep 2023 om 19:48 heeft Fred Morris  het volgende 
geschreven:

> I think what's happening with cloudflare-dns reflects my working hypothesis, 
> which is that infrastructury stuff has a higher likelihood of having reverse 
> DNS attended to and cloudy, direct to consumer stuff has a lower likelihood.

I guess, maybe, depending on what you mean by infrastructury and consumer, 
which are pretty broad categories :-)

> The question in my mind is how often the same entity controls the forward 
> domains and the relevant reverse domains, because there is little to no 
> technical impediment in that case for generating and publishing a 
> notional-as-to-intent reverse DNS entry from their own forward emissions.

Using Cloudflare's customers as an example, some people bring their own 
addresses for a variety of reasons and others use Cloudflare addresses.

In both cases it is possible for there to be a one to one, static mapping 
between a single name and a single address, but the more common situation by 
far is for there to be many (sometimes very, very many) names associated with a 
single address, and for the mapping to be dynamic and to change often. What 
reverse DNS strategy makes sense in that scenario? The strategy of not 
provisioning reverse DNS at all in those cases does not seem ridiculous. 

In the case where a one to one mapping does exist between a customer address 
and a customer name, my observation is that people don't bother to make reverse 
DNS available even though it is quite easy to do so. This seems to support the 
apparent consensus that there's no compelling operational reason to bother.


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

Re: [dns-operations] cloudflare-dns.com doesn't have reverse DNS

[Joe Abley]

> Op 22 sep 2023 om 16:26 heeft Grant Taylor  het 
> volgende geschreven:
> 
> I have long viewed operational, or better accurate, reverse DNS as an 
> indication that a network cares enough to set up lesser valued services.

Me too, actually. I don't personally think it's the only such indication, or a 
particularly strong one, even, but I agree with you. 

So, mail sending, traceroute and marketing to niche technical audiences? :-)


Joe

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

Re: [dns-operations] cloudflare-dns.com doesn't have reverse DNS

[Joe Abley]

Op 19 sep 2023 om 18:52 heeft Fred Morris  het volgende 
geschreven:

> But notice that their infrastructure servers do have reverse DNS.

I will freely admit that I am old enough to like reverse DNS and that it makes 
my eyes itch a little bit when it's not there. 

> I don't know that I really have an ask here, other than an observation that 
> it's nice when DNS works; and when it doesn't it's not that difficult to 
> synthesize PTR records from observed traffic. (Further editorializing 
> deleted.)

I have a tangential question, studiously avoiding the question of what 
Cloudflare does or doesn't or should or shouldn't do. (I work for Cloudflare.)

For a long time now it has seemed that reverse DNS is important in a real and 
practical sense if you want to send mail and have someone else accept it. 

Traceroutes are more informative when they have names to go along with the 
numbers, but there are big parts of the world who never got that memo, ever, so 
it's a bit of a stretch to say that's a hard requirement. 

IANA will send back root zone change requests with red ink on them if they 
involve adding a nameserver to a delegation that doesn't have reasonable 
reverse DNS, I think. At least, that used to be true. I don't think there are 
consequences if the reverse DNS disappears later though. 

Apart from mail and some degree of debugging courtesy, what operational reasons 
exist to put effort into reverse DNS in 2023? Are there any? Or is the whole 
reverse tree just a weird anachronism?


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

Re: [dns-operations] New addresses for b.root-servers.net

[Joe Abley]

Hi Matthew,

Signing the ROOT-SERVERS.NET zone would provide the ability to validate its 
contents, but since it's rare for applications and end users to ask questions 
that are answerable from that zone the benefit is arguably marginal. The 
ability to follow a chain or trust through keys published in the root, COM and 
CLOUDFLARE.COM allows names in that zone to be validated completely without a 
secure delegation to the ROOT-SERVERS.NET zone, for example.

There would also be some amount operational complexity in managing the signing 
function, and new failure modes of the ability to validate the contents of that 
zone depended on a clean path of trust through the root and NET zones. These 
are probably minor or manageable.

I think the most compelling argument against signing that zone is that many 
priming queries are sent with DO=1, and a priming response that included 
signatures would be significantly larger than it is without, and would require 
either fragmentation or a non-UDP transport to deliver. This would be a 
significant change to a population of DNS clients whose practical constraints 
regarding DNS message delivery are not well-understood.

So, it's difficult to identify a clear benefit and the risks, although quite 
possibly small, have the potential to be significant.

Joe

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

Re: [dns-operations] Cloudflare TYPE65283

[Joe Abley]

Hi Emmanuel,

On Mon, Mar 27, 2023 at 10:51, Emmanuel Fusté  wrote:

> Cloudflare start to return TYPE65283 in their NSEC records for "compact
> DNSSEC denial of existence"/"minimal lies" for NXDOMAINs.
> It actually break "minimal lies" NXDOMAIN established decoding
> implementations.
> Does someone know the TYPE65283 usage/purpose in this context ?

If a compact negative response includes an NSEC RR whose type bitmap only 
includes NSEC and RRSIG, the response is is indistuishable from the case where 
the name exists but is an empty non-terminal. Adding a special entry in the 
type bitmap avoids that ambiguity and as a bonus provides an NXDOMAINish signal 
as a kind of compromise to those consumers who are all pitchforky about the 
RCODE. The spec currently calls that special type NXNAME.

https://www.ietf.org/archive/id/draft-huque-dnsop-compact-lies-01.txt

The spec is still a work in progress and the NXNAME type does not have a 
codepoint. I believe TYPE65283 is being used as a placeholder. I think 
Christian made a comment to that effect on this list last week, although I 
think he may not have mentioned the specific RRTYPE that was to be used.

If this has caused something to break, more details would be good to hear!

Joe

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

Re: [dns-operations] Resolvers seeing repeated bursts of identical queries

[Joe Abley]

Hey,

On Mon, Jan 9, 2023 at 03:50,  wrote:

> Example of (part of) query burst - in this case the client sends
> bursts of 84 queries within less than 1 ms:
>
> 09:24:56.593259 IP 194.19.79.131.58089 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> 09:24:56.593283 IP 194.19.79.131.38426 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> 09:24:56.593307 IP 194.19.79.131.56931 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> 09:24:56.593346 IP 194.19.79.131.42976 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> 09:24:56.593350 IP 194.19.79.131.11638 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> 09:24:56.593366 IP 194.19.79.131.22476 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> ...
> 09:24:56.594364 IP 194.19.79.131.41548 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)

Have you looked at the IP TTL within each of these bursts?

A random distributionmight suggest a dispersed set of sources (or ALGs or NATs 
or something). Patterns might give other clues.

Joe

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

Re: [dns-operations] PTR Records for Broadband Network?

[Joe Abley]

Hi Michele,

On Nov 23, 2022, at 07:46, Michele Neylon - Blacknight via dns-operations 
 wrote:

> 

Hmm :-)

> Many many moons ago we setup the PTR records for our network using a template 
> that clearly flagged that the IPs were static and used for hosting.
>  
> The result was that the IP 185.97.239.13 would end up with a PTR record of 
> 239-13.colo.sta.blacknight.ie
>  
> Fast forward to 2022 and we now offer broadband to both businesses and 
> consumers, but unfortunately some streaming services and others are blocking 
> access. So our users have issues with Disney+, All4, Netflix and Ticketmaster 
> to name but a few examples. One of the issues appears to be the PTR records.

It might be worth reaching out to some of the people you know your customers 
are struggling with specifically and seeing what they are looking for. The 
presence and functional correctness of PTR records is known to be used as one 
heuristic for e-mail abuse ops; I hadn't heard of it for things like Netflix 
but what do I know?

I assume these PTR records you have made are correctly published. Have you 
checked that the PTR targets (the 239-13.colo.sta.blacknight.ie name and its 
friends) themselves resolve back to the right address?

Are the address ranges you are using for your customers tainted through some 
prior abuse, e.g. by some other organisation that used to use them? Do they 
appear on any of the usual blacklists?

I have seen informal guidance to access providers in the past on what naming 
conventions are useful. I can't seem to find any of them right now but your 
naming scheme does not seem ridiculous. I would be surprised if that's the 
problem.

You might want also to ask this question on the kind of more general lists that 
access and content providers hang out on.


Joe

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

Re: [dns-operations] .ORG still using SHA-1 DNSKEYs

[Joe Abley]

Hi Viktor,

On Tue, 4 Feb 2020 at 21:05, Viktor Dukhovni  wrote:

> Anyone know whom at PIR to nag?  I see that .ORG are still using
> RSA-SHA1 DNSKEYs:
>
> org. IN DS 9795 7 2
> 3922b31b6f3a4ea92b19eb7b52120f031fd8e05ff0b03bafcf9f891bfe7ff8e5
> org. IN DS 9795 7 1 364dfab3daf254cab477b5675b10766ddaa24982
>

We (PIR) are currently discussing a timeline for implementing changes with
Afilias, who run all the back-end registry systems for ORG. Algorithm 8 or
13 both seem like plausible targets, but opinions from the community would
be very welcome.


Joe

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

Re: [dns-operations] DNS over TCP query uptick with iOS 13?

[Joe Abley]

On 9 Oct 2019, at 09:51, David  wrote:

> On 2019-10-09 3:28 a.m., Vladimír Čunát wrote:
>> On 10/9/19 8:53 AM, Xavier Beaudouin wrote:
>>> I saw that DNS over TLS (not TCP) eg port 853/TCP is more and more used.
>> I expect that's due to newer Androids getting to more people? (i.e. it seems 
>> unrelated to OP)
>> https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
>>  
> 
> Yeah we see that too but you are correct we are referring to normal plain-old 
> DNS over TCP. We're now at 10x the query rates compared to pre-iOS 13, which 
> is still not a lot but is growing each day.

Are there any obvious patterns with QNAMEs or with the servers that receive 
those queries? I wonder whether there's some new query pattern that has started 
triggering large responses and whether what we are seeing is iOS falling back 
to TCP transport due to failures in receiving fragments. It'd be interesting to 
look for other increases within the messages being exchnged over TCP, e.g. an 
unusual preponderance of DO=1 or QTYPE=TLSA or something.

The observation reminds me of the iOS release that started pulling root zone 
DNSSEC trust anchors from data.iana.org  almost a decade 
ago. The CDN stats for data.iana.org  at the time 
revealed what looked initially like a step function but in fact was a steep 
curve tracking iOS upgrades amongst the iPhone-owning public. We found someone 
at Apple to talk to at the time to confirm that our interpretation was correct. 
If iOS deployment is the curve you're seeing, then I imagine you can expect 
more growth than 10x before you see a plateau.

Of course, many commonly-used applications tend to upgrade around an iOS 
upgrade. With iOS 13 there seem to be many popular social media apps releasing 
versions with this "dark mode" that I understand the youth like now.


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

Re: [dns-operations] Link-local IP addresses for a resolver?

[Joe Abley]

On 25 Sep 2019, at 18:18, Warren Kumari  wrote:

> Yes, the best practice and advice is to choose something random, but
> network engineers are humans too, and if you had to remember and try
> tell someone over the phone to use fd5a:8109:a679:180a:45d3:d653:22:1
> or fd00:1::1 as the default gateway, which would you rather do?

You could choose something random then give the end-user a DNSSEC-signed DNS 
name instead of the address. So long as they are using a centralised resolver 
service with a long enough privacy policy, a different address family to do the 
resolution over and the operating system uses DoH by default, security is 
guaranteed and end-users gain the reliability of having large companies 
responsible for communicating their local network parameters instead of 
unreliable local technicians who are invariably up to no good. All we need is 
the universal deployment of IPv6, DNSSEC and DoH.


Joe


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] sibling glue

[Joe Abley]

Hi Stéphane,

On 25 Jun 2015, at 7:26, Stephane Bortzmeyer wrote:


On Tue, Jun 23, 2015 at 02:18:59PM -0300,
Joe Abley jab...@hopcount.ca wrote
a message of 119 lines which said:


The EPP data model includes host objects and domain objects. Every
domain is linked to one or more host objects (two or more in
practice, for policy reasons orthogonal to the data model).


But having host objects is not mandatory and some registries (like
.FR) do not use them at all, even when they use EPP.


Indeed. That's what I meant to infer by the text below, which may have 
been too cryptic.


I think there are probably as many answers to this as there are 
registries, and one size definitely doesn't fit all, but let's assume 
you're talking about the kind of EPP data model that grew out of the 
RRP-accessible registries that were operated by Verisign, back in the 
day (i.e. there are domain objects and host objects).



Joe
___
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] sibling glue

[Joe Abley]

On 23 Jun 2015, at 13:03, Tony Finch wrote:


A question for those who know more about registry rules than me...

In the .example zone there can be five kinds of delegation NS record
(taking each record separately rather than the whole delegation NS 
RRset).


I think there are probably as many answers to this as there are 
registries, and one size definitely doesn't fit all, but let's assume 
you're talking about the kind of EPP data model that grew out of the 
RRP-accessible registries that were operated by Verisign, back in the 
day (i.e. there are domain objects and host objects).


The requirements I am stating below are from the DNS point of view 
rather

than from the registry point of view.


I think that's not going to help you get a clear answer, but let's give 
it a try. People who actually know how registries work can correct all 
the horrible mistakes I'm about to type. It has been a while. The EPP 
spec might be worth reading.



glue-forbidden.example. IN  NS  ns0.example.net.
;
; You must not provide glue when the name server host name is not a
; subdomain of the parent domain (.example in this case).


The EPP data model includes host objects and domain objects. Every 
domain is linked to one or more host objects (two or more in practice, 
for policy reasons orthogonal to the data model).


In this case the domain object glue-forbidden.example would be linked to 
a host object ns0.example.net. Since the host object's name is not 
subordinate to the zone to be produced by the registry, it has no 
addresses associated with it. Hence there is no possibility of producing 
a zone from the registry that includes glue records.



not-glue.example.   IN  NS  ns1.example.
;
; A child zone's name server host name can be in the authoritative 
data

; for the parent zone. This isn't glue.


In this case the domain object not-glue.example is linked to the host 
object ns1.example. Since the host object's name is subordinate to the 
zone to be produced by the registry (it's named under example) the host 
object must include one or more addresses. This means that the zone 
produced from the registry can include a glue record alongside the 
delegation.


Whether or not a glue record is actually included in the zone depends on 
the algorithm by which the zone is produced from the registry. The most 
simple algorithm is to include a delegation for every domain object and 
glue records for every host object, but other algorithms that 
distinguish between glue that is definitively required and glue that 
might not be required are surely possible.


Of course, it's still possible to shoot yourself in the foot, e.g.

$ORIGIN COW.
DOMAIN IN NS A.DOMAIN.HORSE.
  NS B.DOMAIN.HORSE.

$ORIGIN HORSE.
DOMAIN IN NS A.DOMAIN.COW.
  NS B.DOMAIN.COW.

No glue is possible to include in either of the COW or HORSE zones (the 
corresponding host objects have no address attributes) and hence none of 
{A, B}.DOMAIN.{COW, HORSE} can ever be resolved unless the nameservers 
for COW or HORSE are also authoritative for the DOMAIN.COW or 
DOMAIN.HORSE zones.



glue-required.example.  IN  NS  ns2.glue-required.example.
;
; You must provide glue when a child zone has a name server whose host
; name is a subdomain of the child zone's apex.


I don't think that condition is part of the EPP data model; the criteria 
that matters here is that the host object's name is subordinate to the 
name of the zone produced from the registry, which means that one or 
more address records for the host are required.


; There are two cases where a child zone has a name server whose host 
name
; is a subdomain of a different sibling child zone of the same parent 
zone.


sibling-must-glue.example.  IN  NS  ns2.glue-required.example.


Ditto.


; The name server of this child zone can also be a name server of its
; sibling zone, in which case the sibling delegation must provide 
glue.


sibling-may-glue.example.   IN  NS  ns3.sibling.example.


Ditto.


; The name server of this child zone can be a subdomain of its sibling
; zone but not a name server for the sibling zone. Glue is optional in
; this case.


The host object ns3.sibling.example requires one or more address 
attributes. Whether or not glue records are published depends on the 
zone publication algorithm, as above.



Joe
___
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] [Security] Glue or not glue?

[Joe Abley]

On 10 Jun 2015, at 19:12, Mark Andrews wrote:


They are also required to follow RFC 1034 which says they can and
should pull the delegation records if that is the only way to fix
the problem.

The community has not given IANA or ICANN permission to override
RFC 1034.


These kinds of vague, blanket pseudo-legal assertions are unhelpful and 
off-topic in an operational mailing list, I think. People who want to 
talk about registry policy would be better off engaging at ICANN, or 
finding equivalent venues for policy specific to individual ccTLDs.



Joe
___
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] .co broken for non-stock queries?

[Joe Abley]

Hi Paul,

On 9 Jun 2015, at 12:10, Paul Wouters wrote:


I noticed that the .co TLD servers seem to not respond to various
queries, eg:

dig +norecurse -t openpgpkey roessner.co. @ns1.cctld.co.
dig +norecurse -t cds roessner.co. @ns1.cctld.co.
dig +norecurse -t uri roessner.co. @ns1.cctld.co.

It oddly enough does return answers for the private use range.

Anyone know of a .co contact to ask what's going on?


CO nameservers (and the registry, I think) are operated by Neustar. 
There are Neustar people here.



Joe
___
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] Lack of tlsa support

[Joe Abley]

On 27 May 2015, at 20:40, Warren Kumari wrote:


On Wed, May 27, 2015 at 3:02 PM, Joe Abley jab...@hopcount.ca wrote:



On 27 May 2015, at 19:14, Warren Kumari wrote:

For what it's worth, I have no problem getting a reasonable 
(negative)

response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from
156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm 
special :-)


Yah, /I/ know you are special -- but I don't know how 156.154.144.195
knows you are.


I think I must have been referring to the server using its name, which 
caused dig to use IPv6. I also see timeouts on IPv4. Full dig output 
included this time, to satisfy Warren's great thirst for cut and paste.


Just goes to show, IPv6 is better. :-)

These are Neustar-hosted zones. Surely there are still Neustar people on 
this list who can say thanks for letting us know, a fix for v4 is in 
the works.



Joe

[scallop:~]% dig @ns1.dns.nic.accountant. accountant. tlsa +noedns

;  DiG 9.8.3-P1  @ns1.dns.nic.accountant. accountant. tlsa 
+noedns

; (2 servers found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 62146
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;accountant.IN  TLSA

;; AUTHORITY SECTION:
accountant.		7200	IN	SOA	ns1.dns.nic.accountant. hostmaster.neustar.biz. 
189 900 900 604800 86400


;; Query time: 71 msec
;; SERVER: 2610:a1:1071::c3#53(2610:a1:1071::c3)
;; WHEN: Thu May 28 10:35:33 2015
;; MSG SIZE  rcvd: 98

[scallop:~]% dig @ns1.dns.nic.accountant. accountant. tlsa +dnssec

;  DiG 9.8.3-P1  @ns1.dns.nic.accountant. accountant. tlsa 
+dnssec

; (2 servers found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 4456
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65235
;; QUESTION SECTION:
;accountant.IN  TLSA

;; AUTHORITY SECTION:
accountant.		7200	IN	SOA	ns1.dns.nic.accountant. hostmaster.neustar.biz. 
189 900 900 604800 86400
accountant.		86400	IN	NSEC	*.accountant. A NS SOA MX TXT SRV RRSIG NSEC 
DNSKEY
accountant.		7200	IN	RRSIG	SOA 8 1 7200 20150619085628 20150520075628 
28309 accountant. 
P3V+Bfo7JNkH207xoHvboXcIhW9Dulr0YUSMAqllEyepd0ms8Al8Tjs2 
TjIcENJbPA5iBwOZzpW5P2fjsq/jWp02aaOMjqRCRNraPRJD4fGxDtx8 
4ex06Ysp6sOtFRssaCb4BJZ4kvdizCR64RuQdO56shP1AY5+BSKdBby/ tzU=
accountant.		86400	IN	RRSIG	NSEC 8 1 86400 20150619082936 20150520075628 
28309 accountant. 
Yt28u6y0wz+g2L90l/nP7HsmCdzGJ33Pf7+4277PKvLZIdyn+ksR4Rw8 
//3ZgSIn/59P0ZlV5qGh+xlKdOCoh0gMHjXHQkvtXByI5HIg/tXvRA22 
bCbcdHFujBy8WHKZQH6G0UAe+IkpEkMVwIFzSZs+5v1ATNliZUZeP9/C 4R0=


;; Query time: 102 msec
;; SERVER: 2610:a1:1071::c3#53(2610:a1:1071::c3)
;; WHEN: Thu May 28 10:35:44 2015
;; MSG SIZE  rcvd: 484

[scallop:~]% dig @ns1.dns.nic.accountant. something.accountant. tlsa 
+noedns


;  DiG 9.8.3-P1  @ns1.dns.nic.accountant. something.accountant. 
tlsa +noedns

; (2 servers found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 59291
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;something.accountant.  IN  TLSA

;; AUTHORITY SECTION:
accountant.		7200	IN	SOA	ns1.dns.nic.accountant. hostmaster.neustar.biz. 
189 900 900 604800 86400


;; Query time: 63 msec
;; SERVER: 2610:a1:1071::c3#53(2610:a1:1071::c3)
;; WHEN: Thu May 28 10:35:54 2015
;; MSG SIZE  rcvd: 108

[scallop:~]% dig @ns1.dns.nic.accountant. something.accountant. tlsa 
+dnssec


;  DiG 9.8.3-P1  @ns1.dns.nic.accountant. something.accountant. 
tlsa +dnssec

; (2 servers found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 33169
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65235
;; QUESTION SECTION:
;something.accountant.  IN  TLSA

;; AUTHORITY SECTION:
accountant.		7200	IN	SOA	ns1.dns.nic.accountant. hostmaster.neustar.biz. 
189 900 900 604800 86400

*.accountant.   86400   IN  NSECNIC.accountant. A MX TXT SRV 
RRSIG NSEC
*.accountant.		86400	IN	RRSIG	NSEC 8 1 86400 20150619082936 
20150520075628 28309 accountant. 
TrjOnCgHxkycajWjg6FW6Q09Udpr7DIQMtRwh+r6ku8dwvUKFvPvJDE2 
XFUkmce3NqcxQHZvRnAhCado7fOtjlMecSiX/t8Ai1dOMoiCVoVpwbJJ 
rqZuJnbiJM7bLn8Wqodkx4PXIG8WpgRVSjZ7SQf2/IWpC4E7Y5OIynR7 O24=
accountant.		7200	IN	RRSIG	SOA 8 1 7200 20150619085628 20150520075628 
28309 accountant. 
P3V+Bfo7JNkH207xoHvboXcIhW9Dulr0YUSMAqllEyepd0ms8Al8Tjs2 
TjIcENJbPA5iBwOZzpW5P2fjsq/jWp02aaOMjqRCRNraPRJD4fGxDtx8 
4ex06Ysp6sOtFRssaCb4BJZ4kvdizCR64RuQdO56shP1AY5+BSKdBby/ tzU=


;; Query time: 68 msec
;; SERVER: 2610:a1:1071::c3

Re: [dns-operations] Lack of tlsa support

[Joe Abley]

On 28 May 2015, at 0:21, Mark Andrews wrote:

In message a5f5f06b-a4bd-4df5-9381-8f25b6677...@hopcount.ca, Joe 
Abley writ

es:


It's hard to know what you're testing (what gentypereport does), but 
if

you're looking for TLSA records in the ACCOUNTANT zone above, I'm not
sure why; new gTLD operators are constrained by contract as to the
RRTypes they're allowed to publish, and TLSA isn't one of them. It's 
not
obvious that this is a problem for anybody, though; it's not like 
you'd

expect to see a TLSA RRSet in there.


genreport tests non meta types including a unknown type (below) and
checks the rcode returned.  For a name that exists the rcode should
be NOERROR.  You can also specify the type list on the command line
which is what I did for tlsa.


OK. I'm still trying to work out how it was that I could get 
NXDOMAIN/NOERROR+ANSWER=0 responses for TLSA queries when other people 
seem to struggle. I would have pasted the output at the time if I 
thought it was so interesting :-)



We have ICANN checking query rates and uptimes but not protocol
basics (like answering all non meta query types) prior to letting
new TLDs go live.


But again, the servers that serve the TLD zones pragmatically only have 
to serve the record types that are permitted in the zone in order to 
give end-users reasonable performance. There's no production reason I 
can think of that would result of a timeout from a query with QTYPE=TLSA 
to a zone that is certain never to serve a positive response, and which 
no client would ever expect to be there.


I certainly agree with you in principle that this kind of behaviour is 
deplorable and bad, but if it was fixed for these particular servers and 
zones the only noticeable effect would be less mail on this list.


ICANN's pre-delegation checklist includes some requirements for protocol 
compliance, but not all. I imagine it would have been much easier for 
them to be comprehensive in that area if there was a clear specification 
for the DNS and a clear test plan for verifying compliance. Mr Hoffman 
to the courtesy phone.



Joe
___
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] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.

[Joe Abley]

On 27 May 2015, at 13:00, Mark Andrews wrote:


No. Just different query - must be bad.  Different query - don't
know what to do - drop from firewall vendors.


For an enterprise, given that there's no defined use, format (and 
therefore need) for EDNS(1), if your security posture is default deny, 
accept what we know we need then dropping DNS messages with EDNS(1) 
seems like exactly the right thing to do, doesn't it?


I understand the point that this posture makes future development and 
deployment of EDNS(1) hard. I understand why that's a pain for protocol 
development in the DNS. You don't have to explain either of those things 
to me. (Just saying.)


But it's not like anybody is going to succeed in getting an enterprise 
or their firewall vendor to say yes when the request they are hearing is 
can you please open up this hole for an experimental protocol that 
nobody apart from me knows anything about, so that I can play with it.


Remember, these are the people that think ICMP is a security risk.


Joe
___
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] Lack of tlsa support

[Joe Abley]

On 27 May 2015, at 19:14, Warren Kumari wrote:

For what it's worth, I have no problem getting a reasonable 
(negative)

response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from
156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special 
:-)


Unable to parse.


Unsure why. :-)


Are you saying that you *are* getting a reasonable
(negative) response to ACCOUNTANT/IN/TLSA?


Yes. And also to SOMETHING.ACCOUNTANT, both with EDNS0.DO=1 and with no 
EDNS0 (see above).



Joe
___
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] Lack of tlsa support

[Joe Abley]

On 27 May 2015, at 16:16, Mark Andrews wrote:


Do we really have to fight to get every new type supported?

Mark

marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db 
| sh gentypereport tlsa | grep -v all ok

accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout


It's hard to know what you're testing (what gentypereport does), but if 
you're looking for TLSA records in the ACCOUNTANT zone above, I'm not 
sure why; new gTLD operators are constrained by contract as to the 
RRTypes they're allowed to publish, and TLSA isn't one of them. It's not 
obvious that this is a problem for anybody, though; it's not like you'd 
expect to see a TLSA RRSet in there.


What is the point you're making?

For what it's worth, I have no problem getting a reasonable (negative) 
response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from 
156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special 
:-)



Joe
___
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] com. Glue

[Joe Abley]

Hi Jim,

On 19 May 2015, at 17:12, Jim Popovitch wrote:


I'm stuck in the middle with $registrar saying glue exists, and
intodns, et.al., saying no glue exists.   I would appreciate any
insight into why there is no glue appearing for speedyiguana.com (a
mailman dev/test system that i use)

Link for the lazy: http://www.intodns.com/speedyiguana.com

FWIW, I see the following with dig:


The problem with your question and the answers you've heard is that DNS 
protocol elements (glue) and registry data objects (host objects) 
are being conflated. This happens all the time. It may help to chant the 
mantra registries, registrars and registrants are in the database 
business, not the DNS business; the fact that the databases concerned 
exist for the purpose of provisioning the DNS should not distract from 
the fact that they are different.


The COM and ORG zones are published from separate registries.

The EPP spec as implemented for COM and ORG insists that host objects 
with address attributes can only be present if they are subordinate 
names. A host object dns1.domainmail.org in the ORG registry must have 
addresses; a host object dns1.domainmail.org in the COM registry 
cannot have addresses.


So aside from any DNS protocol discussion of whether it's legitimate for 
a COM nameserver to respond with additional-section glue for a 
nameserver named under ORG, the COM registry simply doesn't have the 
information it needs to publish one even if it was a good idea for it to 
do so.


The host object in the ORG registry for dns1.domainmail.org exists, and 
has addresses. I didn't check the others.


[walrus:~]% whois -h whois.pir.org 'host dns1.domainmail.org'
Server Name: DNS1.DOMAINMAIL.ORG
Registrar: eNom, Inc.
IP Address:192.249.57.247
IP Address:2604:180:0:6::2
WHOIS Server:
Referral URL:

[legal nonsense snipped]

[walrus:~]%

Everything seems normal and correct to me.


Joe
___
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] Looking for a public blackhole/sinkhole IP address

[Joe Abley]

On 26 Nov 2014, at 09:25, Stephane Bortzmeyer bortzme...@nic.fr wrote:

 I'm trying to find out if it exists a public IP address which is a
 black hole, swallowing every packet sent to it.
 
 I can do that on my network but I'm wondering if it already exists
 somewhere, may be as an anycasted service (AS112-style).

You could use exactly the AS112 nameservers for this. They are deployed for the 
purpose of attracting junk. They won't give good responses to queries, but you 
don't care about that.


Joe
___
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] Looking for a public blackhole/sinkhole IP address

[Joe Abley]

On 26 Nov 2014, at 14:06, Warren Kumari war...@kumari.net wrote:

 What's wrong with 127.0.0.1? It makes it clear what the intent is, and
 you don't get a much more distributed sinkhole than that...

I'm always wary of using 127.0.0.1 for anything that doesn't really mean you 
should talk to yourself. Without a comprehensive knowledge of the impact, you 
don't know what you're blowing up.

 If there really is a use case, let's try and get a block allocated,
 and encourage folk to anycast - null0 for this.

https://github.com/ableyjoe/draft-jabley-well-known-sinkhole

Needs text. Not submitted. Co-authors welcome.


Joe
___
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] Looking for a public blackhole/sinkhole IP address

[Joe Abley]

On 26 Nov 2014, at 17:05, Florian Lohoff f...@zz.de wrote:

 On Wed, Nov 26, 2014 at 04:10:07PM -0500, Joe Abley wrote:
 
 On 26 Nov 2014, at 14:06, Warren Kumari war...@kumari.net wrote:
 
 What's wrong with 127.0.0.1? It makes it clear what the intent is, and
 you don't get a much more distributed sinkhole than that...
 
 I'm always wary of using 127.0.0.1 for anything that doesn't really mean you
 should talk to yourself. Without a comprehensive knowledge of the impact,
 you don't know what you're blowing up.
 
 If there really is a use case, let's try and get a block allocated,
 and encourage folk to anycast - null0 for this.
 
 https://github.com/ableyjoe/draft-jabley-well-known-sinkhole
 
 Needs text. Not submitted. Co-authors welcome.
 
 Would it make sense to also mention an probably seperate address which should
 generate host unreachables? This should most likely be rate limited
 and probably tcp only or something.

My mental picture of a sinkhole is a hole into which things can be thrown 
without fear that they will come back out. What you're talking about sounds 
more like a volcano, which I would feel less happy standing next to with my 
bags of garbage. :-)

 For certain scenarios a quick nothing here could be useful
 
 E.g. sending smtp backscatter to a sink-hole or botnet command
 and control server.

Can you explain in more detail? I don't think I'm getting it.

If an end-user does something that triggers a packet to be sinkholed, who 
benefits if the sinkhole sources a packet back? This sounds like something that 
could be used to coordinate anonymous sinkhole backscatter towards arbitrary 
victims.


Joe


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] DNS-OARC Fall 2014 Workshop - Los Angeles, California, 11th-13th October

[Joe Abley]

On 11 Sep 2014, at 3:54, Keith Mitchell ke...@dns-oarc.net wrote:

 I can confirm that we still have *plenty* of capacity in our room block
 until CoB today, and having also just tried it the link certainly stil
 works for me. Is it possible you asked for dates outside our 10th-17th
 October window ?

I tried multiple times, 10th-16th, but no matter, I'm booked now -- I just 
couldn't use the group code.


Joe
___
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] DNS-OARC Fall 2014 Workshop - Los Angeles, California, 11th-13th October

[Joe Abley]

Hi all,

Sorry for the non-op question, but Keith's autoresponder says he's busy at 
UKNOF in Belfast and I've unfortunately left all this room booking to the last 
minute.

The group code implied by the link in Keith's earlier mail (below) does not 
exist at this hotel says the Crowne Plaza web page. Anybody know the group 
room rate, and how to get it?


Joe

On 10 Sep 2014, at 11:30, Keith Mitchell ke...@dns-oarc.net wrote:

 A quick reminder that *tomorrow* is the last day that you will be able
 to book accommodation in OARC's room block for this workshop - the ICANN
 Hyatt meeting hotel and other nearby options are all now fully booked.
 
 Keith
 
 
 On 08/27/2014 03:40 PM, Keith Mitchell wrote:
 Here's a reminder that public registration for OARC's Fall Workshop and
 Member AGM is open. This will take place on the 11th to 13th October, in
 Los Angeles, California, USA, and will be held jointly with the ICANN
 ccNSO Tech Day.
 
 Due to heavy demand for accommodation in the area during ICANN week, we
 have arranged a reserved block of rooms for Workshop attendees at
 the nearby Crowne Plaza Beverley Hills, which is about 1.5 miles away
 from the Hyatt.
 
 To book accommodation online, please use this link:
 
 http://www.crowneplaza.com/redirect?path=hdbrandCode=cplocaleCode=enhotelCode=LAXBH_PMID=99801505GPC=OAR
 
 Our rooms are available from Thu 10th through Fri 17th October, with a
 booking cut-off date of 11th September.
 
 ___
 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] DNS-OARC Fall 2014 Workshop - Los Angeles, California, 11th-13th October

[Joe Abley]

On 10 Sep 2014, at 13:49, Peter Losher plos...@isc.org wrote:

 Use the redirect link that Keith provided

Sorry not to have been clear, but that's what I did...

 - once you give it the dates of checkin and checkout it will say OARC Inc

and that's not what happened. It said the group code provided does not exist 
at this hotel.


Joe



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] DNSSEC validation timeout from Afilias TLD

[Joe Abley]

On 23 May 2014, at 20:26, derek.mcumber derek.mcum...@datamtn.com wrote:

 UPDATE:
 
 The issue is was with the KSK key rotation.  Afilias and Verisign have 
 implemented this
 process differently.
 
 You can cancel this request.

According to our records, your request has been resolved.

Thank you for using the DNS.

___
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] Weirdness with glue for old (gone) DNS servers

[Joe Abley]

On 14 May 2014, at 23:18, Mark Andrews ma...@isc.org wrote:

 Then why does't the registry remove all the records below a delegation
 and any records that refer to them from the published zone when a
 delegation is removed?

You're conflating a DNS zone (published from a database) from the registry 
(which is the database).

You need to think in terms of (a) the data model and associated constraints in 
the database, which relates (perhaps indirectly, via a registrar) with the 
instructions received from a registrant, and (b) the scheme by which a zone is 
produced.

For example, in (some? all?) gTLD registries there's a constraint on removing a 
domain object that has subordinate host object dependencies, and there's a 
constraint on removing host objects that have non-superordinate domain object 
dependencies. The way people work around this in practice is with hacks, as was 
seen at the top of this thread.

Once the data constraints are worked around, you publish a zone.


Joe

___
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] DNS-OARC Spring Workshop Final Information

[Joe Abley]

On 10 May 2014, at 8:25, Keith Mitchell ke...@dns-oarc.net wrote:

 For remote attendance, we plan to webcast the open workshop via Google
 Hangouts:
 
 Unfortunately our webcasting team and gear are *still* en-route due to a
 series of flight delays

Fortunately, Dave is now here!

https://www.youtube.com/watch?v=gwp57mcYVQ0

There seems to be a 20-30 second lag on the noise in the room manifesting as 
noise out of the laptop, but it does generally seem to be working.


Joe

___
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] AAAA record for c.root-servers.net

[Joe Abley]

On 28 Mar 2014, at 13:16, Anthony Kirby anthony.ki...@nominet.org.uk wrote:

 the copy available at ftp://rs.internic.net/domain/ does contain the , 
 although that at ftp.internic.net does not;  that's the only diff,  both say 
 last update Jan 3 2013. 

I think rs is run by Verisign and ftp is run by ICANN, and ftp mirrors from rs. 
Kim Davies is on this list and will surely react in due course, but I'm 
guessing he's in transit between Singapore and LA right now following the ICANN 
meeting this week.

Might be just a matter of waiting for a nightly cron job.

If I'm right about the data flow, then the Jan 3 2013 thing is presumably 
something for Verisign to clean up (if they haven't already).


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

[Joe Abley]

On 24 Mar 2014, at 21:46, Leo Vandewoestijne dnsoperati...@dns-lab.com wrote:

 Not exactly official, but the same binairy is using whois-servers.net,
 for anything it doesn't know.

I sent a patch to OpenBSD's whois.c that Theo committed in OPENBSD_2_6 at the 
end of 1999 that made use of Rodney's whois-servers.net. Semi-automagic 
selection of whois servers subsequently appeared in other BSDs; there may well 
have been Linux whois variants that did it earlier. But anyway, this kind of 
behaviour has been around for a while.

 So for some ccTLD's I've requested for an update of missing CNAME entries,
 that were listed in whois.iana.org, but not yet working in whois-servers.net.
 They now work to, but I'm curious how much they will keep up with the nTLD's.

Rodney has always been supremely responsive to any suggestions I have sent his 
way. The new gTLDs have requirements in their contracts that the whois server 
is always found at whois.nic.TLD, I think, which ought to make it easy to keep 
up to date.

A nice feature of looking this stuff up in the DNS is that the namespace easily 
accommodates different servers at different levels, for the bits that feature 
that kind of structure.

[walrus:~]% host co.uk.whois-servers.net
co.uk.whois-servers.net is an alias for whois.nic.uk.
whois.nic.uk has address 213.248.242.41
whois.nic.uk has IPv6 address 2a01:618:8009::92d:f97:4c90:2b79
[walrus:~]% host ac.uk.whois-servers.net
ac.uk.whois-servers.net is an alias for whois.ja.net.
whois.ja.net has address 128.86.25.18
whois.ja.net mail is handled by 1 rimmer.ja.net.
whois.ja.net mail is handled by 2 kryten.ja.net.
[walrus:~]% 


Joe

___
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

[Joe Abley]

On Tuesday 26 November 2013 at 21:17, Damian Menscher wrote:
 Back to solving the problem of traffic at the roots, I've always been curious 
 why recursive resolvers don't just AXFR the root zone file and cache the list 
 of TLDs. Yes, a new TLD might go unnoticed for the duration of your cache, 
 but it's not like we're adding new TLDs every day (yet!). If recursors did 
 this, it would be trivial to avoid sending any of these queries to the roots.


If you want to set up your resolver that way, there's nothing stopping you.

I have frequently argued against any such general recommendation, however. The 
root nameservers are administered by people who have incentives to do a good 
job. Resolvers set up by some random admin one rainy Thursday afternoon to 
transfer the root zone from some place or places that happen to work that day 
constitute an unmaintained critical service, and end-users will pay for it when 
it stops working and nobody can figure out what it is supposed to be doing.

Note, I'm not saying that slaving the root zone on a resolver can't be done, 
and can't be effective, and that there aren't thousands of good admins and 
organisations with sufficient diligence and process to make this work. My 
argument is that the number of resolvers not maintained to that extent reduces 
the size of the former category below the noise floor.

To look at it from a slightly different perspective, there's an advantage in 
being able to measure the response of the root server system to changes in the 
DNS (e.g. root-server s,  glue, DNSSEC, IDNs, new gTLDs). Where the 
bulk of root referrals are performed using queries and responses to/from the 
root servers, we have a place where measurement can happen and trends can be 
identified. If a significant proportion of resolvers in the world slaved the 
root zone, there would be no such system-wide measurement point.

I appreciate one person's measurement is potentially another person's unwanted 
external surveillance, and in general I like decentralisation for that reason. 
It would have been far harder to deploy DNSSEC in the root zone without the 
ability to say convincingly we did actual measurement, there are no signs of 
trouble, however.


Joe
___
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] It's begun...

[Joe Abley]

On 2013-11-14, at 13:22, Anne-Marie Eklund-Löwinder 
anne-marie.eklund-lowin...@iis.se wrote:

 Am I the only one who is surprised of the need for the tld plumbing?

There's a lot of money in TLD plumbing. Apparently.


Joe



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] All NSs for a TLD being in the TLD itself

[Joe Abley]

On 2013-10-29, at 06:18, Jaap Akkerhuis j...@nlnetlabs.nl wrote:

 If I remember correctly, the whole mess was augmented by all these
 resolvers which thought that SE had a delegation only policy. When
 the name servers became in balliwick ...

The threat of delegation-only configuration in BIND9 was one of the things that 
caused me to propose the naming scheme you see for Afilias's hosted TLDs, back 
in the day.

Aside from the general ugliness and confusion that all those similar NS names 
cause (sorry about that) the general approach was to delegate the TLD to names 
in separate zones, but to host those zones alongside the TLD on the same 
nameserver. So, for example, we see

[walrus:~]% dig org. ns +short
a0.org.afilias-nst.info.
d0.org.afilias-nst.org.
b0.org.afilias-nst.org.
c0.org.afilias-nst.info.
a2.org.afilias-nst.info.
b2.org.afilias-nst.org.
[walrus:~]% dig org.afilias-nst.info. ns +short
b0.org.afilias-nst.org.
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
a2.org.afilias-nst.info.
b2.org.afilias-nst.org.
[walrus:~]% dig org.afilias-nst.org ns +short
c0.org.afilias-nst.info.
b0.org.afilias-nst.org.
b2.org.afilias-nst.org.
a0.org.afilias-nst.info.
d0.org.afilias-nst.org.
a2.org.afilias-nst.info.
[walrus:~]% 

This allows any of those nameservers to answer authoritatively for any of those 
three zones, but provides defence against people asserting delegation-only 
semantics in ORG.

The use of separate superordinate TLDs for the nameservers themselves (ORG and 
INFO) was to avoid the question of whether there was a risk in naming them all 
under one TLD, since that question is difficult to answer convincingly; the 
risk profile when you consider all possible failure modes gets complicated to 
describe, quickly.

I haven't worked for Afilias for many years and certainly don't speak for them 
(or PIR) now, so consider this a historical nugget rather than anything 
authoritative about present-day operations or strategy :-)


Joe


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] It's begun...

[Joe Abley]

On Oct 23, 2013, at 16:11, Rick Wesson r...@support-intelligence.com wrote:

 Does ICANN have a root-zone announce list? I remember hearing about it being 
 developed, but can't locate the list subscribe.

I don't believe it does, although I remember Kim Davies telling me it was on 
his list of things to set up. Signalling the customer demand to him directly as 
a reminder surely couldn't hurt, although I seem to think he reads this list.


Joe

___
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] DNS Attack over UDP fragmentation

[Joe Abley]

On 2013-09-07, at 15:07, Paul Wouters p...@nohats.ca wrote:

 On Sat, 7 Sep 2013, Florian Weimer wrote:
 
 Well, there aren't any plans to sign ROOT-SERVERS.NET, are there?
 
 Why sign that when you have the DNSKEY via the DS anyway. You shouldn't
 care which IP answers and whether they can spoof it. If one IP fails,
 try another. If the attacker can rewrite all of that, you should
 probably not be on that network.

Indeed, the only reason to sign ROOT-SERVERS.NET I have heard is that we want 
people to sign, and we want to set a good example, so signing that zone would 
be a good idea. I have not heard a convincing security argument for signing it. 
If there was a good reason, it could be signed.


Joe

___
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] Implementation of negative trust anchors?

[Joe Abley]

On 2013-08-27, at 08:49, Antoin Verschuren antoin.verschu...@sidn.nl wrote:

 How about this solution:
 
 A truly DNSSEC aware authoritative server should not publish a zone,
 not even the unsigned records, when validation fails for that zone.
 That way, if a DNSSEC signed zone is DNSSEC broken, it's also broken
 for a non-validating resolver, there is no competition issue, and the
 zone publisher should fix his zone to get it working at all.
 
 Who will be the first DNS vendor implementing? :-)

That would help avoid some problems. It wouldn't help avoid all problems, 
though. The event horizon for end-user problems is extended based on cached 
records originally served from previous internally-correct zones, and bad 
interactions between successive, well-signed zones can still cause problems.

I seem to think actually that all the prominent public failures near the root 
of the namespace have not been due to zones that were signed incorrectly, but 
rather botched rollovers, parent DS mismatch, accidental use of an old key, etc.

I've long wished for a more general facility where upon successful [AI]XFR I 
could shell out to an arbitrary local executable and do whatever checks I 
wanted before signalling with exit status that this zone is ok to serve. With 
a bit of state held on disk about previous zones you could include some of 
those temporal checks and perhaps catch a few more problems.


Joe



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Odd resolver/cache behavor or normal operation?

[Joe Abley]

Hi Mohamed,

I don't imagine that anybody is going to be able to give you a root cause based 
on just that information. It could be a bug in your resolver, it could be a 
transient problem at google, it could be a sign of successful cache poisoning 
attack, or it could be something else.

I recommend keeping a rolling tcpdump running on all nameservers, and aging out 
the resulting compressed pcaps from cron to avoid filling your local disks. 
It's much better to be able to look for answers with data than to look for 
answers with no data.


Joe

On 2013-08-26, at 10:27, Mohamed Lrhazi ml...@georgetown.edu wrote:

 Hello,
 
 We had mail outage which was caused by one of our three recursive caching DNS 
 servers to be answering a query like seen bellow.
 
 What could explain the fact that this record had zero answers? and why would 
 the cache server, apparently, cache this answer for over 10 hours (until I 
 manually cleared the cache)? A user reported that the cache server was 
 returning  records, but no IPv4, though we dont have an example of such 
 query/response saved. I guess the fact that the server had  record would 
 explain why the bellow response is a NOERROR?
 
 ➜  ~  dig imap.gmail.com @141.161.200.201
 
 ;  DiG 9.9.2-P1  imap.gmail.com @141.161.200.201
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 34151
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ;; QUESTION SECTION:
 ;imap.gmail.com.  IN  A
 
 ;; AUTHORITY SECTION:
 gmail.com.94747   IN  NS  ns3.google.com.
 gmail.com.94747   IN  NS  ns2.google.com.
 gmail.com.94747   IN  NS  ns4.google.com.
 gmail.com.94747   IN  NS  ns1.google.com.
 
 ;; ADDITIONAL SECTION:
 ns2.google.com.   269064  IN  A   216.239.34.10
 ns1.google.com.   269064  IN  A   216.239.32.10
 ns3.google.com.   269064  IN  A   216.239.36.10
 ns4.google.com.   269064  IN  A   216.239.38.10
 
 ;; Query time: 56 msec
 ;; SERVER: 141.161.200.201#53(141.161.200.201)
 ;; WHEN: Sat Aug 24 16:21:17 2013
 ;; MSG SIZE  rcvd: 186
 
 Thanks a lot,
 Mohamed.
 
 ___
 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] Implementation of negative trust anchors?

[Joe Abley]

On 2013-08-23, at 15:14, Vernon Schryver v...@rhyolite.com wrote:

 I can't believe you're seriously suggesting that words in any IETF
 document telling people to use narrow NTAs would have any effect
 on resolver operators.

Personally, my hope is that such words would provide guidance to
software vendors, to constrain resolver operators with sensible
mechanisms that solve specific problems narrowly.

Experience shared by Comcast and Google suggests that NTAs are
necessary for validation on a large scale. However, Comcast and Google
are engaged and have the resources to do the right thing; small
resolver operators are generally not engaged and have fewer resources
available to deal with support-loading (churn-enhancing,
profit-harming) problems whose origins are elsewhere. They are far
more likely to be guided by (a) the hooks available in their software
and (b) the kind of rumour mill that came up with block ICMP for
security reasons.

Reasoned guidance from the IETF at best would improve (a) and decrease
the incidence of (b). At worst, it would do no harm.


Joe
___
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] Implementation of negative trust anchors?

[Joe Abley]

On 2013-08-22, at 12:06, Doug Barton do...@dougbarton.us wrote:

 As stated before, the problem is that after the early adopter period is 
 over we'll be stuck with NTAs forever.

I think we need to acknowledge that there will always be signing problems, and 
there will always be validator operators who know that certain failures are the 
result of those signing problems, and not some kind of attack.

Further, there will always be such validator operators who have Good Reasons to 
accept and serve such responses. We don't need to agree that the reasons are 
sensible, just that some people will have them.

We are not talking about code or protocol quality here, we are talking about 
humans. Code and protocols improve over time. Humans do not.

Last thing, we have NTAs today. People use them.

So, there are two plausible outcomes here:

(a) DNSSEC deployment reverses, and nobody uses it any more, so there is no 
need for NTAs.

(b) We will always NTAs.

I don't feel like there is any reason to aim for outcome (a), which leaves us 
with (b).

If we accept that logic, then the pertinent questions is whether or not NTAs 
should be standardised (in a protocol or operational sense). I think the answer 
is yes. So do others. Some don't see value in it, but that's fine; nobody is 
*requiring* anybody to implement anything.


Joe

___
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] Implementation of negative trust anchors?

[Joe Abley]

Hi Randy,

On 2013-08-22, at 16:58, Randy Bush ra...@psg.com wrote:

 I think we need to acknowledge that there will always be signing
 problems
 
  from a conversation with a friend wiser than i 
 
 the problem is that we are going through a deployment phase where there
 is little penalty for sloppy server ops because so few are validating.
 
 patching over this to be more tolerant of sloppy server ops is going in
 the wrong direction.  we need to think about how to make good server ops
 the easy path:
  o less breakage prone protocols
  o less breakage prone implementations
  o easing fast repair if breakage is known
  o detecting and reporting more aggressively
  o blah blah blah
 
 i.e. put that gun back in your hand

I like that line of thinking. Very nicely put, and it makes me reconsider my 
earlier thinking that NTAs will be useful to someone for ever.

However, I'm still not convinced that the right answer is not to standardise, 
or not to write up a BCP, for reasons of if we write about this, people will 
do it for ever.

We can't predict how long this deployment phase will last, and it seems weird 
to assume that standardisation has no value over that unknown period. As a zone 
publisher, I would very much like to know how people are consuming my data. It 
seems more likely that I can have that insight if there is consistency in the 
way it is done.

When there is sufficient validation in the world that the support costs of 
signing errors shift from validator operators to zone publishers, it seems 
reasonable to predict that any words on NTAs will become useless naturally, on 
their own. That seems far more likely than the outcome where validator 
operators continue to deploy NTAs (at their own cost) for no reason.


Joe
___
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] old root hints still been seen

[Joe Abley]

On 2013-06-22, at 15:12, Jared Mauch ja...@puck.nether.net wrote:

 While processing some openresolver data (yes, blah blah), I see there are 
 still folks providing root referrals to old root hints:
 
 119.151.1.94/53///.^IN^NS^C.PSI.NET|.^IN^NS^TERP.UMD.EDU|.^IN^NS^NS.NASA.GOV|.^IN^NS^NS1.ISI.EDU|.^IN^NS^NS.INTERNIC.NET|.^IN^NS^NS.ISC.org|.^IN^NS^NS.NIC.DDN.MIL|.^IN^NS^AOS.ARL.ARMY.MIL|.^IN^NS^NIC.NORDU.NET

Wow, really, really old.

If we discount the possibility that there are some primed recursive servers 
that haven't been rebooted in twenty years, then what remains is that these 
servers (a) are equipped with badly-stale root hints, and (b) are not sending 
priming queries the way they should.

Peter Koch did some work some time ago to document the priming process. The 
draft withered on the vine, which I think is a shame. (Not that I'm naive 
enough to imagine that the presence or absence of a document in the IETF 
correlates directly to observed behaviour in the wild.)

It would certainly be interesting to find out what software this is.

 ;; ANSWER SECTION:
 version.bind. 0   CH  TXT The Latest and Greatest

Haha :-)


Joe

___
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] OARC website down ?

[Joe Abley]

Seems to be usefully up for me (from AirTel 3G in Zambia).

Aue Te Ariki! He toki ki roto taku mahuna!

On 2013-06-14, at 13:56, Billy Glynn billy.gl...@iedr.ie wrote:

 Hi,

 The DNS-OARC website appears to be down...

 Billy
 ___
 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] DNSCrypt.

[Joe Abley]

On 2013-05-31, at 11:02, Ken A k...@pacific.net wrote:

 What is keeping nameserver vendors from building this into servers?

DNSCrypt provides channel security. The rhetoric surrounding it for a long time 
promoted its use as a replacement for DNSSEC, and that promotion faltered 
because it's not an obvious replacement (DNSCrypt and DNSSEC do different 
things).

As a replacement for TSIG or SIG(0) between stub resolvers and upstream 
validators it might have a use. But replacement is the wrong word, because 
nobody secures those channels today; this leaves DNSCrypt looking like a 
solution to a problem that nobody is really acknowledging out loud that they 
have.

DNSCrypt is quite clever, I think. I don't think it's a lack of cleverness that 
is stopping it from making progress. OpenDNS arguably have a better shot at 
encouraging its deployment than the original authors, since OpenDNS have paying 
customers to talk to (and are no longer talking about it in terms of replacing 
DNSSEC).


Joe

___
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] DNSCrypt.

[Joe Abley]

On 2013-05-31, at 11:24, Dobbins, Roland rdobb...@arbor.net wrote:

 There's no crypto anything inherent in DNS today, heh.

Well, apart from the use of TSIG to authenticate zone transfers.

As I mentioned obliquely, I haven't heard of any widespread use of TSIG or 
SIG(0) to authenticate the channel between a stub resolver and a recursive 
resolver, but I'd hesitate to deny that there's any deployment without thinking 
of what numbers could possibly back up that claim.


Joe

___
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] DNS Performance Test Over TCP

[Joe Abley]

Hi Kareem,

On 2013-05-22, at 10:06, Kareem Ali kareem@centralnic.com wrote:

 I'm trying to run a DNS TCP performance test to a DNS server in a
 lab environment. I'm doing the test from another server connected
 directly with a 1 Gb link. Both servers are running CentOS 6.4. I use
 dnsperf to run my DNS performance test on UDP, and it's giving me what I
 want on both IPv4 and IPv6, but I can't find a proper tool to do it with
 TCP.

Francis Dupont gave a presentation at the DNS-OARC spring workshop about 
exactly this. The motivation for developing the tool he described was that he 
couldn't find a sensible TCP performance tool, so much like your experience.

https://indico.dns-oarc.net/indico/contributionDisplay.py?contribId=21confId=0

https://indico.dns-oarc.net/indico/getFile.py/access?contribId=21resId=0materialId=slidesconfId=0

I don't get the impression that the tool is released yet, but no doubt 
Francis/ISC would be happy to give you an early snapshot.


Joe

___
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] http://www.intodns.com/ no go for tlds

[Joe Abley]

On 2013-05-21, at 10:01, Randy Bush ra...@psg.com wrote:

 http://www.intodns.com/ does not seem to work for cctlds

It seems not to work in a variety of ways (it seems not to know about  
records or DNSSEC, and seems incapable of retrieving a perfectly well-served 
SOA, from what I can see).


Joe

___
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] DNS Issue

[Joe Abley]

On 2013-04-26, at 08:11, wbr...@e1b.org wrote:

 From: Dobbins, Roland rdobb...@arbor.net
 
 The actual problem being that the DNS servers oughtn't to be behind 
 a firewall in the first place.
 
 Can you elaborate on your statement?  I can guess what the reaction around 
 here would be if I suggested it.

This list needs a FAQ. The following is the usual way this conversation pans 
out.

The assumption is that firewall means device that keeps state. This could 
be a firewall, or a NAT, or an in-line DPI device, or something similar. We're 
not talking about stateless packet filters.

A DNS server can process 100,000 qps on only mildly modern iron. With typical 
query patterns, that means something approaching a capacity of 100,000 flows 
per second.

Your steady state query load may be much lower, but DNS servers have a habit of 
attracting flash crowds.

The number of stateful firewalls that can happily handle occasional flows of up 
to 100,000 flows per second two/from individual devices are few. Yours 
probably isn't one of them.


Joe

___
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] [Off-topic] DNS dataset for academic research

[Joe Abley]

On 2013-04-18, at 11:24, Kaio Rafael kaioraf...@dcc.ufam.edu.br wrote:

 I am looking for a DNS dataset for academic research. I have been
 studying .BR DNS dataset (DITL 2008 on DNS-OARC servers), however, I
 would like to investigate more recent traffic.

What are you looking for?

Data from authority-only servers (which ones?), recursive servers,
something else?

Packet captures, something else?

What sample period do you need? Do you need a continuous/complete set
of data within that window, or samples?

How recent?


Joe
___
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] open resolver versio.bind responses

[Joe Abley]

On 2013-04-16, at 10:39, Roy Arends r...@dnss.ec wrote:

 Interesting list. I assume that some resolvers are actually happy to try and 
 resolve version.bind chaos txt on your behalf, and so you might see the 
 version.bind response from either the IANA roots or some alternative servers.

Is there actually any resolver that will do a recursive lookup for a CH class 
query?

Where would they find a delegation? There are no CH class hints to use..


Joe
___
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] public consultation on root zone KSK rollover

[Joe Abley]

Hi all,

As advised a month or so ago, the following public comment period is open:

  
http://www.icann.org/en/news/public-comment/root-zone-consultation-08mar13-en.htm

We have received a small number of responses which are accessible from that 
page.

The topic at hand and the specific questions that have been asked as part of 
the consultation are important ones; the decisions taken will have operational 
consequences to any user of the Internet who validates DNS responses with 
DNSSEC.

If you have experience, opinions or expertise to contribute, it would be 
greatly appreciated. The window for being able to submit comments closes on 12 
April 2013 at 23:59 UTC.

Many thanks,


Joe

___
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] Buzzwords Bingo or Radware on SDN DDoS protection

[Joe Abley]

On 2013-04-01, at 11:22, Dobbins, Roland rdobb...@arbor.net wrote:

 On Apr 1, 2013, at 10:18 PM, Rikimaru, Scott wrote:
 
 Perhaps this is how Radware is getting to a diversion model with their 
 products?
 
 OpenFlow is a dynamic, programmable control-plane for networking devices.  
 The initial focus has been on switches.

With OpenFlow, the distinction between switches and routers doesn't really 
exist.

 However, there isn't much in the way of OpenFlow running in production 
 environments.

I hear they have different perspectives on this at Google.

 It's a relatively new, immature concept, and none of the major vendors are 
 really committed to it, as they want to try and keep things proprietary.

... although the number of vendors and models of OpenFlow switch available off 
the shelf seems to continue to rise.

 I think OpenFlow is something which may benefit us (and potentially 
 soi-disant competitors) in the future.  But it isn't something that's widely 
 deployed, today.

What I've observed is that few people who offer commentary on OpenFlow have 
taken the time to play with it. The deployment concerns, I think, are really 
software engineering and release problems. You don't want to depend on a custom 
OpenFlow controller that is only understood by one person who just got hired by 
someone else.

Software engineering discipline is not as common on the network administration 
side of the house as it is on the systems/devops or developer side. Some 
cultural shift is needed.


Joe

___
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] Buzzwords Bingo or Radware on SDN DDoS protection

[Joe Abley]

On 2013-04-01, at 11:26, Dobbins, Roland rdobb...@arbor.net wrote:

 Sorry folks, this was from another list, and I apparently fat-fingered it.  
 Apologies for the spam.

I though it was a bit off-topic :-) Apologies also for the additional noise 
from me (including this bit).


Joe

___
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] N-Root

[Joe Abley]

On 2013-04-01, at 16:17, Robert Edmonds edmo...@isc.org wrote:

 with single-character names, like this:
 
. IN NS a.
. IN NS b.

This idea surfaces from time to time. In other contexts people have gone 
further, questioning the design decision regarding how much additional-section 
glue it is ever necessary to return to a priming query. Perhaps there's room 
for an O and a P, too. Perhaps a Q!

But, how sure are we that single-label hostnames work as expected? There seems 
to be quite some variety in the installed client base (e.g. see 
http://www.icann.org/en/groups/ssac/documents/sac-053-en.pdf) and 
predictability in priming behaviour seems important.

Having the root servers named as you suggest brings them into the root zone as 
full-class citizens, where they will be signed. Priming queries with DO=1 are 
going to get larger replies because of the extra RRSIGs. What might that break?

What assumptions might be hard-coded into middleware, end systems, etc about 
the number of root servers? What DPI/firewalls are going to start rejecting 
priming queries if they look unusual?

Given that answers based in theory and protocol for these and another five 
hundred questions only go so far, how do you design a representative experiment 
to find out for sure? If the answer is deploy and see, how do you detect 
failure? How do you back out the change? Who is responsible for the costs 
imposed on others by this change?

What are the operational benefits of adding root servers when you already have 
13 (22 if you count individual As and s) and hundreds of anycast nodes 
deployed?

Assuming there are operational benefits, what are the costs? How can you 
measure the cost of such a change in a system when the service operators can't 
ever know all their clients, and the clients half the time don't know what 
service they're using?

How can we be sure that the benefits (if we can find any) outweigh the costs 
(which perhaps we can't ever measure)?

What are the political implications of having to choose one operator for a new 
root server? How might this affect the coordination between the other twelve?

I think fitting RRSets in a response packet is actually the most trivial of all 
these issues. Even with a convincing answer to that, the rest of the problem 
space is filled with angry crocodiles.

My point is not to defend any sacred institutions, but rather to illustrate 
that a conservative approach to such a change is hard to find, the costs are 
potentially many and the benefits potentially slight. If there is money and 
energy to burn making the Internet a better place, this isn't (to me) the most 
obvious place to start spending it.


Joe
___
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] Force TCP for external quereis to Open Resolvers?

[Joe Abley]

On 2013-03-31, at 12:09, Vernon Schryver v...@rhyolite.com wrote:

 Only the DNS people think that. The HTTP people are used to many TCP
 connections to manage and do not think it is impossible.
 
 So we could abandon DNS/UDP and move exclusively to DNS/TCP?
 
 No one said that it is impossible to handle lots of DNS/TCP connections.

There seems to be an implicit assumption in this thread that when we say DNS 
over TCP, we mean setting up a TCP session and tearing it down again once per 
query.

If instead we imagine persistent pools of TCP connections open between stubs 
and resolvers which are rarely set up or torn down, how is the overhead in 
bandwidth, latency and CPU cycles substantially different from UDP?

Keeping state for millions of connections sounds like a bit of a nightmare, 
granted. :-)

And I am not blind to the fact that lacking today's low-hanging DNS fruit, 
attackers will just switch to some other protocol/service.


Joe

___
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] Fwd: New Version Notification for draft-jabley-dnsop-anycast-mapping-00.txt

[Joe Abley]

Hi all,

I wrote up the below-referenced draft to document some measurement aspects of 
L-Root.

No doubt there are typos, errors, ambiguity and related horrors in the text 
which could be improved. If you have a few spare minutes and don't mind giving 
me a review, I'd appreciate it.

(apologies if you get some form of this e-mail in multiple places due to 
overlapping list subscriptions)

Thanks,


Joe

Begin forwarded message:

 From: internet-dra...@ietf.org internet-dra...@ietf.org
 Subject: New Version Notification for 
 draft-jabley-dnsop-anycast-mapping-00.txt
 Date: 25 March 2013 15:29:43 EDT
 To: Joe Abley joe.ab...@icann.org
 
 
 A new version of I-D, draft-jabley-dnsop-anycast-mapping-00.txt
 has been successfully submitted by Joe Abley and posted to the
 IETF repository.
 
 Filename:  draft-jabley-dnsop-anycast-mapping
 Revision:  00
 Title: A Summary of Various Mechanisms Deployed at L-Root for 
 the Identification of Anycast Nodes
 Creation date: 2013-03-25
 Group: Individual Submission
 Number of pages: 16
 URL: 
 http://www.ietf.org/internet-drafts/draft-jabley-dnsop-anycast-mapping-00.txt
 Status:  
 http://datatracker.ietf.org/doc/draft-jabley-dnsop-anycast-mapping
 Htmlized:
 http://tools.ietf.org/html/draft-jabley-dnsop-anycast-mapping-00
 
 
 Abstract:
   Anycast is a deployment technique commonly employed for
   authoritative-only servers in the Domain Name System (DNS).  L-Root,
   one of the thirteen root servers, is deployed in this fashion.
 
   Various techniques have been used to map deployed anycast
   infrastructure externally, i.e. without reference to inside knowledge
   about where and how such infrastructure has been deployed.
   Motivations for performing such measurement exercises include
   operational troubleshooting and infrastructure risk assessment.  In
   the specific case of L-Root, the ability to measure and map anycast
   infrastructure using the techniques mentioned in this document is
   provided for reasons of operational transparency.
 
   This document describes all facilities deployed at L-Root to
   facilitate mapping of its infrastructure and serves as documentation
   for L-Root as a measurable service.
 
 
 
 
 The IETF Secretariat
 

___
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] Who is xn--j1amh.? Well, the general problem...

[Joe Abley]

On 2013-03-20, at 09:07, Edward Lewis ed.le...@neustar.biz wrote:

 $ whois -h whois.iana.org XN--J1AMH.
 % IANA WHOIS server
 % for more information on IANA, visit http://www.iana.org
 % This query returned 1 object
 
 domain:   укр
 domain-ace:   XN--J1AMH
 
 status:   ACTIVE
 
 created:  2011-03-01
 source:   IANA

Evidently this data:

  http://www.iana.org/domains/root/db/xn--j1amh.html

was entered last night; it's possible there is a propagation delay to 
whois.iana.org:43, or that something is broken somewhere. The right people at 
IANA are looking into it.

Thanks for the heads up!


Joe
___
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] Who is xn--j1amh.? Well, the general problem...

[Joe Abley]

On 2013-03-20, at 11:18, Rick Wesson r...@support-intelligence.com wrote:

 clearly if twitter is the best option for the community to be
 notified about upcoming changes to the root, we have identified
 something that should be fixed.

:-)

I was briefly enthusiastic about twitter, which is when I knocked that silly 
script together. I mainly ignore it these days. No doubt my twitter biorhythm 
will cycle at some point.

 What is the best method to ask the IANA to make a feed of upcoming changes.

Apparently, mentioning it on this list, since Kim just confirmed that it's on 
the to-do list.


Joe

___
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] Who is xn--j1amh.? Well, the general problem...

[Joe Abley]

On 2013-03-20, at 09:07, Edward Lewis ed.le...@neustar.biz wrote:

 PPS - Here's my whois lookup at 9am (-0500) today.

(-0400, presumably)

 $ whois -h whois.iana.org XN--J1AMH.
 % IANA WHOIS server
 % for more information on IANA, visit http://www.iana.org
 % This query returned 1 object
 
 domain:   укр
 domain-ace:   XN--J1AMH
 
 status:   ACTIVE
 
 created:  2011-03-01
 source:   IANA

To close the loop on this:

 - IANA's databases are populated when a new ISO-3166 code is assigned, or when 
a new fast-track IDN string is approved, in advance of those TLDs actually 
being used or delegated. The records for such strings are sparse, as above.

 - such changes propagate very rapidly to www.iana.org, but more slowly to 
whois.iana.org

 - a change was made for this particular string recently, as could be seen on 
www.iana.org

 - that same change is now reflected in whois.iana.org (see below). There was 
no problem, just a matter of waiting for the data to propagate.

[krill:~]% whois -h whois.iana.org XN--J1AMH
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

domain:   укр
domain-ace:   XN--J1AMH

organisation: Ukrainian Network Information Centre (UANIC), Inc.
address:  10, Volodymyrska str.
address:  Kyiv 01025
address:  Ukraine

contact:  administrative
name: CEO
organisation: Ukrainian Network Information Centre (UANIC), Inc.
address:  10, Volodymyrska str.
address:  Kyiv 01025
address:  Ukraine
phone:+380442309344
fax-no:   +380442309344
e-mail:   c...@uanic.net

contact:  technical
name: Head of UANIC Technical Group
organisation: Ukrainian Network Information Centre (UANIC), Inc.
address:  73, Artema str., office #112
address:  Kyiv 04053
address:  Ukraine
phone:+380503538629
fax-no:   +380442309344
e-mail:   dot...@uanic.net

nserver:  DNS1.U-REGISTRY.COM 91.231.86.6
nserver:  DNS2.U-REGISTRY.NET 188.40.51.250
nserver:  DNS3.DOTUKR.COM 195.64.155.254
nserver:  NSI.UANIC.NET 212.1.66.247
nserver:  TIER1.NUM.NET.UA 193.110.163.134

whois:whois.dotukr.com

status:   ACTIVE
remarks:  Registration information:
remarks:  https://namestore.u-registry.com

created:  2011-03-01
changed:  2013-03-20
source:   IANA

[krill:~]% 


Joe


___
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] DS keys for child zones on same server inline signing

[Joe Abley]

On 2013-03-15, at 00:27, Phil Pennock dnsop+p...@spodhuis.org wrote:

 I finally fixed it with re-running the rndc signing command (preserving
 the previous salt ... I don't believe that's necessary, but shouldn't
 hurt):
 
  rndc signing -nsec3param 1 7 100 $salt_from_logs globnix.net

If you want online signing to work nicely, edit the zone using dynamic 
updates/nsupdate.

If you're editing the zone manually, be sure to rndc freeze/thaw around your 
edits.

I think (but I haven't checked) that a manual edit wrapped in a freeze/thaw 
will still do the wrong thing in some circumstances due to signature reuse 
where signatures really ought to have been regenerated. Same may well go for 
NSEC/NSEC3 RRSets. If you really need to make changes with manual edits, I 
would suggest removing all NSEC/NSEC3/RRSIG scaffolding around whatever you 
change before you thaw, then rndc sign afterwards.

Really though, using dynamic updates is cleaner.


Joe

___
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] DS keys for child zones on same server inline signing

[Joe Abley]

On 2013-03-15, at 13:01, Tony Finch d...@dotat.at wrote:

 Joe Abley jab...@hopcount.ca wrote:
 
 If you want online signing to work nicely, edit the zone using dynamic
 updates/nsupdate.
 
 If you're editing the zone manually, be sure to rndc freeze/thaw around
 your edits.
 
 I thought that wasn't necessary with inline-signing mode.

Right, but I think inline-signing implies either DNS UPDATE or IXFR. Manually 
editing a zone file without rolling the journal back in first is universally 
bad, I think.


Joe

___
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] recursive nameservers with hidden auth zones?

[Joe Abley]

On 2013-03-14, at 08:21, R.P. Aditya adi...@grot.org wrote:

 I didn't mean to be opaque, but just in case it clarifies more:
 
 The question is does the benefit of quicker updates outweigh the risks
 involved in serving a few select zones authoritatively from a recursive
 server that is open to a select population? 

Hosting authoritative zones on recursive servers is recommended for zones that 
are recognised as being for local use, e.g. see RFC 6303. There is nothing 
fundamentally broken with this idea.

What you're suggesting (if I read the inference correctly) is that your 
recursive servers are also acting as stealth slaves for particular zones that 
your user base cares about, zones that are not of only local significance in 
the 6303 sense.

The only risk I can think of that you might consider is that of troubleshooting 
in the future. You need to make sure that the stealth slaves are able to 
maintain up-to-date copies of those zones (i.e. that zone transfer is working) 
to avoid the confusing situation where clients of your recursive servers are 
seeing a different zone revision from the one published on the non-stealth 
authoritative servers (i.e. the servers that are cited in the delegation and 
apex NS sets).

For example, consider a situation where someone else in the organisation 
decides in the future to change the hosting of those zones, but is unaware of 
the stealth slave arrangement on the recursive servers. The zones might move 
and zone transfers of those zones might start to fail, and the result might 
very well be an apparently complex and mysterious situation that it is not 
immediately obvious how to debug.

You might consider whether it makes any practical difference to your users in 
terms of performance or stability for these zones to be served authoritatively 
by your caches or whether the caches actually cache answers from external 
authoritative servers depends. I won't presuppose an answer to that question, 
since it depends on an understanding of your particular circumstances and I 
don't think there's any useful general answer.

 I do realize that that is a determination for my organization to make,
 but if more of the risks were enumerated for non-open resolvers, it
 would be easier to weigh.

The operational concern above is all I can think of, if I've understood the 
question correctly.


Joe

___
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] public consultation on root zone KSK rollover

[Joe Abley]

Hi all,

The following public comment period opened today:

  
http://www.icann.org/en/news/public-comment/root-zone-consultation-08mar13-en.htm

Your responses to the questions presented above would be most welcome. Please 
feel very free to pass on the link to anybody you think might be interested in 
this topic.


Joe
___
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] Defending against DNS reflection amplification attacks

[Joe Abley]

On 2013-02-22, at 13:55, Jo Rhett jrh...@netconsonance.com wrote:

 On Feb 22, 2013, at 4:04 AM, Paul Vixie p...@redbarn.org wrote:
 at which point it's easier to fix source address validation and make THAT 
 universal. which we already know can't be done.
 
 Don't confuse won't with can't. It absolutely can be done. It won't be 
 done because the carriers see profit in laziness, and see no profit in 
 stopping criminals.

Before everybody starts waving red flags and marching in the streets:

 - the carriers of which you speak are big companies;

 - big companies with staff who care about BCP38 have likely already deployed 
it;

 - big companies with non-trivial networks who have yet to deploy it need a 
business reason to do so, since the implementation and support costs are likely 
enough to be significant that there's probably no room under the radar to do it 
there;

 - companies have a responsibility to their shareholders to act according to a 
profit motive;

 - there is no profit motive in increase my costs so that I can decrease the 
costs of my competitors.

If you can describe BCP38 deployment in a non-trivial network such that 
deployment is to the benefit of shareholders and non-deployment is not, I'm all 
ears. Absent regulation and punitive fines for non-compliance, I don't see it.

If there's a logical or practical fallacy in here, someone please point it out. 
(As if I have to type that.)


Joe

___
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] CloudShield advices against dDoS

[Joe Abley]

On 2013-02-20, at 12:46, Stephane Bortzmeyer bortzme...@nic.fr wrote:

 http://www.cloudshield.com/applications/dns-control-traffic-load.asp

I think this particular information security professional with more than 16 
years of experience is a bit confused. I tried hard to find something in there 
I agreed with, but I failed.


Joe

___
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] TelstraClear DNS server issue

[Joe Abley]

On 2013-02-15, at 09:54, Frank Bulk frnk...@iname.com wrote:

 http://www.stuff.co.nz/technology/digital-living/8293896/TelstraClear-intern
 et-outage
 
 Wondering if anyone knows what happened here.  It's seems a bit odd that a
 larger service provider could lose all their DNS servers.  We hand out our
 customers a heterogeneous set of caching resolvers on different networks to
 avoid just this sort of thing.

I have no insight into what happened at TCL, but their 30 minute (as reported) 
outage seems mild compared to other recent large companies.

http://www.computerworld.com.au/article/317356/telstra_internet_outage_points_dns_failure/
http://www.cbc.ca/news/canada/toronto/story/2013/01/09/toronto-rogers-outage.html

The latter was interesting; again, no insider info, but I did see a pronounced 
split in public rage, one side venting generically about Rogers customer 
service, monopolies, the regulator, refunds, I WILL SUE YOU!11! and the other 
side disseminating the magic fix change your DNS to 8.8.8.8 and it all works 
again. See, e.g.

  http://blog2.easydns.org/2013/01/09/rogers-ontario-users-we-can-help/

Perhaps the message that needs to be drilled home everywhere is that recursive 
DNS service is important; if it breaks, everything gets really bad and really 
expensive really quickly.


Joe
___
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] All requests are logged by BIND?

[Joe Abley]

On 2013-01-25, at 15:05, Mike Hoskins (michoski) micho...@cisco.com wrote:

 Well if you believe Google, you're comparing Quincy Public Schools and
 Portland Public Schools, which have different lunch menus, job openings,
 etc.
 
 Sorry, needed to lighten up my day a bit...  8^P
 
 Queries Per Second vs Packets Per Second...obviously PPS should be much
 larger.

Depends what you're counting.

If you're counting requests from a client base that predominately supports 
EDNS0, pps ought to be very close to qps.

If you're counting responses sent to that same client base, then you might well 
see pps  qps if you're counting fragments as separate packets (seems probable).

If you're seeing a lot of TCP fallback, then you can expect the resulting 
handshake per q to cause pps  qps.

You never expect qps  pps, but the degree to which pps  qps depends.


Joe

___
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] google DNS doing validation?

[Joe Abley]

Hi all,

I haven't seen anybody else mention this out loud, but since early last week 
(doing a DNSSEC workshop with NSRC at NZNOG 2013) we saw 8.8.8.8 giving secure 
answers when queried with EDNS0/DO=1.

The responding node of 8.8.8.8 we saw in Wellington was in Sydney, I think 
(routing out through REANZ) but I see the same thing from my desk at home so 
perhaps this is a widespread change.

8.8.8.8 doesn't seem to support NSID, ID.SERVER/CH/TXT or HOSTNAME.BIND/CH/TXT 
but I included a traceroute in case anybody is interested.

The FAQ still says that responses are not validated, but perhaps there is a 
documentation gap. https://developers.google.com/speed/public-dns/faq#dnssec


Joe

[krill:~]% dig @8.8.8.8 hopcount.ca MX +dnssec 

;  DiG 9.8.3-P1  @8.8.8.8 hopcount.ca MX +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 21782
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;hopcount.ca.   IN  MX

;; ANSWER SECTION:
hopcount.ca.21451   IN  MX  10 mail.hopcount.ca.
hopcount.ca.21451   IN  RRSIG   MX 5 2 86400 20130218080658 
20130119073027 37548 hopcount.ca. 
nZCKjUeb/yw6WKJjnHAkuGUWQJ4z0bAZ5A4Q/TCeUXHTlLXW/a9Ax8Aj 
Dw/CymTAWDisKW2yAhi2M9iU5xeQog1+gHmPL+laqsDsEPweYV21+o1W 
Zbb5jHyZKxlMqkW0QYaly4aE7USC4RLqAW+zJkP78Jz0qe/yy1mjddW0 6Ec=

;; Query time: 102 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jan 28 11:32:45 2013
;; MSG SIZE  rcvd: 232

[krill:~]% 
[krill:~]% traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
 1  office.r1.owls.hopcount.ca (199.212.90.1)  2.328 ms  1.608 ms  1.863 ms
 2  216.235.0.30 (216.235.0.30)  55.019 ms  54.184 ms  55.669 ms
 3  216.235.0.133 (216.235.0.133)  66.517 ms  62.202 ms  57.321 ms
 4  gw-google.torontointernetxchange.net (206.108.34.6)  84.828 ms  53.842 ms  
57.366 ms
 5  209.85.255.232 (209.85.255.232)  53.916 ms
216.239.47.114 (216.239.47.114)  55.641 ms  56.410 ms
 6  72.14.236.224 (72.14.236.224)  75.079 ms
72.14.236.226 (72.14.236.226)  75.515 ms  74.957 ms
 7  209.85.249.11 (209.85.249.11)  81.529 ms
72.14.239.93 (72.14.239.93)  81.668 ms
209.85.249.11 (209.85.249.11)  79.977 ms
 8  72.14.238.16 (72.14.238.16)  80.152 ms  80.997 ms
72.14.238.18 (72.14.238.18)  80.736 ms
 9  72.14.232.21 (72.14.232.21)  79.942 ms  93.158 ms  93.146 ms
10  google-public-dns-a.google.com (8.8.8.8)  80.808 ms  80.641 ms  79.708 ms
[krill:~]% 






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] google DNS doing validation?

[Joe Abley]

On 2013-01-28, at 12:14, Hauke Lampe la...@hauke-lampe.de wrote:

 It appears they're validating _only_ when queried with DO=1:

Yeah.

 dig badsig.dnstest.hauke-lampe.de @8.8.8.8 - status: NOERROR
 dig +dnssec badsig.dnstest.hauke-lampe.de @8.8.8.8 - status: SERVFAIL

They do the right thing with CD=1, DO=1:

[krill:~]% dig @8.8.8.8 badsig.dnstest.hauke-lampe.de A +dnssec +cd +noall 
+comments +answer 

;  DiG 9.8.3-P1  @8.8.8.8 badsig.dnstest.hauke-lampe.de A +dnssec +cd 
+noall +comments +answer
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 63408
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; ANSWER SECTION:
badsig.dnstest.hauke-lampe.de. 198 IN   A   85.10.240.253
badsig.dnstest.hauke-lampe.de. 198 IN   RRSIG   A 5 4 300 20100409031244 
20100310031244 46791 badsig.dnstest.hauke-lampe.de. 
HDJtmGW02QHyKB1H23A+wKIHrLY0qsK74a+j8E5z809BfIY3L9HnSp0e 
SJfblQbn5ty8t3yZg31gBPc5n3y3cg==

[krill:~]% 

 Still no alternative to a local validating resolver but a big step in the 
 right direction, I think.

I think so, too.


Joe

___
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] getting .CW recognised in the Google ccTLD tables/databases ...

[Joe Abley]

On 2013-01-21, at 11:55, .CW Registry Curacao regis...@una.net wrote:

 I am not sure this is an issue that you can do anything about, however we 
 have been advised by our colleagues from the ccNSO (ICANN) to send you this 
 email message.
  
 We need some help with getting our ccTLD registered worldwide.
 Several Internet services sites cannot be used by our customers, because the 
 .CW is not recognized.
 In our case it prevents us as university to make use of (for instance) Google 
 Apps.

There are google people on this list who (if they haven't already contacted you 
about it) will no doubt be happy to help you out with that specific problem, in 
their normal efficient way.

More generally, there are many people who make assumptions about what a valid 
domain name is. A common example (I find) can be found in web forms which 
validate e-mail addresses. I can't even remember the number of times I was told 
that jab...@ca.afilias.info was invalid when I was working for Afilias, which 
always struck me as pleasantly ironic, especially when the web forms in 
question were provided by people trying to sell us stuff.

There's no central registry for broken human expectations of how the DNS works. 
You pretty much need to just get used to complaining to the people who provide 
individual broken services when you find them.


Joe

___
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] 10% was Re: .mm ....

[Joe Abley]

On 2013-01-19, at 06:05, Edward Lewis ed.le...@neustar.biz wrote:

 The posed question is whether expanding the lifetime of a signature by 10% 
 is a good idea.

I'll assume (since I didn't see the original mail) that the proposal is to make 
validators tolerant by 10%, rather than to change anything on the authority 
server or on the signers. (If you want to extend the validity of a signature by 
10% when you sign the zone you can already do that just by changing the 
parameters used by your signer.)

If the idea is I'll tolerate an expired signature for 10% of the original 
validity period (I didn't see the original mail) then you're just trading a 
failure today for a failure today + T. I don't think there's much practical 
difference between those outcomes. I don't see the point of the change.

If the idea is I'll tolerate an expired signature for 10% of the original 
validity period and use that extra time to shout loudly about the fact that 
there is a failure then I'd suggest just setting your monitoring systems to 
start the loud klaxons when you only have 10% validity remaining, and avoid the 
change too.

I don't see much good, here.

I think the main things that are missing from the world are:

 - a pragmatic approach to setting signature validity periods in signers, 
mindful of operational considerations

 - people monitoring their own zones and getting early warnings when signer 
policy appears not to be reflected in the DNS

If you plan to refresh your signatures every 7 days, you know that sometimes 
there are failures which might take 4 days to mitigate (long weekends, etc) and 
you know that the number 4 in the preceding phrase is a bit woolly, then make 
your signature validity 7 + 3 * 4 = 19 days. If 3 is not a good enough woolly 
factor, make it higher. If 4 is not enough days, make it higher.

If you see signatures persist beyond 7 days, sound the alarm, but know that you 
don't have to panic because you have another (e.g.) 12 days before any 
embarrassing impact of human waste vs. rotating blades.

The numbers here all depend on local circumstances. I can't imagine a 10% 
style number that would have universal application. If these kinds of things 
are too hard to think about, don't deploy DNSSEC.


Joe

___
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] email address in SOA

[Joe Abley]

On 2012-12-05, at 20:24, Feng He fen...@nsbeta.info wrote:

 for the soa record, i.e,
 google.com. 43199   IN  SOA ns1.google.com. 
 dns-admin.google.com. 2012113000 7200 1800 1209600 300
 
 Though I know dns-admin.google.com is an email address standing for 
 dns-ad...@google.com
 
 I have the questions that:
 
 #1 what purpose is this address used for?

It's used for

(a) legitimate operational communication with a zone maintainer, and

(b) source data for people harvesting addresses in order to send spam.

Since the e-mail resulting from (b) greatly outnumbers the e-mail resulting 
from (a), it's a reasonable assumption on the part of an (a) sender that in 
most cases the address won't be useful. Correspondingly, it's a reasonable 
assumption on the part of most zone maintainers that the address doesn't 
matter, unless you're in the business of collecting spam (or have a really 
effective way to sift through the spam to find the legitimate mail).

But perhaps I'm being over-cynical.


Joe

___
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] Upgrading 9.9.1-P3 and zone transfer is very slow

[Joe Abley]

On 2012-11-22, at 02:17, Ayca Taskin (Garanti Teknoloji) 
ayc...@garanti.com.tr wrote:

 Today I upgraded our company DNS Servers from 9.6.1 to the 9.9.1-P3(one of 
 them is master DNS and the other one is one of slaves) But after upgrading 
 there was a problem with zone transfer. When we changed content of any *.dom 
 file and do rndc-reload, almost after 1 hour later slave DNS Servers took 
 changes. Is it known issue for 9.9.1-P3 ?

You should probably check your log files to find out why the transfer isn't 
happening. Log files are good. Highly recommended.

 The other problem is when we tried to display content of *.dom file located 
 DNS Server(slave) on running 9.9.1-P3, we cannot see clear content, it is 
 unreadable but on master DNS server(9.9.1-P3) we can see clear content dom 
 file. Is this known issue for 9.9.1-P3.

That's a bit vague. http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

 also, do you advice to work on 9.9.1-P3 or upgrade to 9.9.2 will be better 
 for us? Because I downloaded bind 9.9.1-P3 package on 
 http://www.sunfreeware.com but now there is only 9.9.2 bind version on the 
 site, is there any problem 9.9.1-P3 with solaris 10.

This is the list you're looking for: 
https://lists.isc.org/mailman/listinfo/bind-users


Joe
___
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] PTR records, and IANA blackhole

[Joe Abley]

Hi Chris,

 We're going to ISC.
 
 192.175.48.6
 192.175.48.42

All the AS112 nodes answer from those addresses, but it's good that the 
traceroutes and digs gave you some clues about who is actually running the 
instance you are seeing.

From memory, the address to use to report operational problems at ISC is 
n...@isc.org. If that doesn't seem to work or you want direct contacts for 
some other reason, drop me a line off-list and I will do what I can to help.


Joe

___
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 experiments with DNS dampening to fight amplification attacks

[Joe Abley]

On 2012-10-29, at 06:16, Stephane Bortzmeyer bortzme...@nic.fr wrote:

 On Mon, Oct 29, 2012 at 10:13:55AM +,
 Dobbins, Roland rdobb...@arbor.net wrote 
 a message of 20 lines which said:
 
 We apply iptables based rate-limiting on ANY queries with RD bit set. 
 
 The problem with fronting your DNS servers with a stateful firewall 
 
 ? iptables != stateful firewalling.

no, rate-limiting == stateful firewalling.

(I appreciate that there are techniques available to keep the state manageable, 
but state is required to rate-limit and retaining state in front of DNS servers 
in general ought indeed to prompt some careful thinking before implementation.)


Joe

___
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] nscd issue

[Joe Abley]

On 2012-10-04, at 12:17, Mohamed Lrhazi ml...@georgetown.edu wrote:

 Sorry for this off topic question and please do point me to a more 
 appropriate list if you know one.

This doesn't sounds like a DNS problem; it seems like a problem to take up with 
whomever maintains nscd, which in turn depends on what platform you're running 
it on (Linux, Solaris, whatever).

Perhaps I'm about to be proved wrong by a helpful and erudite response from 
someone here who knows something about nscd, but I think you're more likely to 
find help on a platform-specific list (or a vendor support phone number).


Joe

___
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] Google Public DNS

[Joe Abley]

On 2012-10-02, at 18:41, Adam King adam.k...@auda.org.au wrote:

 I am receiving SERVFAIL from both 8.8.8.8 or 8.8.4.4 for specific domains
 (icann.org, ietf.org, isc.org)

Just out of interest, are all the domains you're seeing (or you saw) problems 
with signed?

Perhaps you're seeing an engineering/pre-production test of DNSSEC validation 
at Google, and there are still kinks to iron out.


Joe

___
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] go daddy refuses to register NS not otherwise associated with go daddy controlled domains

[Joe Abley]

On 2012-09-11, at 20:13, George Michaelson g...@apnic.net wrote:

 this is more tending to the provisioning and the registrar requirements side 
 of things, than DNS on the wire.
 
 I recently wrote to godaddy asking why they refused to let me specify 
 arbitrary NS against my domain.

The real answer depends on what registry your domain is registered in. The 
collection of words loosely resembling sentences that you quoted I think are 
trying to illustrate:

 - you need a registered host object for the nameserver in the registry your 
domain lives in
 - until that host object exists, the registry won't accept the change of 
nameservers
 - the host object is controlled by the superordinate domain object if one 
exists

There are others here more qualified to comment on the specifics of the 
host/domain object dependency mess, but you'll need to be more specific about 
the domain name and nameserver you're talking about before you get real answers.

Anyway, regardless, I think it's likely that this is a registry restriction, 
not a godaddy restriction, and that front-line support staff don't always 
explain things as thoroughly as they might (film at 11).


Joe

___
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] go daddy refuses to register NS not otherwise associated with go daddy controlled domains

[Joe Abley]

On 2012-09-11, at 20:36, George Michaelson g...@apnic.net wrote:

 On 12/09/2012, at 10:27 AM, Mark Jeftovic mar...@easydns.com wrote:
 
 I don't understand this, they are saying they will only do this for
 domains under their management, implying that this domain isn't.
 
 Yes. I am saying that using their GUI, to manage a domain which is managed 
 with them, they limit NS to
 
 1) in-baliwick, defined in a hosts.txt file they control and expose a UI to
 
 2) any NS already in use by you, in any domain, under godaddy control
 
 3) any grandfathered in NS, but I cannot verify if this remains true if you 
 drop them from the record of any domain.

The registry requirement is that a host object exist before a domain object is 
linked to it (this is the NET registry we're talking about; other TLD 
registries can be and are different). Further, a host object with a nameserver 
whose name is subordinate to the registry (in this case, ends in NET) needs to 
have address records associated with it, and is sponsored by the registrar who 
sponsors the domain the nameserver is subordinate to.

This is easier to explain with examples. To link the domain QUIRKAFLEEG.NET 
(sponsored by GoDaddy) to the host object A.NS.EXAMPLE.NET (sponsored by 
Network Solutions):

 - request that Network Solutions create a host object A.NS.EXAMPLE.NET (with 
addresses)
 - request that GoDaddy link the domain object QUIRKAFLEEG.NET to the host 
object A.NS.EXAMPLE.NET

These requirements exists for all NET registrars. Exactly how different 
registrars expose this requirement to customers can vary wildly, however.

This is not very easy to explain, even to people who are technologists, so it 
seems slightly unfair to apportion all the blame for the situation on any 
particular registrar (particularly one whose business model is all about hiding 
complicated details and making things easy for non-technical customers). The 
point of the registry/registrar model is that if you don't like how one 
registrar deals with the ugliness, you can always choose another (eventually, 
in some cases, as you saw).


Joe
___
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] register nameservers in different TLD's NS

[Joe Abley]

On 2012-07-16, at 11:21, Mark Jeftovic wrote:

 Sorry, I mispoke when I said glue record. It's not a glue record that
 needs to exist, BUT there does need to be a nameserver defined for that
 hostname at the registry before you can delegate a .com or .net domain
 to it.

For even more clarity, it's perhaps worth mentioning that in gTLDs this is 
mainly an artifact of the EPP data model (which itself inherited aspects from 
earlier data models).

Registries (e.g. ccTLD registries) which take other approaches might not need 
the registration of a host object (or equivalent, in their model).


Joe
___
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] The (very) uneven distribution of DNS root servers on the Internet

[Joe Abley]

Hi Andrew,

On 2012-05-15, at 13:03, Andrew Sullivan wrote:

 On the root-servers.org site, however (which seems
 to be the source of at least some of the data pingdom is using), there
 isn't anywhere one can find a description of how sites are chosen by
 the various operators nor what factors determine provisioning in those
 sites.  

Since you asked: for us, right now, the criteria for a host to host an anycast 
instance of L-Root are:

 - ability to speak BGP
 - willingness and ability to enter into a $0 contract with ICANN
 - willingness to buy a server to ICANN's spec and host it

The question of how sites are chosen for us is, flippantly, that they are 
not. If someone thinks it is worthwhile hosting a copy of L-Root and they meet 
the criteria above, that's good enough for us.

I agree that it would be good to be able to find this kind of information more 
easily from www.root-servers.org.

 Let me make up an implausiblr scenario to illustrate why this might
 matter, and how additional coverage could in principle get worse by
 adding more nodes (an issue not clear in the pingdom article).
 Suppose that in Viet Nam there is an IX, that most of the ISPs in Viet
 Nam have a presence in that IX, and that all the pariticpans in the IX
 have free and easy peering policies.  Suppose also that the ISPs in
 that IX all have extremely good connections to Singapore and Malaysia.
 As a result of all of this, ISPs all have extremely good connectivity
 to F, I, and J.  Suppose L puts a node in the Vietnamese IX.  Service
 is improved in the sense that RTT on root queries goes down when
 they're directed to L.  However, if L accidentally puts an
 underprovisioned node in Viet Nam, and it is sometimes overwhelmed,
 then service actually gets _worse_: the overwhelmed node sometimes
 drops queries or crashes or traffic gets routed elsewhere; in any
 case, there is additional latency that results from having to recover
 from the overload condition.

We're interested in the stability of the system overall, and are not fixated on 
optimising every variable for L. By taking a different approach to other root 
server operators (e.g. focussing on deployment in ISP networks rather than at 
exchange points, deploying many small boxes instead of a smaller number of 
bigger ones, deploying in new locations using different criteria) we're adding 
diversity of approach to the system.

There are undoubtedly scenarios such as the one you described that will cause a 
root server's service to be degraded for some users. I think the important 
thing, however, is that the extent to which individual root servers' 
infrastructure are affected by any individual scenario be usefully different. 
It's not possible to prevent every possible failure mode; what we aim for is to 
make the system as a whole more robust by incorporating as much diversity as 
possible. That diversity is important in operations and deployment, just as 
it's important in (for example) operating system, network equipment vendors, 
DNS software used, etc.


Joe

___
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] The (very) uneven distribution of DNS root servers on the Internet

[Joe Abley]

On 2012-05-16, at 02:04, paul vixie wrote:

 On 5/15/2012 11:56 PM, David Conrad wrote:
 ... In the context of this blog posting, I personally think having
 folks (ISPs in particular) pre-fetch/mirror the root zone in their
 caches is the right answer to pretty much any useful definition of
 fair and equitable related to serving the root zone :-).
 
 now that i've been reminded that the SOA timers are shorter than the
 update frequency and that no NOTIFY is required for up-to-date stealth
 slave service; and now that the root is signed, making it unlikely that
 stealth copies will be amended or that their namespaces will be
 overloaded with other stealth slaves... i agree with drc here. let's
 start encouraging widespread stealth slavery for the root zone.

I'm not convinced that this is a good idea.

Right now we have a root server system that is measurable, and that is operated 
by people who understand the implications of operational choices, and who are a 
small enough group that coordination and communication with other actors in the 
root zone management is practical.

Ad-hoc distribution of root zone operation to an unbounded set of operators 
would result in a system that was much more challenging to measure, that was 
operated by people whose focus was (properly) elsewhere, and with whom reliable 
communication was probably not possible.

I am generally in favour of decentralisation, but in this specific instance I 
can't see much benefit to offset the deficiencies.


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