Re: [dns-operations] DNS Operations

[David Conrad via dns-operations]

--- Begin Message ---
Hi,

On Mar 2, 2024, at 4:57 AM, 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.

ChatGPT is the weaponization of “I saw it on the Internet so it must be true."

> I'm guessing that "most popular" is what most home users use

Probably.

> - which seems to be pi-hole

I’d be very surprised if this were the case.  I’d have thought the vast 
majority of what end users would use (at least on the recursive side) would be 
whatever their ISP was providing, which I strongly suspect is not pi-hole. 

> If you want to define "most popular" as what the root servers 

This would be an odd definition of “most popular”.

> If you want to define "most popular" as DNS servers accessible on the 
> Internet, I'd kind of like to know too.  Maybe bind, maybe not.. I dunno.


Historically (as in the 80s and 90s), it was probably BIND because it was 
pretty much the only DNS package out there. My memory was that when Microsoft 
came out with Active Directory (and, to a lesser extent djbdns), BIND’s market 
share dropped rapidly. There was (is) a tool known as “fpdns” that could be 
used to provide interesting stats on what DNS servers were running, but I 
believe this stopped being effective as developers ‘fixed’ the information 
leakage fpdns made use of.

Fortunately, there are a lot of name servers, both authoritative and recursive, 
out there these days so monoculture concerns aren’t that significant anymore.

Regards,
-drc



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

Re: [dns-operations] [DNSSEC] Venezuela ccTLD broken

[David Conrad]

Hi,

On Jul 20, 2023, at 7:29 AM, Viktor Dukhovni  wrote:
> Finally, for the RSAC (yes not the right forum to formally lodge the
> question), should the root zone DS TTL still be 1 day?  Would a change
> to one hour be acceptable (aligning with it with the practice of many
> TLDs and aiding in more time recovery from mistakes)?


Haven’t thought about the implications enough to comment on the idea, however 
instead of RSSAC, this sounds to me like a question for RZERC to (eventually) 
weigh in on. In the Byzantine world of ICANN, it would need to be brought to 
RZERC by "any of [RZERC’s] members, PTI staff, or by the Customer Standing 
Committee (CSC)”, many of which are on this mailing list.

Regards,
-drc



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] Single label queries on Windows (11)

[David Conrad]

A very long time ago (i.e., back when I was executive director of ISC and 
BINDv9.0.0 was being released) we tried to encourage people to NOT use nslookup 
as it tends to try too hard to “help", leading to all sorts of confusion, e.g., 
the kind you experienced. Instead, we recommended dig as (a) it provides all 
sorts of options that help with pretty much every form of diagnostic you can 
imagine and (b) it doesn’t try to “help”.  We obviously didn’t succeed and it’s 
far too late now (it was back then too).  Ah well…

Regards,
-drc

> On Jul 7, 2023, at 10:35 PM, Petr Menšík  wrote:
> 
> Ah, this is embarrassing. Yes, trailing dot have helped.
> 
> I am sorry for the confusion.
> 
> 
> >nslookup -type=ns org.
> Server: pihole
> Address: 192.168.88.9
> 
> Non-authoritative answer:
> org nameserver = b2.org.afilias-nst.org 
> org nameserver = a2.org.afilias-nst.info 
> org nameserver = c0.org.afilias-nst.info 
> org nameserver = b0.org.afilias-nst.org 
> org nameserver = a0.org.afilias-nst.info 
> org nameserver = d0.org.afilias-nst.org 
> 
> a0.org.afilias-nst.info  internet address = 
> 199.19.56.1
> a2.org.afilias-nst.info  internet address = 
> 199.249.112.1
> b0.org.afilias-nst.org  internet address = 
> 199.19.54.1
> b2.org.afilias-nst.org  internet address = 
> 199.249.120.1
> c0.org.afilias-nst.info  internet address = 
> 199.19.53.1
> d0.org.afilias-nst.org  internet address = 
> 199.19.57.1
> a0.org.afilias-nst.info   IPv6 address = 
> 2001:500:e::1
> a2.org.afilias-nst.info   IPv6 address = 
> 2001:500:40::1
> b0.org.afilias-nst.org   IPv6 address = 
> 2001:500:c::1
> b2.org.afilias-nst.org   IPv6 address = 
> 2001:500:48::1
> c0.org.afilias-nst.info   IPv6 address = 
> 2001:500:b::1
> d0.org.afilias-nst.org   IPv6 address = 
> 2001:500:f::1
> 
> 
> On 7/7/23 20:32, Viktor Dukhovni wrote:
>> On Fri, Jul 07, 2023 at 08:09:39PM +0200, Petr Menšík wrote:
>> 
>>> I have tested recently how Windows 11 behaves when resolving single
>>> label queries.
>>> 
>>> I have expected it might try to use LLMNR. But I did not expect it would
>>> do so also when trying nslookup, a tool which should be DNS only tool.
>>> 
>>> I have tried:
>>> 
>>> nslookup -type=ns com 9.9.9.9
>> It is not too surprising if this is also subject to the default suffix
>> list of the network "connection", which initialises the resolution
>> context, and then just overrides the server.  Have you tried:
>> 
>> nslookup -type=ns com. 9.9.9.9
>> 
>> with an explicit trailing "."?
> I thought I have tried that, but turns out I have tried that only when
> testing behavior of systemd-resolved installation on Linux, where it was 
> useless.
> On Windows it helps. Parameter -debug showed it indeed
> appends default domain suffix and does not try without it after negative
>  response.
> 
> nslookup from ISC BIND9 behaves a bit better, but that is an acceptable 
> difference.
> 
> $ nslookup -domain=home.arpa -debug -type=ns org
> 
> Server:127.0.0.1
> Address:127.0.0.1#53
> 
> 
> QUESTIONS:
> org.home.arpa, type = NS, class = IN
> ANSWERS:
> AUTHORITY RECORDS:
> ->  home.arpa
> origin = localhost
> mail addr = nobody.invalid
> serial = 1
> refresh = 3600
> retry = 1200
> expire = 604800
> minimum = 10800
> ttl = 10800
> ADDITIONAL RECORDS:
> 
> ** server can't find org.home.arpa: NXDOMAIN
> Server:127.0.0.1
> Address:127.0.0.1#53
> 
> 
> QUESTIONS:
> org, type = NS, class = IN
> ANSWERS:
> ->  org
> nameserver = b0.org.afilias-nst.org.
> ttl = 1824
> ->  org
> nameserver = b2.org.afilias-nst.org.
> ttl = 1824
> ->  org
> nameserver = c0.org.afilias-nst.info.
> ttl = 1824
> ->  org
> nameserver = d0.org.afilias-nst.org.
> ttl = 1824
> ->  org
> nameserver = a0.org.afilias-nst.info.
> ttl = 1824
> ->  org
> nameserver = a2.org.afilias-nst.info.
> ttl = 1824
> AUTHORITY RECORDS:
> ADDITIONAL RECORDS:
> 
> Non-authoritative answer:
> orgnameserver = b0.org.afilias-nst.org.
> orgnameserver = b2.org.afilias-nst.org.
> orgnameserver = c0.org.afilias-nst.info.
> orgnameserver = d0.org.afilias-nst.org.
> orgnameserver = a0.org.afilias-nst.info.
> orgnameserver = a2.org.afilias-nst.info.
> 
> Authoritative 

Re: [dns-operations] [Ext] Re: in-addr.arpa. "A" server "loopback network" misconfiguration

[David Conrad]

Mark,

Kim indicated the relevant IETF Area Director advised that no action be taken.  
I suspect instead of reiterating what the changes are that you believe should 
be made, a more useful course of action would be to understand why the relevant 
IETF Area Director provided the advise that they did and whether the 
circumstances have changed after 6 years to change that advice.

Regards,
-drc

> On Jun 23, 2023, at 2:38 PM, Mark Andrews  wrote:
> 
> Thanks
> 
> All the zones listed in RFC6303 (as well as any added to the registry 
> subsequently) need to have insecure delegations. At the moment some do and 
> some don’t. The simplest way to do this is to delegate to the same servers as 
> those of the parent zone.  This keeps the traffic going to the same place and 
> you have a known set of machines to touch (unlike AS112).
> 
> e.g.
> 
> 127.in-addr.arpa NS a.in-addr-servers.arpa.
> …
> 127.in-addr.arpa NS f.in-addr-servers.arpa.
> 
> Where the zone contents are just the SOA record and the NS RRset.  This is 
> also the minimalist change that needs to be made.
> --
> Mark Andrews
> 
>> On 24 Jun 2023, at 02:38, Kim Davies  wrote:
>> 
>> Hi Mark, Hi all,
>> 
>> Quoting Mark Andrews on Friday June 23, 2023:
>>> There should be an insecure delegation for 127.in-addr.arpa. In the 
>>> in-addr.arpa zone. IANA have instructions from the IETF to do this in RFC 
>>> 6303.
>>> There has been a ticket open for years with IANA to correct the missing 
>>> insecure delegations.
>> 
>> I looked into this in our ticketing system. Our practice is to review
>> all open tickets at least weekly until they are resolved, so there are
>> no tickets that are left open indefinitely without activity.
>> 
>> In this case, it looks like we communicated with the relevant IETF Area
>> Director and were advised to take no further action. Since it is now
>> almost 6 years later, happy to take a fresh look at this and see what
>> may need to be done.
>> 
>> kim
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



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

Re: [dns-operations] [Ext] How should work name resolution on a modern system?

[David Conrad]

Mark,

On Jun 15, 2022, at 6:57 PM, Mark Andrews  wrote:
> Views come down to lack of IPv4 address space forcing RFC 1918 on people

No. Split DNS existed before RFC 1918 was written. What ISC defined as “views" 
in BIND 9 is simply an implementation of an independent namespace. The fact 
that it is (now) most frequently used in the context of an independent address 
space is irrelevant.

> and security theatre that hiding names actually protects anything at all.

As people tend to use descriptive names (e.g., “printer”, “rtr”, “gw”, “Mark 
Andrew's iPhone”, etc.), useful information can be obtained from DNS names.

> After 27 years we, as an industry, shouldn’t be requiring anyone to use
> RFC 1918 addresses at all but the laggards in various places across the
> planet have prevented this being cleaned up.

Sorry, who are the Internet Police that are requiring the use of RFC 1918?  
Regardless, people are using split DNS in IPv6 too.

Regards,
-drc





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] Input from dns-operations on NCAP proposal

[David Conrad]

Hi,

On Jun 1, 2022, at 12:39 AM, Petr Špaček  wrote:
> On 24. 05. 22 17:54, Vladimír Čunát via dns-operations wrote:
>>> Configuration 1: Generate a synthetic NXDOMAIN response to all queries with 
>>> no SOA provided in the authority section.
>>> Configuration 2: Generate a synthetic NXDOMAIN response to all queries with 
>>> a SOA record.  Some example queries for the TLD .foo are below:
>>> Configuration 3: Use a properly configured empty zone with correct NS and 
>>> SOA records. Queries for the single label TLD would return a NOERROR and 
>>> NODATA response.
>> I expect that's OK, especially if it's a TLD that's seriously considered.  
>> I'd hope that "bad" usage is mainly sensitive to existence of records of 
>> other types like A.
> 
> Generally I agree with Vladimir, Configuration 3 is the way to go.
> 
> Non-compliant responses are riskier than protocol-compliant responses, and 
> option 3 is the only compliant variant in your proposal.

Just to be clear, the elsewhere-expressed concern with configuration 3 is that 
it exposes applications to new and unexpected behavior.  That is, if 
applications have been “tuned” to anticipate an NXDOMAIN and they get something 
else, even a NOERROR/NODATA response, the argument goes those applications 
_could_ explode in an earth shattering kaboom, cause mass hysteria, cats and 
dogs living together, etc.

While I’ve always considered this concern "a bit" unreasonable, I figure its 
existence is worth pointing out.

Regards,
-drc



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

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

[David Conrad]

[Sorry for the slow response — US holidays and a resolution not to look at my 
computer over said holidays got in the way]

> On Nov 28, 2019, at 12:42 AM, Petr Špaček  wrote:
> On 27. 11. 19 21:49, David Conrad wrote:
>> Petr,
>> 
>>> I think there is even more fundamental problem:
>>> Someone has to pay operational costs of "the new system”.
>> 
>> The “new system” is simply the existing network of resolvers, augmented to 
>> have the root zone.  As far as I can tell, the operational cost would be in 
>> (a) ensuring the resolver is upgraded to support obtaining the root zone and 
>> (b) dealing with the fetch of the root zone with some frequency.
> 
> I hypothetise that in the end requirements for "the new system for root zone 
> distribution" will be fairly close to current requirements for current DNS 
> root system... so I do not see where the cost reduction comes from.

Root zone distribution is on different timescales than root query service.  
Even if the root zone distribution service relies only on AXFR, an effective 
DDoS of that service based on SOA timers would need to be maintained for far 
longer than a DDoS against root service based on cache TTLs.  And, of course, 
folks have already been looking at distributing the root zone via stuff other 
than AXFR (e.g., HTTPS).

Further, the root servers have to respond to pretty much every DNS query that 
gets thrown at them, both UDP and TCP. A root zone distribution service would 
only need respond to AXFR/IXFR requests over TCP (and this could even be gated 
by whitelisting/blacklisting).

Regards,
-drc
(Speaking for myself, not any organization I may be affiliated with)





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

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

[David Conrad]

Petr,

> I think there is even more fundamental problem:
> Someone has to pay operational costs of "the new system”.

The “new system” is simply the existing network of resolvers, augmented to have 
the root zone.  As far as I can tell, the operational cost would be in (a) 
ensuring the resolver is upgraded to support obtaining the root zone and (b) 
dealing with the fetch of the root zone with some frequency.

There would be an additional cost, that of making the root zone available to 
myriads of resolvers, but I believe this is an easily handled issue.

> Personally I do not see how transition to another root-zone-distribution 
> system solves the over-provisioning problem - the new system still has to be 
> ready to absorm absurdly large DDoS attacks.

Two ways:
- greater decentralization: there are a lot more resolvers than the number of 
instances root server operators are likely to ever deploy. While an individual 
resolver might melt down, the impact would only be the end users using that 
resolver (and it is relatively easy for a resolver operator to add more 
capacity, mitigate the attacking client, etc).
- the cost of operating and upgrade the service to deal with DDoS is 
distributed to folks whose job it is to provide that service (namely the ISPs 
or other network operators that run the resolvers).  Remember that the root 
server operators have day jobs, some of which are not particularly related to 
running root service, and they are not (currently) being compensated for the 
costs of providing root service.

> Have a look at https://www.knot-dns.cz/benchmark/ 
>  . The numbers in charts at bottom of the 
> page show that a *single server machine* is able to reply *all* steady state 
> queries for the root today.
> ...
> Most of the money is today spent on *massive* over-provisioning. As an 
> practical example, CZ TLD is over-provisiong factor is in order of *hunderds* 
> of stead-state query traffic, and the root might have even more.


Yep. As mentioned before, steady state is largely irrelevant.

In my view, the fact that root service infrastructure funnels up to a (logical) 
single point is an architectural flaw that may (assuming DDoS attack capacity 
continues to grow at the current rate or even grows faster with crappy IoT 
devices) put the root DNS service at risk.  One of the advantages of putting 
the root zone in the resolver is that it mitigates that potential risk.

Regards,
-drc
(Speaking for myself, not any organization I may be affiliated with)


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

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

[David Conrad]

On Nov 26, 2019, at 11:33 AM, Jim Reid  wrote:
>> On 26 Nov 2019, at 09:16, Florian Weimer > > wrote:
>> 
>> Up until recently, well-behaved recursive resolvers had to forward
>> queries to the root if they were not already covered by a delegation.
>> RFC 7816 and in particular RFC 8198 changed that, but before that, it
>> was just how the protocol was expected to work.
> 
> So what? These RFCs make very little difference to the volume of queries a 
> resolving server will send to the root. QNAME minimisation has no impact at 
> all: the root just sees a query for .com instead of foobar.com 
> . A recursive resolver should already be supporting 
> negative caching and will have a reasonably complete picture of what's in (or 
> not in) the root. RFC8198 will of course help that but not by much IMO.

It would appear a rather large percentage of queries to the root (like 50% in 
some samples) are random strings, between 7 to 15 characters long, sometimes 
longer.  I believe this is Chrome-style probing to determine if there is 
NXDOMAIN redirection. A good example of the tragedy of the commons, like water 
pollution and climate change.

If resolvers would enable DNSSEC validation, there would, in theory, be a 
reduction in these queries due to aggressive NSEC caching.  Of course, practice 
may not match theory 
(https://indico.dns-oarc.net/event/32/contributions/717/attachments/713/1206/2019-10-31-oarc-nsec-caching.pdf).

Of course, steady state query load is largely irrelevant since root service has 
to be provisioned with massive DDoS in mind. In my personal view, the 
deployment of additional anycast instances by the root server operators is a 
useful stopgap, but ultimately, given the rate of growth of DoS attack capacity 
(and assuming that growth will continue due to the stunning security practices 
of IoT device manufacturers), stuff like what is discussed in that paper is the 
right long term strategy.

Regards,
-drc
(Speaking for myself)



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] glitch on [ip6|in-addr].arpa?

[David Conrad]

Adam,

On Oct 11, 2019, at 12:36 AM, Adam Vallee  wrote:
> On Thu, Oct 10, 2019 at 10:40 AM David Conrad  <mailto:d...@virtualized.org>> wrote:
> Adam,
> 
> I’d recommend reading "A Proposed Governance Model for the DNS Root Server 
> System” (https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf 
> <https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf>)
> 
> Regards,
> -drc
> I think you are only helping my point, in that it says the following in that 
> document:
> ...
> 7.RSOs must operate with integrity and an ethos demonstrating a commitment to 
> the common good of the Internet.
> ...
> 11.RSOs must be neutral and impartial.
> 
> Cogent is not activating in a commitment to the common good of the internet, 
> and they are not neutral nor impartial.

I have no comment on Cogent’s behavior in this context, however I think you 
missed my point.

RSSAC 37 is a proposal. It has not been implemented as yet, so it’s a bit hard 
to apply it in this particular case.

More directly, today, there are no agreements that dictate what root server 
operators must do.

Regards,
-drc



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] glitch on [ip6|in-addr].arpa?

[David Conrad]

Adam,

On Oct 10, 2019, at 8:28 AM, Adam Vallee  wrote:
> In my opinion, a new C root operator should be chosen based on the fact that 
> Cogent is not fulfilling its duty to operate their root servers for the 
> benefit of the internet as a whole.
> 
> It seems to me that they are operating the root for the benefit of their 
> customers only. And the fact that they do block access from HE.net 
>  over IPv6 should be grounds for their agreement to be torn 
> up,

What agreement?

> the responsibility should be assigned to a group of ISPs.
> 

> And don't get me started on G root, or H root.

I’d recommend reading "A Proposed Governance Model for the DNS Root Server 
System” (https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf)

Regards,
-drc



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

[David Conrad]

On May 27, 2015, at 6:16 PM, Mark Andrews ma...@isc.org wrote:
 Do we really have to fight to get every new type supported?

Is this a trick question?

The Empirical Evidence 8-ball would appear to say Yes.

Regards,
-drc



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] knot-dns

[David Conrad]

Florian,

On Dec 14, 2014, at 10:55 PM, Florian Weimer f...@deneb.enyo.de wrote:
 When you aim for diversity, you get the union of all bugs, not the 
 intersection.  

In the sense that some portion of your infrastructure may be affected by all 
bugs, sure.

The point is that _all_ your infrastructure won't be affected by a single bug.

Regards,
-drc



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] knot-dns

[David Conrad]

Roland,

I am suggesting that when building out infrastructure, it is prudent to try to 
minimize single points of failure.  One such single point of failure is 
reliance on a software monoculture. 

You appear to be suggesting that the Internet is so broken that taking steps to 
minimize single points of failure in your own infrastructure is pointless.

I suppose we'll have to agree to disagree.

Regards,
-drc

On Dec 14, 2014, at 8:21 PM, Roland Dobbins rdobb...@arbor.net wrote:
 Two words: Microsoft Windows.
 
 Here're two words for you:
 
 Linux botnet.
 
 Or three:
 
 Linux router botnet.
 
 Or two more:
 
 OSX botnet
 
 And two more, for good measure:
 
 Android botnet.
 
 Presumably you too can google packet of death.
 
 I don't need to search for anything - I know at least as much about them as 
 you do.
 
 Since you so conveniently elided my comments to that effect, I'll reproduce 
 them here:
 
 Having worked for a major vendor of telecommunications gear which is quite 
 dominant in its space, and having dealt with packet-of-death issues from 
 said vendor's perspective, I'm here to tell you that all this preaching 
 about avoiding monoculture is a sideshow compared to the real issues faced 
 every day in the trenches.
 
 I've dealt with packet-of-death issues - router input queue wedges, for one - 
 which would've literally brought the entire Internet to its knees.
 
 And yet, it didn't happen.
 
 Maybe you ought to think about that before you tell me to search for anything.
 
 The point is that it is a risk that is easily mitigated by having diversity 
 in your infrastructure.
 
 Maybe so, for small networks which are operated by a handful of competent 
 admins.
 
 But it doesn't scale, and my contention, based upon direct operational 
 experience, is that it often ends up with a negative effect on security 
 posture, as it's easier to be incompetent at securing multiple platforms than 
 it is to be incompetent at administering a single platform.
 
 Does the term closing the barn door after the horses have fled mean 
 anything to you?
 
 Again, see above.
 
 Sorry, where is gross incompetence being demonstrated in this particular 
 case?
 
 Gross incompetence like, say, ~27M open resolvers?  Gross incompetence, like, 
 say, storing passwords in a plaintext file on a network share in a folder 
 called 'Passwords'?
 
 Those are the *real* types of problems we face.  Beside those, software 
 monoculture is noise.
 
 Actually, the problems with software are even more fundamental.  Since we've 
 known about buffer overflows for about forty years, and experienced them in 
 the wild for at least the last 26 years (Morris worm, anyone?), why do 
 software developers persist in using non-typesafe languages?
 
 Until these very basic issues are resolved (pardon the pun), software 
 diversity is a red herring.
 
 Are you really arguing that we should not have diversity in the Internet 
 infrastructure because there are a bunch of problems diversity in the 
 infrastructure won't fix?
 
 I'm saying that, given the current levels of utter incompetence which are the 
 norm in all aspects of the IT and networking industries, expecting people who 
 are utterly unqualified to securely design, deploy, operate, and defend a 
 single platform to magically be able to do so for multiple platforms, without 
 further reducing their organizational security postures, is wishful thinking.
 
 I'm saying that until such time as average people can design, deploy, 
 operate, and defend a single platform effectively, it's utterly unrealistic 
 to expect them to do so for multiple platforms.
 
 Too bad no one has come up with something like Puppet, Chef, Ansible, etc., 
 to help manage infrastructure configuration at scale.
 
 No - what's too bad is that due to aforementioned incompetence (as well as 
 the fact that they aren't as easy to utilize as they ought to be), they're 
 only used on a fraction of networks/deployments worldwide.
 
 Software diversity is a tool that network administrators use to improve 
 resiliency in their infrastructure.
 
 For above-average - emphasis on *average*, it actually means something - 
 personnel in focused organizations, sure.
 
 Not at scale, and not with average personnel.  Quite the opposite, in my 
 experience and observation.
 
 I agree it is not a silver bullet but if I was building out critical 
 infrastructure like (oh say) a root server or a resolver cloud that my 
 customers depend on, I would want to minimize the risk that my 
 infrastructure was vulnerable to a single bug.
 
 You'd be a lot better off worrying about all the BCPs and other mechanisms 
 required to keep those services up and running, and ensuring that you've done 
 them *all*, before you start worrying about software diversity.
 
 If you make so much progress that software diversity is your biggest worry, 
 you've pretty much won.
 
 I've yet to see any organization get there.
 
 I am honestly surprised you're 

Re: [dns-operations] knot-dns

[David Conrad]

Hi,

I'm having a bit of trouble believing this isn't April 1.

On Dec 14, 2014, at 10:38 AM, Florian Weimer f...@deneb.enyo.de wrote:
 While it sounds good on phosphor, the concept of code diversity is so
 abstract, compared to the significant operational challenges and
 associated security challenges of operating separate systems
 performing the same functions (sort of), but differently, that any
 potential benefit is generally outweighed by the negative impact to
 security posture of said challenges.

Sorry, this is simply wrong.

A monoculture invites catastrophic failure. We've seen this over and over again.

Sure, there are a wide variety of other possible failure points, but it would 
be simply insane to (say) have everyone run the exact same code base would mean 
that everyone is subject to the same Packet-of-Death.

Are you seriously arguing that it is better to have your entire infrastructure 
subject to a PoD because it's a bit more challenging to run different software 
bases?

 In particular, running different implementations behind a load
 balancer on the same public IP address can break EDNS detection by
 resolvers, and crafted queries sent to a resolver can make data
 unavailable to that resolver (until a timeout occurs).

Huh?

If you're running multiple implementations behind a load balancer and one is 
not following the protocol specifications such that it breaks EDNS detection, 
the answer is to fix the broken resolver or run a different resolver that 
responds correctly, not run an identical code base.

Regards,
-drc



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] knot-dns

[David Conrad]

On Dec 14, 2014, at 3:05 PM, Roland Dobbins rdobb...@arbor.net wrote:
 I've never run into a situation in which a monoculture would've made things 
 any worse.

?? 

Two words: Microsoft Windows.

 a) packet-of-death vulnerabilities are rare,

Sure, but they happen. For example:

- the resolver bug we're talking about
- pretty much any one of 
https://kb.isc.org/article/AA-00913/74/BIND-9-Security-Vulnerability-Matrix.html
 (not to pick on BIND, other DNS servers have DoS vulnerabilities as well of 
course)
- 
http://www.eweek.com/c/a/IT-Infrastructure/Bug-in-Juniper-Router-Firmware-Update-Causes-Massive-Internet-Outage-709180/
- http://blog.krisk.org/2013/02/packets-of-death.html
- etc.

Presumably you too can google packet of death.

The point is that it is a risk that is easily mitigated by having diversity in 
your infrastructure.

 b) operators ought to have mechanisms in place to filter them when they do 
 show up (*not* silly 'IPS'),

Does the term closing the barn door after the horses have fled mean anything 
to you?  

 c) gross incompetence with a heterogeneous software base is no different than 
 gross incompetence with a monoculture - except that it's more certain.

Sorry, where is gross incompetence being demonstrated in this particular case?

 If we could ever get to the point where a monoculture was the biggest 
 challenge we face, we'd be a lot better off than we are today.

Are you really arguing that we should not have diversity in the Internet 
infrastructure because there are a bunch of problems diversity in the 
infrastructure won't fix?

 And 'a bit more challenging' is a significant understatement, especially at 
 scale.

Too bad no one has come up with something like Puppet, Chef, Ansible, etc., to 
help manage infrastructure configuration at scale.

 Worrying about software monoculture at this juncture is like worrying about 
 urban planning when you don't even have indoor plumbing.

Software diversity is a tool that network administrators use to improve 
resiliency in their infrastructure.  I agree it is not a silver bullet but if I 
was building out critical infrastructure like (oh say) a root server or a 
resolver cloud that my customers depend on, I would want to minimize the risk 
that my infrastructure was vulnerable to a single bug.

I am honestly surprised you're arguing against this.

Regards,
-drc



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] knot-dns

[David Conrad]

Matt,

On Dec 14, 2014, at 6:08 PM, Matthew Ghali mgh...@gmail.com wrote:
 Given the set of practical issues we’re worried about today, delivering a 
 service via multiple codebases certainly isn’t a magic bullet.

Agreed. I would be surprised if anyone seriously argues that it is.

 Upon closer inspection heterogeneity might reduce exposure to catastrophe 
 much less than you’d expect.

If you built out your customer resolver cloud with a set of Nominum servers and 
Unbound servers behind load balancers, would the resolver bug being discussed 
have taken out your infrastructure?

Do you believe managing the configuration of a set of Nominum servers and 
Unbound servers (regardless of how many) is in any way challenging?

Regards,
-drc



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] cool idea regarding root zone inviolability

[David Conrad]

Patrik,

On Nov 26, 2014, at 10:40 PM, Patrik Fältström p...@frobbit.se wrote:
 FWIW, I have been working on this for a while with the Diplo foundation, and 
 I am happy to answer questions (and of course listen to concerns).

It is an interesting idea, but I don't get how it would work.  I asked Jovan 
back when he initially proposed it, but never heard back.

Is the theory behind this that governments around the world would enter into 
some sort of treaty or some other formally binding vehicle that would make the 
root zone inviolable? What would be the sanctions should the holder of the root 
zone (whoever it might be) ignore the inviolability of the root zone and how 
would they be enforced? How is that going to work given (e.g.) the US hasn't 
even been able to ratify the Treaty of the Sea and internal domestic politics 
will generally override any international agreement at politicians' whim?

Regards,
-drc



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] resolvers considered harmful

[David Conrad]

Hi,

On Oct 23, 2014, at 10:36 AM, Paul Vixie p...@redbarn.org wrote:
 until you have done this and have results to report, you'd be wise not
 to make any claims about this possibility.

I've done so, on an off over the years (including mirroring the root zone), and 
found that it mostly just works. In the past, T-Mobile Hotspots and (currently) 
many hotels/Internet cafes can be problematic and that can definitely impact 
the people who read this mailing list due to our relatively high mobility, 
however for the vast majority of Internet users who aren't as mobile, I'm 
fairly certain local resolvers will just work.

However, with that said, I would agree that it would be an interesting area of 
study.

Regards,
-drc



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] resolvers considered harmful

[David Conrad]

On Oct 22, 2014, at 10:27 AM, Florian Weimer f...@deneb.enyo.de wrote:
 I've suggested multiple times that one
 possible way to make DNS cache poisoning less attractive is to cache
 only records which are stable over multiple upstream responses, and
 limit the time-to-live not just in seconds, but also in client
 responses.  

Why not just turn on DNSSEC?

Regards,
-drc



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] resolvers considered harmful

[David Conrad]

Mark,

On Oct 22, 2014, at 12:18 PM, Mark Allman mall...@icir.org wrote:
 Why not just turn on DNSSEC?
 Important zones are still unsigned, so I can understand why there is a
 desire for altenative solutions.
 
 Right.  It isn't like we are lacking for ways to solve the problems we
 know about.  E.g., we know how to mitigate the Kaminsky attack.  But,
 yet, still there are plenty of vulnerable resolvers (per our PAM paper
 From this past spring).  

It might be the case that a good proportion of those vulnerable resolvers 
(e.g., the stupid CPE that responds to DNS queries on their WAN ports) are 
actually already following your proposal.

 E.g., we know how to secure DNS records with
 crypto.  But, yet, broadly speaking we don't do it.  So, perhaps we need
 to re-think things.

As I understand it, you're proposing pushing the resolvers out to the edges 
(something I'm in favor of), however if you're not doing DNSSEC at the edges, 
won't those edge caches still be vulnerable to cache poisoning attack?  
Granted, the impact would be less than in the case of a shared resolver, but a 
shared resolver probably has more folks watching to detect the attack and is 
more likely to be operated by someone with clue...

Regards,
-drc



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] resolvers considered harmful

[David Conrad]

Mark,

On Oct 22, 2014, at 6:07 PM, Mark Allman mall...@icir.org wrote:
 David Conrad d...@virtualized.org:
 As I understand it, you're proposing pushing the resolvers out to the edges 
 That is not what we are proposing.  We are not suggesting resolvers be
 *moved*, but rather *removed*.  That is, clients simply do name lookup
 on their own.

Perhaps I'm being unclear and/or we're having a terminology mismatch. To be 
concrete: are you suggesting that (a) every application on an 'endpoint' 
provide its own iterative resolution, (b) the 'end point' effectively runs an 
iterative caching resolver at 127.0.0.1/::1, or (c) something else?

 All I am saying is that the resolver
 cannot do its job without accepting requests from other hosts.

As a person who frequently runs unbound listening only to 127.0.0.1 on my 
laptop, we may have differing opinions of the scope of the job of a resolver.

 David Conrad d...@virtualized.org:
 if you're not doing DNSSEC at the edges,
 Let me be clear I am not arguing against DNSSEC.  A crypto signed
 record is always better than a clear text record.  But, DNSSEC is still
 not here

It's getting there (cue Geoff Huston :)). BTW, while it may be true that 1% of 
resolvers validate as you mention in your paper, a more interesting number is 
the percentage of clients that are getting validated answers.  IIRC, I believe 
Geoff's numbers are suggesting that percentage is upwards of 20% (too lazy to 
look it up).

 and it seems to me that factoring out some of the
 intermediaries that we know sometimes both play games and have games
 played on them may well be a useful path.

I don't disagree (and have argued the same thing numerous times). By moving 
resolution to the endpoint (whichever way you mean it), you are presumably 
reducing the attack surface, specifically erasing the stub-to-resolver vector 
of attack, at a cost (as Andrew notes) of increased network/authoritative load 
and latency (whether that cost is negligible is an interesting question).  Of 
course, this doesn't remove the resolver-to-authoritative vector of attack, it 
lessens the impact (specifically, a successful attack only impacts the 
endpoint, not the multiple system that are using the resolver).  My point was 
that to definitively fix resolver-to-authoritative, you're going to need 
something like DNSSEC.

Regards,
-drc



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] Hearing first complains about failing internal resolving due to .prod TLD

[David Conrad]

Franck,

On Sep 13, 2014, at 2:19 AM, Franck Martin fmar...@linkedin.com wrote:
 I’m not sure why the dot prod was not first set up to return NXDOMAIN, 
 queries logged, and then source IP contacted to warn them of such upcoming 
 change.

The source IP is a resolver, not the original querier. I’m guessing Google 
doesn’t need to be warned :).

 May be this is an insight now, may be this is something to do for ALL newly 
 introduced TLDs, set up the resolution for a month with NXDOMAIN and then 
 analyze the logs and see if it could be an issue.

You might want to look at 
https://www.jasadvisors.com/namespace-expansion-i.pdf. Interestingly, .prod had 
only 146 (filtered) unique SLDs in the DITL data. 

This was discussed in the last year or so of ‘discussions’ related to name 
collision. Trivial to game, difficulties finding the actual source, 
difficulties in establishing what could be an issue vs. a false positive, etc.

The behavior of returning 127.0.53.53 is specifically intended to interrupt 
normal behavior in a less damaging way (at least compared to the alternative 
interruption approaches) so people notice and can go and fix things. See 
https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf
 for a longer explanation of the current approach used to deal with name 
collision.

Regards,
-drc
(ICANN CTO, but speaking only for myself)



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] Validating or not validating (ICANN controlled interruption)

[David Conrad]

Rubens,

hatless
But isn’t it better we shake these sorts of things out now?
/hatless

Regards,
-drc

On Sep 3, 2014, at 5:41 AM, Rubens Kuhl rube...@nic.br wrote:

 
 What I can tell you is that registries and applicants suggested ICANN to not 
 require DNSSEC-signign of wildcard controlled interruption due to likely 
 differences in resolver behaviour, including some known bugs. 
 
 Rubens
 
 On Sep 3, 2014, at 4:00 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
 
 BIND validates A nimportequoi.otsuka and yields an answer with AD bit
 set.
 
 Unbound gives back the answer but without the AD bit.
 
 [Try it yourself, 'dig @unbound.odvr.dns-oarc.net A
 nimportequoi.otsuka' and 'dig @bind.odvr.dns-oarc.net A nimportequoi.otsuka']
 
 In some cases (difficult to pinpoint, depending on the resolver's
 state), both BIND and Unbound return SERVFAIL.
 
 Who's right?
 
 PS: dnsviz claims that names like eb2dz5xm4s.otsuka are secure,
 non-existent while they elicit an answer.
 
 
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



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] First new gTLD using ICANN's Name Collision Occurrence Management Framework

[David Conrad]

Hi,

On Aug 28, 2014, at 11:59 PM, Patrik Fältström p...@frobbit.se wrote:
 On 29 aug 2014, at 07:04, SM s...@resistor.net wrote:
 At 14:13 28-08-2014, Rod Rasmussen wrote:
 I note that these documents speak to many of the issues being exposed here 
 (and yes, full disclosure, I wrote a small portion of the text/reviewed 
 them):
 
 Was there a response to those issues?

For details of ICANN’s efforts related to name collisions, please see 
https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

 Some, but also referrals to issues still under a disclosure policy not made 
 public.

For clarification:

During the analysis associated with name collision, JAS Global Advisors 
discovered a vulnerability. In keeping with ICANN’s “Coordinated Vulnerability 
Disclosure Reporting” policy, JAS notified ICANN and the affected vendor(s). 
The exact nature of the vulnerability has not yet been released as the 
vendor(s) work to mitigate the potential impact of the vulnerability.

Full disclosure: I was on contract to JAS during their name collision efforts 
and have since joined ICANN.

Regards,
-drc



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] about the underline in hostname

[David Conrad]

On May 29, 2014, at 9:54 AM, Phillip Hallam-Baker ph...@hallambaker.com wrote:
 This implies that ICANN can't delegate an all-numeric TLD, and in fact, 
 ICANN (in section 2.2.1.3.2, sub-section 1.2.1 of the Applicant's Guide 
 Book) states:
 I am rather worried when specifications rely on what is implied rather than 
 what is stated.

Well, what was stated (in RFC 1591, section 2) was:

It is extremely unlikely that any other TLDs will be created.

We seem to have gotten over that.  More seriously, 1123 seems pretty clear to 
me, even if it is indirect: a valid hostname must have as its highest-level 
component an (all) alphabetic label. ICANN has followed that restriction in its 
acceptance of applications for new top-level domains.

I would agree that it would be preferable if there was a single document in 
which a hostname and the distinction between a hostname and a  domain name were 
clearly and unambiguously spelled out. However, there hasn't been enough energy 
for anyone to actually do this in the past, so we're sort of stuck with what 
we've got.

Regards,
-drc



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] most of root NS and com's NS fail from here

[David Conrad]

Emmanuel,

On Apr 29, 2014, at 3:05 AM, Emmanuel Thierry m...@sekil.fr wrote:
 If i'm not mistaken, the Chinese filtering is performed on a per-service 
 basis.

The (presumably UDP) based traceroute appears to get stuck just after entering 
the DREN, not at the Chinese border... 

Regards,
-drc



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] Uptick in number of domains losing delegation recently

[David Conrad]

Dave,

On Apr 22, 2014, at 9:57 PM, Dave Warren da...@hireahit.com wrote:
 On Apr 22, 2014, at 8:45 PM, Jothan Frakes jot...@gmail.com wrote:
 Actually I am all about making sure contact info is correct and trimming 
 away perp abuses.
 My understanding is that the toolbox to do this is somewhat limited.  What 
 other mechanisms than domain suspension would you propose?
 
 One thought would be to defer the suspension until the domain's renewal date, 
 since users will tend to expect their domain goes down if they don't take 
 some action at this time. Since the users are contacting us and anticipating 
 interaction, it's a good time ask for updated information (and verify it)

So, there can be inaccurate/junk registration info for up to a year (does 
anyone offer less than a year?) with no way to remedy?

What's the point in collecting the data again?

Regards,
-drc



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] Uptick in number of domains losing delegation recently

[David Conrad]

Jothan,

On Apr 22, 2014, at 11:17 PM, Jothan Frakes jot...@gmail.com wrote:
 David I think the desired outcome is honorable and important, but the 
 mechanism needs to be thought out a bit so it doesn't crush the innocent in 
 pursuit of the guilty.

My understanding that the RAA requirements have been under discussion for quite 
some time. I'm surprised there is a perception that the mechanism for registry 
accuracy is now considered to be not well thought out.

 Suspension certainly gets attention from the registrant, but for a lot of the 
 existing domains have been auto-renew / set and forget for more than a couple 
 decades in a lot of cases.  Update a contact on those where the admin doesn't 
 respond, like is exampled in the article, and have your domain deactivated.

Right, but isn't the point of the contact information to be able to actually 
contact the party responsible for the domain in the event of abuse or ill-use?  
If the admin has changed and the contact information hasn't been updated, 
doesn't that make the registration database entry useless?

 I don't have a great solution in mind, other than perhaps as other group 
 wisdom would unfold from the community suggestions that have been made around 
 the validation at renewal on existing names, so at least they are not swept 
 into the same wood chipper designed to mulch newly created domains that may 
 have bad contact info.  

Reports of abuse only apply to newly created domains?

 That seems patently reasonable because they are potentially separate issues, 
 or if they are not, the solution space could be separated to that it is 
 less likely to take down existing websites that are legitimate.

I guess I'm confused as to the point of the Whois database...

Regards,
-drc




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] Uptick in number of domains losing delegation recently

[David Conrad]

Jothan,

On Apr 22, 2014, at 8:45 PM, Jothan Frakes jot...@gmail.com wrote:
 Actually I am all about making sure contact info is correct and trimming away 
 perp abuses.

My understanding is that the toolbox to do this is somewhat limited.  What 
other mechanisms than domain suspension would you propose?

Regards,
-drc



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

[dns-operations] Fwd: [perpass] A reminder, the Network is the Enemy...

[David Conrad]

Hi,

I'm taking the liberty of forwarding the following off the IETF perpass list as 
Nicholas' analysis matches my own intuition. Stephane Bortzmeyer asked on the 
same list:

 Very convincing reasoning. But I would feel better if it were actually
 tested in a lab with common resolvers. Any volunteer here?

I figure this list is a better place for volunteers for this sort of thing than 
perpass. So, anyone volunteering? :)

Regards,
-drc

Begin forwarded message:
 From: Nicholas Weaver nwea...@icsi.berkeley.edu
 Subject: Re: [perpass] A reminder, the Network is the Enemy...
 Date: December 2, 2013 at 8:56:26 AM PST
 To: Stephane Bortzmeyer bortzme...@nic.fr
 Cc: perpass perp...@ietf.org, Nicholas Weaver nwea...@icsi.berkeley.edu
 
 On Nov 27, 2013, at 7:05 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
 
 On Wed, Nov 20, 2013 at 12:42:53PM -0800,
 Nicholas Weaver nwea...@icsi.berkeley.edu wrote a message of 70 lines 
 which said:
 
 http://www.wired.com/opinion/2013/11/this-is-how-the-internet-backbone-has-been-turned-into-a-weapon/
 
 You mention DNSSEC twice, as a solution against some man-on-the-side
 attacks (injecting false DNS answers).
 
 The Schneier paper
 https://www.schneier.com/blog/archives/2013/10/how_the_nsa_att.html
 about QUANTUM mentions packet injection but not the DNS. We don't know
 if the NSA does DNS poisoning (but we may assume they - and other
 actors - do it).
 
 We can bet they do:  Its the easiest way (and just about the only way) to 
 privilege escalate a man on the side to a MITM, which is needed to use things 
 like a fake cert for SSL decryption.  
 
 A full MITM on a backbone link is a very dangerous thing to install, because 
 failures get noticed and its also far easier to get the friendly ISP to 
 install something that is just a tap, while installing a full MITM closer 
 to the victim may often be very difficult or downright impossible to do 
 without getting caught.
 
 However, if the attacker is the NSA, we have to take into account the
 possibility that they can sign data with the root's private key, which
 is under US management. Therefore, is DNSSEC still useful?
 
 Actually spoofing DNSSEC replies even with knowledge of the root key is going 
 to be difficult...
 
 Simply put, the attacker is going to need to create a fake path of trust or 
 an insecure delegation.  So, eg, assuming the target is:
 
 target.example.com
 
 and the attacker only has a copy of the root key.
 
 
 They are going to have to create a fake NSEC for .com, wait for a query for 
 .com to go to the root (to enable the fake NSEC record), and then wait until 
 the victim queries for victim.example.com or the victim does another query 
 back to the root, which makes getting caught far more likely.  
 
 And since .com and other TLDs support DNSSEC, you could hardcode there must 
 be DS record from . for these TLDs, this wouldn't work.  (An alternative 
 would be a fake DS, and then fake EVERY reply from .com with new RRSIGs...  
 And for that, you have a timing problem because your injector may not know 
 the answer TO inject!)
 
 And at the same time, its still packet injection (and therefore still 
 detectable, see http://conferences.npl.co.uk/satin/papers/satin2012-Duan.pdf‎ 
 ).
 
 
 So although its possible that the root ZSK gets compromised by the NSA, its 
 something that I'd not only consider rather unlikely, but something that even 
 if they did, it would be something they wouldn't want to use, especially now 
 that packet injection IS on everybody's radar and if they got caught, the 
 own-goal damage against US interests (so much of DNSSEC on the authority side 
 has been driven by DHS) would be huge.
 
 
 --
 Nicholas Weaver  it is a tale, told by an idiot,
 nwea...@icsi.berkeley.edufull of sound and fury,
 510-666-2903 .signifying nothing
 PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc



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] chrome's 10 character QNAMEs to detect NXDOMAIN rewriting

[David Conrad]

Ed,

On Nov 27, 2013, at 6:00 AM, Edward Lewis ed.le...@neustar.biz wrote:
 My excuse is - operators limit the effort expended in fighting entropy.  
 Imagine an average operations environment operating as most environments go.
 ...
 Eventually one day something breaks and then...  ...include here the 
 only one who can fix it has left.

I suspect this argument applies _far_ more to configuring/operating DNSSEC than 
it does to slaving the root zone, particularly when you take into account the 
rolling of the root key. For one thing, consider the time intervals between 
change events that might cause problems.

 I'd argue that the resolver admin is also incentivized to do a good or better 
 job too.  Joe's right in general,

Actually, he isn't... :)

Slaving a zone is not (or perhaps should not be, despite BIND configuration 
language) rocket science. Hand wringing about poor resolver operators being 
unable to master the complexities feels like the don't look behind the 
curtain scene of the Wizard of Oz.

The root represents one of the few single points of failure on the Internet. 
Continued reliance on that single point of failure, particularly in the days of 
multi-hundred of gigabit DoS attack at the flip of a switch potential, is ... 
questionable. Given the lack of ability for the Internet operations community 
to effectively deploy BCP 38, I anticipate this situation to only get worse.  
Arguments along the lines of but anycast! don't really help when the root 
instances you get routed to have fallen over due to the latest DoS attack. Yes, 
the system as a whole can still be said to be responsive, but you're SOL.  

I would agree that existing resolver technology makes it more challenging than 
it should be to decentralize the root. Fixing that is long overdue IMHO.

Regards,
-drc




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] Issue with www.bing.com resolution in Time Warner

[David Conrad]

On Nov 18, 2013, at 1:54 PM, Ashley Flavel ashle...@microsoft.com wrote:
 I’ve had reports that users in TWC are getting incorrect IPs back from their 
 local resolvers.  Both of the IPs below are proxy servers and sometimes 
 redirect the user to dnsrsearch.cominstead of bing.com.

Perhaps relevantly (or perhaps not):

% whois -h whois.markmonitor.com msedge.net
Server is too busy, try again later!

(connections to http://whois.markmonitor.com also time out)

Markmonitor getting DoS'd?

Regards,
-drc



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

[David Conrad]

On Nov 14, 2013, at 1:41 PM, Joseph S D Yao j...@tux.org wrote:
 When it will get interesting is when there are 5000+ TLDs, 2500+ of which 
 have been abandoned because the entrepreneurs who proposed them decided it 
 wasn't fun and abandoned them, leaving lame servers galore.  Is there any 
 mechanism in place to remove lame TLDs?

http://www.icann.org/en/resources/registries/ebero

Regards,
-drc



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

[David Conrad]

On Nov 5, 2013, at 8:52 AM, Matthäus Wander matthaeus.wan...@uni-due.de wrote:
 The operator of xn--80asehdb. and xn--80aswg. is using a custom-made
 name server according to their version.bind.

I don't know if I'd call http://www.irondns.net custom.

Regards,
-drc



smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[David Conrad]

On Oct 20, 2013, at 2:16 PM, Vernon Schryver v...@rhyolite.com wrote:
 Should the people working on DNS implementations prioritize making
 their DNSSEC code more robust and easier to use above or below
 addressing your issues?

I'd say below.

Resolver operators (hopefully) want to protect their caches.  DNSSEC will do 
that, but only if people are signing their zones. There are lots of external 
parties (e.g., registries, registrars, software developers, resolver operators, 
etc) to get DNSSEC deployed and there remains very little incentive for anyone 
to sign their zones, regardless of how robust and easy it might be made.

The alternative would be to disregard current and future cache poisoning 
attacks.  Pragmatically speaking, I personally think it highly questionable to 
ignore cache poisoning vulnerabilities because something which isn't yet 
deployed to 10% of the Internet will fix it.

This would be a bit like saying don't deploy RRL because BCP38 is the correct 
answer to the problem.

 Your work would be valuable if it helped pressure people to get busy on 
 DNSSEC.  

Seems to me the work they have done is valuable, regardless of DNSSEC.

Regards,
-drc



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] ALERT: .QA CCTLD in wrong hands currently

[David Conrad]

On Oct 19, 2013, at 5:36 AM, Kauto Huopio kauto.huo...@ficora.fi wrote:
 It seems that .QA TLD could be currenty in wrong hands:
 https://twitter.com/Official_SEA16/status/391339315562688513

The TLD appears to be fine (that is, it hasn't been redelegated).  Looks like 
the registry might be having issues however -- the domain referenced on the 
IANA page for registration information (domains.qa) does not resolve (NXDOMAIN).

% whois -h whois.registry.qa domains.qa
Domain Name: domains.qa
Last Modified:   19-Oct-2013 00:02:13 UTC
Registrar Name:  Qatar Domains Registry
Status:  pendingDelete (Client requested policy delete)

Registrant Contact ID:   QT50010
Registrant Contact Name: Mohamed El-Bashir - Qatar Domains Registry
Registrant Contact Email:Visit www.domains.qa

Tech Contact ID: QT50010
Tech Contact Name:   Mohamed El-Bashir - Qatar Domains Registry
Tech Contact Email:  Visit www.domains.qa

Name Server: ans0.qaregistry.qa
Name Server IP:  178.23.18.5
Name Server: ans1.qaregistry.qa
Name Server IP:  178.23.18.6
Name Server: ns1.registry.qa
Name Server IP:  178.23.16.104
Name Server: ns2.registry.qa
Name Server IP:  178.23.17.104

Regards,
-drc



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] Should medium-sized companies run their own recursive resolver?

[David Conrad]

Florian,

On Oct 15, 2013, at 10:24 PM, Florian Weimer f...@deneb.enyo.de wrote:
 There's a tendency to selectively block DNS traffic, which can be a
 pain to debug.  

True. Hate that. A lot.

 Various network issues might only affect DNS recursor traffic.

Given the information provided in the scenario, I feel it safe to assume a 
company of 100 with 2 full-time IT staff would have a clear channel for 
Internet traffic.  If not, I would agree with your caveat (and question the 
company's sanity).

Regards,
-drc




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] Should medium-sized companies run their own recursive resolver?

[David Conrad]

On Oct 14, 2013, at 7:08 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
 A fictitious 100-person company has an IT staff of 2 who have average IT 
 talents. They run some local servers, and they have adequate connectivity for 
 the company's offices through an average large ISP.
 
 Should that company run its own recursive resolver for its employees, or 
 should it continue to rely on its ISP?

Given the information provided (and interpolating): they should run their own 
recursive servers.

Running a recursive server is (should be) far easier than running the vast 
majority of other local servers.  If it isn't, they're using the wrong 
recursive server.  With the exception of root key rollover, running a recursive 
server is a fire-and-forget type service (modulo some initial configuration to 
avoid being an open resolver).

Given the role DNS has, if they do not run their own resolver they are 
investing a vast amount of trust both in the resolver operator and the wire 
(air, in the case of wireless) between their stubs and their resolver.  That 
trust is constantly being violated through crap like redirection. Further, in a 
DNSSEC environment, validation is pointless if the channel between the resolver 
and the stub is subject to attack.  Until that channel can be protected, it is 
far safer to run local resolvers if you are interested in security.

Regards,
-drc
 




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

[David Conrad]

On Aug 22, 2013, at 3:19 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
 On Aug 22, 2013, at 2:47 PM, David Conrad d...@virtualized.org wrote:
 A resolver operator deploying an NTA is making an assertion that data behind 
 a name is safe despite protocol indications that is may not be.
 
 Where is that stated? I ask, because it would seem that a better description 
 would be that they are asserting that the data behind a name is unprotected 
 by DNSSSEC.

Apologies for using shorthand.  The term 'safe' in my comment meant that it was 
what was intended by the zone editor.

Regards,
-drc



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

[David Conrad]

On Aug 22, 2013, at 3:25 PM, Paul Vixie p...@redbarn.org wrote:
 A resolver operator deploying an NTA is making an assertion that data 
 behind a name is safe despite protocol indications that is may not be.
 Where is that stated? I ask, because it would seem that a better description 
 would be that they are asserting that the data behind a name is unprotected 
 by DNSSSEC.
 agreed, and that's why, over and above the absurd engineering economics 
 behind it, i don't like NTA. if my signatures don't work because i've been 
 attacked (for example, one of my name servers has been compromised), the last 
 thing i'd want is comcast telling their customers that the data they're 
 getting from my compromised name server is ok to consume because it's 
 unsigned.

Exactly so.  However pragmatically speaking if someone (say NASA perhaps?) 
screws up signing their zone, it isn't the zone-signing-screwer-upper that gets 
the phone calls, it is the eyeball networks that are doing the validation.  
Without NTA, the eyeball network operators have a choice, eat the cost of those 
calls or turn off validation _for ALL signed zones until the 
zone-signing-screwer-upper fixes their problem_.

I gather you believe eating the cost is the right answer.  

 madness test: would we have bothered with DNSSEC at all, back in the day, if 
 NTA had been known as a definite requirement?

Sure.

Regards,
-drc



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

[David Conrad]

On Aug 22, 2013, at 5:13 PM, Paul Vixie p...@redbarn.org wrote:
 Randy Bush wrote:
  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.  ...
 
 +1. we're currently debating placement of first mover advantage. today
 if you sign incorrectly you lose. with NTA at scale, if you sign
 incorrectly you won't lose.

Sure you will.

You screw up signing and you instantly lose.

NTA allows other folks to not lose with you if they decide the pain of your 
screwing up to them is sufficiently high to justify manual intervention.

Not everyone will make the same value judgement and they all won't make it at 
the same time.

Regards,
-drc



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

[David Conrad]

On Aug 23, 2013, at 9:02 AM, Vernon Schryver v...@rhyolite.com wrote:
 Eyeball networks would be best served by turning off DNSSEC.  

I believe this is what they're trying to avoid.

 Let's be honest and admit that talk about NTA today and tommorow (as
 opposed to last year) is really a statement of regret about DNSSEC and
 a demand that DNSSEC just go away.  

If this were the case, it is much easier to just put 

dnssec-validation no;

in configurations and let others get the arrows in the back.

 }  On the contrary, NTA is a new tool for deliberately introducing new
 }  faults in the data you give your DNS clients.
 } True.  This is why I suspect corporate types will have hesitancy to use =
 } NTAs and wish to remove them as soon as possible.
 On the contrary, given minimal cover such as an RFC,

RFCs provide no cover.  If a validator operator sets an NTA and their customers 
are compromised by an attack that would have otherwise been prevented by 
DNSSEC, I strongly suspect the validator operator will have set themselves up 
for an interesting set of meetings with their customers' lawyers.

Regards,
-drc



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

[David Conrad]

On Aug 23, 2013, at 9:19 AM, Paul Vixie p...@redbarn.org wrote:
 if nasa.gov had screwed up its delegation or had allowed its public secondary 
 servers to expire the zone due to primary unreachability, i do not think the 
 phone at comcast would have rung less, but i also don't think that comcast 
 would have fixed nasa's error in local policy.

That's because every resolver operator would have been affected, not just 
Comcast, so the screams that Comcast (alone) was censoring NASA for conspiracy 
theory du jour) would have been trivially dismissed.

If you want a reminder of the stupidity Comcast (alone AFAIK) experienced, see 
http://nasawatch.com/archives/2012/01/comcast-blocks.html

 we're only talking about this because DNSSEC is new.

Of course. NTA is a mechanism that allows folks who want to do the right thing 
to do so without incurring costs that folks who aren't interested in doing the 
right thing won't incur.  As more folks start validating, the playing field 
levels out and the need for NTA decreases.

Regards,
-drc



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

[David Conrad]

Vernon,

On Aug 23, 2013, at 11:10 AM, Vernon Schryver v...@rhyolite.com wrote:
 They would be better served by `rndc validation off X hours` with 
 a limit on the X hours of 24 than any sort of NTA hook.

So, because one zone messes up signing, instead of opening up that one zone to 
spoofing attack you think it is better the resolver operator opens up all zones 
to spoofing attack?

This seems wrong to me.

 If you don't let them to use `rndc validation off X hours`, most will
 use `rndc nta gov` because their users will be shouting about governement
 web site problems and they won't have the time, inclination, or
 permission to discover that it's only the apod.nasa.gov.

I'd suggest that in the BCP/RFC/whatever, in addition to recommending that NTAs 
be time capped and not written to permanent storage, it should also recommend 
NTAs be written as specifically as possible.  (Should be obvious, but doesn't 
hurt to reiterate I suppose).

Regards,
-drc



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

[David Conrad]

Doug,

On Aug 22, 2013, at 12:06 PM, 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.

A resolver operator deploying an NTA is making an assertion that data behind a 
name is safe despite protocol indications that is may not be.

I would think corporate lawyers might quiver with ... righteous indignation in 
situations like this. As such, I have some skepticism that corporate resolver 
operators will be allowed to leave NTAs up for much longer than necessary.

But maybe I overestimate lawyer nervousness.

Regards,
-drc

___
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] Geoff Huston on DNS-over-TCP-only study.

[David Conrad]

Geoff,

I personally think this is really interesting work. A question about 
methodology:

On Aug 21, 2013, at 4:36 PM, Geoff Huston g...@apnic.net wrote:
 - Our experiment used a modified DNS server that truncated all UDP at 512 
 bytes, and over 10 days we enlisted some 2 million end clients to perform a 
 set of tests by using online ads. The ad used a very wide geographic and 
 network variety, so there is good grounds to see this set as a reasonable 
 representative sample of the internet's end user population.

If I recall correctly, you're using a Flash thingie to do this.  Is that right?

If so, have you looked at how platforms that don't do Flash (notably, Apple 
IOS-based devices by default) behave (at least in a lab)?  I know those devices 
had an ... interesting impact on the IANA servers providing the root trust 
anchor... 

Thanks,
-drc



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

[David Conrad]

On Apr 1, 2013, at 2:40 PM, Lutz Donnerhacke l...@iks-jena.de wrote:
 * Stephane Bortzmeyer wrote:
 Congratulations: you've solved the easy problem, the technical one,
 and left open the really hard one, finding who has the legitimacy to
 hire/fire root name server operators :-)
 
 Oh, this problem was solved years ago. ICANN was founded to bind all efforts
 of gouvernments, private people, and orgranisations in a burocracy impossible 
 to
 understand nor to survice, with the simple goal to keep all those from
 affecting the real work of the real root server operators. The funny part
 is, that the root server operators (which does not exist as an organization)
 appears to be an organisation within ICANN. But this is only just another
 level of indirection and confusion. ICANN is very successful in doing their
 (hidden) primary goal: Let the operators work.

I love April 1.

:)

Regards,
-drc


___
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] Another whitepaper on DDOS

[David Conrad]

On Feb 22, 2013, at 2:58 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
 they keep pretending that the DNS attack in Brazil was cache poisoning, while 
 it has been widely documented for a long time 
 http://www.securelist.com/en/blog/208193852/The_tale_of_one_thousand_and_one_DSL_modems.

I keep running into the Brazil had an attack that could've been prevented by 
DNSSEC too.  Gets boring after a while.

Has there been any documented attack that would have been prevented by DNSSEC 
that one can point to?

Thanks,
-drc

___
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] Another whitepaper on DDOS

[David Conrad]

Warren,

On Feb 22, 2013, at 7:42 AM, Warren Kumari war...@kumari.net wrote:
 http://dnssec-deployment.org/pipermail/dnssec-deployment/2012-July/006003.html

Thanks!  Missed that message somehow.

BIND 4.8.anything in 2010? I weep for humanity.

Regards,
-drc


___
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] Monday rant againt the uses of the Public Suffix List

[David Conrad]

On Jan 28, 2013, at 4:31 AM, Franck Martin fmar...@linkedin.com wrote:
 There are plenty errors in the public suffix list for Pacific Island
 countries. I guess the operators of the ccTLDs there, never heard of the
 PSL.

Should they have?

Regards,
-drc

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

[David Conrad]

Hi,

On Jan 21, 2013, at 1:07 AM, Jaap Akkerhuis j...@nlnetlabs.nl wrote:
 ISO-3166-1 table which shows valid ccTLDs in green:
 http://www.iso.org/iso/home/standards/country_codes/iso-3166-1_decoding_table.htm
 Yellow (exceptionally reserved) code elements used for ccTLDs
 are also considered 'valid'.
 Just some of them.

I was speaking from IANA/ICANN's perspective in the sense that for a 2-letter 
TLD to be delegated, the first condition that must be met is that the 2-letter 
ISO-3166 code point must be allocated by ISO-3166/MA. At this point in time, 
IANA/ICANN considers code points marked in green and in yellow in the decoding 
table as 'allocated'.  This, of course, is not the only condition for a 
2-letter TLD to be delegated out of a 2-letter ISO-3166 code point.

Regards,
-drc

___
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] What's a suffix?

[David Conrad]

On Jan 21, 2013, at 1:00 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote:

 On Mon, Jan 21, 2013 at 09:25:03AM +0100,
 Stephane Bortzmeyer bortzme...@nic.fr wrote 
 a message of 21 lines which said:
 
 A suffix is any string ending a domain name. 
 
 A reader even more nazi than I am suggested a definition closer to the
 DNS semantics:
 
 A suffix is any sequence of labels ending a domain name.


The term 'suffix' isn't really the issue -- it is the subset of 'suffixes' 
deemed 'public'.

Quoting RFC 6265:

  NOTE: A public suffix is a domain that is controlled by a
  public registry, such as com, co.uk, and pvt.k12.wy.us.
  This step is essential for preventing attacker.com from
  disrupting the integrity of example.com by setting a cookie
  with a Domain attribute of com.  Unfortunately, the set of
  public suffixes (also known as registry controlled domains)
  changes over time.  If feasible, user agents SHOULD use an
  up-to-date public suffix list, such as the one maintained by
  the Mozilla project at http://publicsuffix.org/.

I have to admit this definition has confused me for some time (e.g., what does 
public registry mean in this context?), but ignoring this, I find it odd that 
a registry as important to Internet operations as the public suffix list is 
not maintained by IANA. The fact that .CW was not automatically added to the 
list increases the oddness factor for me.

Regards,
-drc

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

[David Conrad]

A nit:

On Jan 20, 2013, at 4:35 PM, Doug Barton do...@dougbarton.us wrote:
 ISO-3166-1 table which shows valid ccTLDs in green:
 http://www.iso.org/iso/home/standards/country_codes/iso-3166-1_decoding_table.htm

Yellow (exceptionally reserved) code elements used for ccTLDs are also 
considered 'valid'.

 This is an uphill battle which is only going to get steeper when the next 
 round of new TLDs is released.

It might eventually improve as folks who make broken assumptions keep getting 
whined at.  And world peace might break out too.

Regards,
-drc

___
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] responding to spoofed ANY queries

[David Conrad]

Vernon,

On Jan 12, 2013, at 3:11 PM, Vernon Schryver v...@rhyolite.com wrote:
 We just need to admit that self-regulation by the industry has failed
 to address this matter adequately.
 That statement is wrong and irritating.

While I might agree it is irritating, it is so because it is true. Industry 
self-regulation has indeed failed.

 The tool is too tempting and potentially effective for too many government
 projects ranging from national hostilities to operations by law
 enforcement against criminals to expect governments to entirely
 support BCP38 or even allow its complete deployment.  This is like
 the prospects for governments and politicians limiting their own spam.

A possibility but I've not yet reached that level of cynicism. I suspect that 
when there is a sufficient demonstration of the effectiveness of source address 
spoofing against government or infrastructure targets, laws will suddenly 
appear that require ISPs to take steps to ensure the traffic they source has 
appropriate source addresses, just as laws appeared to allow lawful intercept 
of traffic.

I personally believe it is only a matter of time.

 IP source address forging is like spam.

Not really.  Spam doesn't affect anything except email.  Source address 
spoofing can affect _anything_ on the Internet.

Regards,
-drc


___
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] responding to spoofed ANY queries

[David Conrad]

Paul,

On Jan 12, 2013, at 4:51 PM, Paul Vixie p...@redbarn.org wrote:
 in that having only spoofing and not amplification would mean there would be 
 a smaller problem, it's less true.

In a world of million-zombie botnets, amplification is merely icing on the cake.

 the internet is extra-legal because it is  extra-national. 


While I would agree that national laws do not apply outside of national 
boundaries (Predator drones not withstanding), pragmatically speaking, in the 
face of a massive infrastructure outage caused by an attack facilitated by 
spoofed addresses, I suspect the distinction you are making isn't going to be 
made by lawmakers.  

More to the point, I suspect such nationally-based laws would actually have a 
positive impact: it would force spoofing to move from domestic circuits to 
international circuits where the situation is slightly different.

However, I don't think this is really all that related to dns-operations... 

Regards,
-drc
 
___
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] responding to spoofed ANY queries

[David Conrad]

Vernon,

On Jan 12, 2013, at 5:55 PM, Vernon Schryver v...@rhyolite.com wrote:
 Laws requiring that all routers support one or more of the BCP 38
 mechanisms sound rather late and redundant and wouldn't do much to
 make ISPs turn them on,

Do you really believe that in the aftermath of a successful spoofing-based 
infrastructure attack in which (say) people die that politicians and lawmakers 
would care about the fact that the law was late or redundant?

I suspect you're misunderstanding what I'm saying: while I might believe 
nationally-based legislation may (possibly) have a positive impact in that it 
might reduce domestic spoofing and change the dynamics (forcing ISPs and 
hosting providers to wipe their own butts), whether or not a law is effective 
is beside the point.  In the face of a high profile event which demonstrates 
industry self-regulation has utterly failed, politicians will feel a need to 
do something and the only thing they can do is pass laws.  Yes, it is yet 
another form of security theatre, but when has that stopped anyone?

However, I'm pretty sure this isn't appropriate fodder for dns-operations...

Regards,
-drc

___
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] ATT DNS Cache Poisoning?

[David Conrad]

Bert,

On Oct 27, 2012, at 10:55 PM, bert hubert bert.hub...@netherlabs.nl wrote:
 Thus continuing the trend that all purported cache poisonings observed have 
 been registry hacks.

Looks that way, although it looks like this wasn't really a registry hack but 
rather what happens when a domain name expires these days. With that said, I 
still believe the most critical vulnerability in the DNS is in the security of 
the registrars.

 It appears that source port randomization works. 

Was there ever any doubt?  The question wasn't (isn't?) whether source port 
randomization would work, it was how long it would work.  Source port 
randomization simply protects the communication channel, not the data -- it 
kicks the can down the road (yet again). DNSSEC protects the data making the 
communication channel irrelevant. IMHO, it is a better long-term solution 
(folks who know my opinion on DNSSEC may now require smelling salts).

 Probably the only vulnerable servers are those behind NAT that derandomizes
 the source port. But important servers are unlikely to suffer from network
 address translation.

Heh.  Let me introduce you to CGN... :-)

Regards,
-drc

___
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] ATT DNS Cache Poisoning?

[David Conrad]

Robert,

On Oct 27, 2012, at 1:37 PM, Robert Edmonds edmo...@isc.org wrote:
 i don't think it's cache poisoning.  note that there are two out-of-zone
 nameservers for ben.edu:
...
 and that bobbroadband.com was updated recently,

Good catch! Makes sense.  I checked the history on ben.edu but didn't think to 
check the rest of the delegation tree. D'oh.

Regards,
-drc

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

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

[David Conrad]

Vernon,

On Oct 3, 2012, at 6:38 AM, Vernon Schryver v...@rhyolite.com wrote:
 Any popular scheme that works around DNS, HTTP, ssh, etc.
 man-in-the-middle attacks that become popular will be blocked,
 proxied, or hijacked unless most users normally use tools that
 detect and refuse to work with men in the middle.

You're assuming the MITM attacks are intentional. My impression is that the 
majority of the issues in getting EDNS0-requiring protocols to work are due to 
ignorance, e.g., valid DNS responses are always UDP512bytes or valid DNS types 
are {A,MX,SOA,NS,PTR,TXT}. If this is true, than egregious hack workarounds 
like using HTTP/S as a transport will solve most of the problem (not that I 
think this is the best solution).

Regards,
-drc

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

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

[David Conrad]

Vernon,

On Oct 3, 2012, at 8:57 AM, Vernon Schryver v...@rhyolite.com wrote:
 You're assuming the MITM attacks are intentional. 
 No, I assume only either that the men in the middle will back off if
 they irritate enough users or that they can be detected.

They can only back off if they're aware they are doing it.

 (Never mind corrupt DNS registrars or registries attacking DNSSEC.)

Not corrupt, just inept. Which is, of course, a much more significant threat 
today than anything DNSSEC can protect against, but that's a rant for a 
different thread.

 Breaking DNS is not accidental, not even with NAT.

Sure it is. CPE/firewall vendors have a long history of implementing the 
absolute minimum they can get away with that still sort of works (which, from a 
business perspective). In the past, DNS UDP512 (for CPE) and limited types 
(for firewalls) sort of worked.  Then those evil greedy DNSEXT bastards went 
and modified the protocol, thereby breaking simplistic implementation 
assumptions. However, there is a lot of CPE/firewalls out there that needs to 
be upgraded.  Hence suggestions like Paul's of egregious hacks like 
DNS/TLS/HTTP.

 On the other hand, if many user computers have validating stubs that
 compute SERVFAIL for broken DNSSEC and so make gethostbyname() in
 applications fail, then many users will yell at hotel concierges for
 $15/day WiFi that doesn't work and use LTE instead of paying $15/day.
 Many hotels would change and allow EDNS0 after the sign-on.  Employers
 would either do the same or point to conditions of employement.  State
 actors would either do the same or send whiners to gulags.

I want to live in your world.  In my world, the vast majority of users would 
simply turn off the features that caused their laptops/phones/etc. to not work 
and would rarely (if ever) complain to their service provider (even if they 
knew what to complain about).

Regards,
-drc

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

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

[David Conrad]

On Oct 2, 2012, at 12:54 PM, Paul Vixie p...@redbarn.org wrote:
 if ietf hadn't declared the dns protocol finished, and were not even now
 working to close up the dnsext working group, i'd propose that we
 develop a standard for carrying edns over tcp/80 and/or tcp/443, which
 is for most mobile users what the internet consists of.

What's stopping you from proposing a BOF at the next IETF (with the intent of 
spinning up a new WG if the BOF suggests that would be a good idea)?  I thought 
killing off DNSEXT was to move away from the omnibus working group model and 
back to the topic-of-interest WG model? Did the IETF Illuminati declare a 
moratorium on all new DNS work when I wasn't looking?

Regards,
-drc

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

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

[David Conrad]

On Oct 2, 2012, at 5:49 PM, Vernon Schryver v...@rhyolite.com wrote:
 The only reasonable solution is to give stub resolvers some of the
 features of recursive resolvers including DNSSEC validation and caching
 to make the costs of DNSSEC tolerable.

Why not get rid of stub resolvers completely and simply use recursive resolvers?

Regards,
-drc

___
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] dotless domains

[David Conrad]

Florian,

On Sep 24, 2012, at 12:07 AM, Florian Weimer f...@deneb.enyo.de wrote:
 * Paul Vixie:
 those are country code top level domains. cctld's enjoy national sovereignty
 Uhm, most of them are companies, and not subjects of international law.  Few 
 of them, however, have entered binding contracts with ICANN.


Because ccTLD administration is considered an issue of national sovereignty, 
ICANN has no license to insert itself between the government and the contractor 
the government chooses to operate the ccTLD.

Regards,
-drc

___
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] dotless domains

[David Conrad]

Stephane,

On Sep 21, 2012, at 1:40 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
  I'm not particularly against the idea of using dotless
  domains, but we know who's going to live with the support
  questions when users start complaining. Paul's piece on
  CircleID sums it up nicely. Caveat emptor.
 
 For the consultation mentioned in Paul Vixie's original message, the
 issue is not whether one-label domains are a good idea or not but
 whether ICANN has really nothing better to do than to add yet another
 stupid regulation in an already very thick book.

According to its bylaws, ICANN's responsibility is to ensure the security and 
stability of the top level of the DNS (among other resources) at the same time 
as it is supposed to increase competition to improve service, reduce cost, 
foster innovation, blah blah blah. I'm not sure how ICANN is supposed to do 
that without 'regulations'.

The ICANN community has, through a 10+ year excruciatingly painful process, 
decided to allow for an unprecedented expansion of the root zone. Regardless of 
whether the expansion is a good idea, I personally believe that given it is 
going to occur, it is appropriate to be conservative in the degrees of freedom 
in which we can shoot ourselves in the foot. 

As documented in SAC053 (and discussed on this list), weird shit happens 
because many software developers assumed that a domain name has a dot in it. 
Given there is one root and that pretty much everybody is dependent upon it, 
you probably want to minimize the surprises that are associated with the root. 
To me, this means that you make exceptions to allow for surprises rather than 
the opposite. Over time, as software developers fix their broken code, it 
should become easier to get those exceptions for folks that care.

Regards,
-drc

___
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] Authoritative Name Server at Wikipedia

[David Conrad]

Paul Mockapetris founded Nominum? How offensive! I'm shocked to hear Wikipedia 
got something wrong.

Oh. Wait. Did you mean to highlight something else?

:-)

Regards,
-drc

On Aug 8, 2012, at 1:23 PM, Jan-Piet Mens jpmens@gmail.com wrote:
 From [1]:
 
Authoritative Name Server
 
The Authoritative Name Server (ANS) is high-end commercial
authority-only DNS server software product from Nominum, a
company founded by Paul Mockapetris, the inventor of the DNS.
ANS was designed to meet the needs of top level domain servers.
 
 [sic]. Just so you know. ;) 
 
-JP
 
 
 [1] https://en.wikipedia.org/wiki/Authoritative_Name_Server
 ___
 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] I know I'm a curmudgeon but

[David Conrad]

On Jul 9, 2012, at 9:17 AM, Edward Lewis wrote:
 At 17:53 +0200 7/9/12, Benny Pedersen wrote:
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
 2 last zerro is bad sign

Not really. Some folks like minimal-response.

 The name isn't a problem, it's dig.  

Sounds like a +no-ulabel option feature request for dig ('cause dig needs 
more options).  I'm sure ISC will be happy to take your money to implement said 
feature :-).

Regards,
-drc

___
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

[David Conrad]

On May 17, 2012, at 3:25 AM, Joe Abley wrote:
 Even ignoring folks who slave the zone now, is coordinated measurement of 
 the root system realistically possible today given the 
 business/political/philosophical environments of the root operators?
 Yes.

[citation needed]

 However, there's a difference between making the data available for public 
 scrutiny and encouraging people to make poor operational choices about what 
 to do with it.

I think the idea is that given the data exists and (arguably) slaving the root 
addresses some concerns/can improve things, it would be nice to encourage 
people to make good operational choices about it.

Regards,
-drc

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

[David Conrad]

Andrew,

On May 17, 2012, at 1:36 PM, Andrew Sullivan wrote:
 [rebuttals to suggested advantages]


I feel like this is going stuff already discussed so I won't bother going point 
by point as I suspect it would be a waste of both our time (particularly given 
your view as expressed below).

 I am claiming that there are, perhaps, best ways to do it, but that
 one shouldn't do it in the first place.  There's probably a best way
 not to get caught robbing banks, but I don't think we should publish
 manuals.  There's a best way not to get parking tickets while yet
 parking without paying, but I don't think we should publish manuals
 for that either.  This case lies somewhere between those examples.

This implies you believe slaving a root is (or should be) illegal. I would be 
surprised if you actually believed this.

It seems to me that since slaving the root is implemented today, will 
undoubtedly be implemented in the future, and that it can be argued (rightly or 
wrongly) to address some technical and non-technical issues related to root 
zone service, it would make sense to at least document the pros and cons, 
provide warnings on what to do and not do, etc.

Perhaps you would agree that there _may_ be benefits to slaving the root and 
that further study would be warranted (perhaps replicating/expanding upon the 
work David Malone did back in 2003 
(http://www.maths.tcd.ie/~dwmalone/p/rootslave03.pdf))?

Regards,
-drc

___
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

[David Conrad]

Stephane,

On May 14, 2012, at 11:14 PM, Stephane Bortzmeyer wrote:
 BTW fair and equitable is one of those unfortunate phrases that
 gets Internet governance types very excited, not always in a good
 way: eg fair and equitable distribution of IP addresses.
 
 We disagree here. Asking for fairness and equity (for IP addresses or
 root name servers) seem reasonable to me.

Asking for 'fairness and equity' is indeed reasonable. The problem is defining 
(and getting consensus on) what 'fair and equitable' actually means, 
particularly in an IGF/ITU/ICANN context... 

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

Regards,
-drc

___
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