Re: [dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack

[Phillip Hallam-Baker]

Looks like the 'downgrade attack' is actually a consequence of the fact
that support for multiple algorithms means that you end up with the
security of the weakest. So not really an 'attack' but a consequence of the
design approach not considering the downgrade issue worth addressing
because people should not be signing under multiple algorithms for very
long.

But given that, I think we are long past the time when anyone is doing
anything of the slightest value signing with SHA-1. There is no reason to
pick SHA-1 over SHA-2. You are not going to improve interop, you are much
more likely to harm it. So moving SHA-1 to MUST NOT seems like the way to
go.




On Thu, Aug 11, 2022 at 7:23 PM Viktor Dukhovni 
wrote:

> On Thu, Aug 11, 2022 at 06:41:23PM -0400, Donald Eastlake wrote:
>
> > So say a zone is signed by the zone owner with both BK and a strong
> > algorithm denoted STRONG. As long as a resolver only trusts STRONG
> > signatures I don't see how the status of what NSECs say is signed can
> cause
> > forged data to be trusted.
>
> The issue is arguable lack of clarity in the validator requirements of
> 4035 when the server returns only RRSIGs with algorithms none of which
> are supported by the validator.
>
> When only unsupported algorithms appear in DS, the zone is "insecure"
> and all's well.  But otherwise, when only unsupported algorithms (or
> none at all) appear in an authoritative RRset's set of RRSIGs, the
> response is "bogus" not "insecure".
>
> The question of which algorithm is stronger or weaker does not arise
> here, MiTM can in fact "downgrade" a multi-signed zone to its weakest
> signing algorithm, by stripping the other RRSIGs.  Don't use broken
> algorithms, by switching away from deprecated algorithms in a timely
> fashion.  This has largely been accomplished for algorithms 5 and 7,
> which are down to ~7% of their peak deployment counts.
>
> DNSSEC algorithm agility is serving its intended purpose just fine.
> Resolver implementations had an apparently somewhat common bug, which
> most should have addressed by now (that the issue is public).
>
> --
> Viktor.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] BlackHat Presentation on DNSSEC Downgrade attack

[Phillip Hallam-Baker]

Looks to me like there is a serious problem here.

NSEC record specifies what is signed but not the algorithm used to sign. DNSSEC 
allows multiple signature and digest algorithms on the same zone. If a zone 
does this, validators are prohibited from rejecting records only signed using 
one of the algorithms rather than both.

Won’t go into extreme detail here as researcher’s slides will be available 
tomorrow.

This definitely needs fixing.

One near term fix is to make SHA-1 a MUST NOT. It is long past its sell-by date 
now.



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

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

[Phillip Hallam-Baker]

Paul makes excellent points here. The only security slogan I adhere to is
that security by slogan is usually bad security.

Just as it is impossible to render most technical arguments in a tweet,
boiling them down to three word slogans 'Security Through Obscurity'
completely misses the original points being made.

Back in 1992 there were some people calling me all sorts of names for
suggesting that UNIX systems should be configured to use shadow passwords
and that salted hashes are not a sufficient control. 'Security through
obscurity' they screamed. That stopped a few weeks later when CRACK came
out.

The biggest weakness in most Internet security designs is that they are
designed so that a single point of failure causes a complete collapse. We
are only just getting to deploy multi-layer security.

I really can't see much point in changing the naming system API unless we
are also going to change the naming/discovery system. This does not mean we
throw DNS away and start again but it would mean learning from the past 30
years and building a system that meets our current needs.

Today, the DNS protocol serves three distinct sets of requirements:

1) Locating the authoritative server for a delegated zone
2) Service discovery at the authoritative
3) Client to caching resolver

These are three separate applications which should have three separate
protocols.

*1) Locating an authoritative service.*

I don't suggest we throw ICANN away completely but I think we can provide a
sidegrade that is better for individual users. $10/yr is far too much for a
domain name. I can do $0.10 with no renewal fee. It will be necessary for
$BTC and the Ponzi coins to die die die before a public goods proposal can
work in that space but fortunately that appears to be well underway.

I plan a notarized append only log of signed assertions specifying the root
of trust for a callsign @alice. This may optionally include the address of
an authoritative DNS service for the zone alice.mesh. The intention being
that Alice can use alice.mesh in place of .local and thus avoid all the
inevitable confusion that .local entails.

*2) Service discovery at the authoritative*

Existing DNS protocol is almost OK. But needs to be extended so that ad hoc
extensions such as geographic responses are formalized. Can also optimize
the protocol in various ways such as allowing multiple response packets for
a single request and introducing new query types optimized for the new
discovery mechansim.

*3) Client to caching resolver*

DPRIV isn't doing it for me, sorry. The basic problem here is that DNS
protocol as implemented only allows one error code per request and so even
though you can have multiple requests in theory, you can only make one
query per packet in practice.

I want to move to the DNS Service Discovery approach (RFC6763). Every
service is discovered by means of an SRV record lookup. In normal
circumstances, a client would never query for the A or  records, they
would ask for the _SRV and get the TXT and A/ as additional records.

This is the approach I am using in my own work. The big change I would to
make in the future is to allow the DNS resolution to be access controlled
and thus make use of private views more tractable.



On Thu, Jun 16, 2022 at 2:34 PM Paul Vixie via dns-operations <
dns-operati...@dns-oarc.net> wrote:

> -- Forwarded message --
> From: Paul Vixie 
> To: DNS-Operations 
> Cc:
> Bcc:
> Date: Thu, 16 Jun 2022 11:25:48 -0700
> Subject: Re: [dns-operations] [Ext] How should work name resolution on a
> modern system?
>
>
> David Conrad wrote on 2022-06-16 08:26:
> > ... 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.
>
> when considering BIND9, bob halley and i knew of many BIND4 and BIND8
> installations who ran a different name server instance for each IP
> interface address, in order that different audiences would receive
> different results. this seemed to us like the long way around, and we
> wanted BIND9 to handle this situation natively.
>
> while RFC 1597 (later reissued as RFC 1918) was widely practiced at the
> time BIND9 was designed, it's true as david recounts above that the
> primary use case we had for "views" was enterprise-internal naming
> systems. (when i did some consulting for sony electronics, we had to
> keep 43/8 addresses from leaking to the outside world.)
>
> see also .
>
> --
> P Vixie
>
>
>
>
> -- Forwarded message --
> From: Paul Vixie via dns-operations 
> To: DNS-Operations 
> Cc:
> Bcc:
> Date: Thu, 16 Jun 2022 11:25:48 -0700
> Subject: Re: [dns-operations] [Ext] How should work name resolution on a
> modern system?
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> 

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

[Phillip Hallam-Baker]

It is my firm belief that the collapse of the crypto-ponzi world and the
$45 name coins is an essential precondition for anything useful to happen
in this space. It is possibly fortuitous that this appears to be underway
as we speak.

One reason we are where we are is that UNIX doesn't actually have a DNS
interface, it has a name service API that predates DNS which has been
repurposed. So very little of the power of DNS is actually visible to the
application. Unless you write your own DNS resolution API and that has
other issues.

Use of .local is a kludge.

Proposing something better is easy. Been there, done that, have running
code. Deployment is the hard part.

On Wed, Jun 15, 2022 at 7:52 PM Viktor Dukhovni 
wrote:

> On Wed, Jun 15, 2022 at 07:13:30PM -0400, Phillip Hallam-Baker wrote:
>
> > I am of course fully aware of the commercial and technical issues that
> make
> > it very difficult for the incumbents to address this problem. But that
> > doesn't change the fact that a system designed to meet the needs of
> > educational institutions exchanging email in the 1980s is really not fit
> > for purpose for the needs of five billion users in the 2020s.
>
> Less stridently, we can recognise that the service discovery APIs we
> have do not have a first-class notion of overlay "views" each with its
> own independent naming tree, and the applications running on top of
> these APIs don't have syntax for choosing a view in which to resolve
> such names.
>
> The closest we have is the ".local" subspace of the global DNS, and
> reaching IETF consensus on such special use namespaces has been
> exceedingly complex.
>
> So the DNS is fundamentally a *global* namespace, but one in which
> businesses often overlay a single additional internal view.
>
> I don't think this is so much a *DNS* problem as such, or that DNS is
> not fit for purpose, but I do agree that requirements are shifting,
> and that indeed home automation is served poorly by a global namespace,
> and an overly centralised operational model.
>
> Sadly, time to market seems to favour doing what already works, however
> poorly.  I do hope that real innovation can happen in this space, and
> better solutions found.  It won't be easy.
>
> --
> Viktor.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Phillip Hallam-Baker]

On Wed, Jun 15, 2022 at 5:13 PM Paul Hoffman  wrote:

>
> What is "profoundly fragile" about A or  records at any level of the
> DNS hierarchy?
>

Well since you asked...


Alice has a home with IoT devices installed in the walls. No scratch that,
I have such a house. Currently roughly $10,000 worth of high tech junk, all
of which has failed to meet expectations.

One of the real problems with IoT systems at present is that they all end
up relying in services in the cloud. Which means that when my wife asks me
to change the temperature on the Nest thermostat, it takes a minute to do
that because I have to connect to the site which then kicks me to the
google account log in and back again then to a very slow site. I am pretty
sure the issue is not on my side, I am using a brand new MacBook Pro and
the Internet drop is never slower than 300Mbs.

There are many of things wrong with the current vision for IoT but the
reliance on external services is one of the biggest. I should be able to
control any device in my house when the Internet is out.

Resolving a name such as iot.example.com has two separable concerns:

1) Resolve the authoritative for the domain example.com
2) Query the authoritative to get the A/ for iot.example.com

The current DNS infrastructure does separate these concerns, it just does
it incredibly badly using a one size fits all protocol that conflates
resolution of what changes very rarely (the authoritative binding) with the
discovery of the device services themselves.

Moreover, while it has been understood that split horizon DNS is essential
to running any large scale enterprise DNS, this separation is not supported
in the protocols which are still in effect built on the assumption that the
very idea is heresy thus resulting in instability and error when devices
pass from the internal network to the outside and back.

So while the obvious deployment of DNS as a discovery system for the home
would be for the homeowner to have a domain for the house with the
discovery system operating there, DNS doesn't support this approach. The
A/ record resolution is fragile because it has to be performed in the
wrong place.


I am of course fully aware of the commercial and technical issues that make
it very difficult for the incumbents to address this problem. But that
doesn't change the fact that a system designed to meet the needs of
educational institutions exchanging email in the 1980s is really not fit
for purpose for the needs of five billion users in the 2020s.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] K-root in CN leaking outside of CN

[Phillip Hallam-Baker]

On Sat, Nov 6, 2021 at 12:52 PM Viktor Dukhovni 
wrote:

> On Sat, Nov 06, 2021 at 12:35:00PM -0400, Phillip Hallam-Baker wrote:
>
> > If the DNS protocol were sane the root zone would be published as a
> > notarized, chained append only log. Every DNS resolver would obtain a
> list
> > of updates to that log either directly or indirectly. There would be no
> > root server to poison or DDoS.
>
> https://localroot.isi.edu/about/


So near!

But the problems are that 1) you need to know you have the up to date copy.
so I think you want to go for a chain approach which naturally lends itself
to replication 2) you need an infrastructure that allows you to get updates
when the source is DDoSed and  3) this has to be turned on by default

I know this has been proposed multiple times. But it still isn't common let
alone standard operating procedure.


It should be of course because local root allows a resolver to kill
resolution of non existent TLDs which is 99% of the traffic they send to
the root.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] K-root in CN leaking outside of CN

[Phillip Hallam-Baker]

On Sat, Nov 6, 2021 at 12:22 AM Manu Bretelle  wrote:

> Hi all,
>
> Based on https://root-servers.org/, there are a few root servers operated
> from Mainland China.
>
> How do we ensure that those are not advertised outside of China so DNS
> answers are not poisoned by the GFW?
>

You can't.

All you can do is to authenticate the data and reject invalid responses.

I am getting heartily sick of all this fearmongering about China. One of
the chief fearmongers who was largely responsible for coining the phrase
'yellow peril' was Kaiser Wilhelm II who after telling Europe how China was
going to invade Europe for decades went and invaded Europe himself starting
WWI.


If the DNS protocol were sane the root zone would be published as a
notarized, chained append only log. Every DNS resolver would obtain a list
of updates to that log either directly or indirectly. There would be no
root server to poison or DDoS.

But the DNS protocol is not sane and is not going to be changed. Not least
because the organizations that run root servers are rather pleased about
the prestige it brings to them.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Blockchain Address Transparency with DNS

[Phillip Hallam-Baker]

There are good reasons for using an append only log as the basis for a name
registration. See for example:

Mathematical Mesh 3.0 Part VII: Mesh Callsign Service (ietf.org)


If you start with an authenticated append only log, you get the benefits of
secure by default. The log is the authoritative source of name
registrations. If you require registration of a public key at the same
time, you can make all registry operations transparent and auditable.

But

You can't graft an append only log onto a registry post facto. And
certainly not as a third party effort. Who is to say any given blockchain
is the ground truth?

The chief limitation in the current DNS is that the running costs are
ruinous as the registry is required to support resolution which exposes it
to abuse. 99% of traffic to core DNS is abuse and misconfigured systems.
The root operators, VeriSign etc, are unable to respond to the abuse
except by building out absurd levels of excess capacity. As a consequence,
DNS names must be rented rather than sold.

Finally, any system that builds on any infrastructure related to a
purported crypto-currency is going to be unacceptable to many. I for one am
fed up of being told BitCoin doesn't generate vast amounts of CO2, doesn't
provide the payments infrastructure for ransomware, child abuse etc. I am
fed up of the gaslighting denial of the facts.






On Fri, Jul 23, 2021 at 4:38 AM Vittorio Bertola via dns-operations <
dns-operati...@dns-oarc.net> wrote:

>
>
>
> -- Forwarded message --
> From: Vittorio Bertola 
> To: InterNetX - Marco Schrieck ,
> dns-operations@lists.dns-oarc.net
> Cc:
> Bcc:
> Date: Fri, 23 Jul 2021 10:32:09 +0200 (CEST)
> Subject: Re: [dns-operations] Blockchain Address Transparency with DNS
>
>
> > Il 22/07/2021 21:36 InterNetX - Marco Schrieck <
> marco.schri...@internetx.com> ha scritto:
> >
> >
> > Hi Eduardo,
> >
> > Maybe you take a look on this. its is something similar:
> >
> > https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/
>
> That draft associates a hostname with a URI pointing to a DID document,
> i.e. the identifier for a digital identity, rather than with a blockchain
> address in general. At the ID4me project (www.id4me.org) we are also
> working on a way to store a DID document directly within a DNS record,
> saving the HTTP connection. However, I am not sure whether Eduardo's use
> case is about identities or more general than that.
>
> I would have comments on Eduardo's proposal (e.g. in the case of the TXT
> record I would recommend the use of a specific underscored prefix) but
> possibly this is a discussion for DNSOP, rather than for DNS-OARC.
>
> --
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
>
>
> -- Forwarded message --
> From: Vittorio Bertola via dns-operations 
> To: InterNetX - Marco Schrieck ,
> dns-operations@lists.dns-oarc.net
> Cc:
> Bcc:
> Date: Fri, 23 Jul 2021 10:32:09 +0200 (CEST)
> Subject: Re: [dns-operations] Blockchain Address Transparency with DNS
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Separating .ARPA operations from the root zone

[Phillip Hallam-Baker]

I think it is a very worthwhile and necessary effort. But the security
considerations are woefully insufficient.

What has never been fully appreciate is that while the root zone is the
apex of the naming hierarchy. The .arpa zone is potentially the apex of the
trust hierarchy.

Separating the two concerns is a very useful and worthwhile 'separation of
duties' control. Besides the security benefits, a system in which there are
two roots makes for much more convincing answers to questions of root
rollover.


We should do it right because the .ARPA zone is evolving into the trust
root of the legacy telephone system. It is also likely to be the delegation
point for any new naming system.

The concentration of risk in the root '.' has always been a weakness in the
DNS design. This change provides an opportunity to address some of that.
While the Internet is robust against information attacks, almost none of
the facilities are designed to withstand physical attacks. the best
defense is to make a physical attack pointless.


What this means in practice is that as with the DNS apex root servers, the
.ARPA root servers need to have stable, static IP addresses that change
infrequently with long notice times. The zones should be signed using
appropriate ceremonies.

I am of course aware of the cost of PKI ceremonies. I taught the VeriSign
ceremony course. I am thinking of separating the ceremonies as a longer
term goal and there is technology developed since we wrote the VeriSign
ceremonies that allows the cost to be greatly reduced.

One way sequence technology and threshold signatures mean that it is no
longer necessary for key ceremony key holders to meet in the same physical
location. Nobody is going to let us try out new technology on the root
zone. But we can probably get away with that for .arpa and then transition
the dot to that approach.


So what I would suggest is:

1) Separate the hosts for .ARPA from the root zone hosts.

2) Create a separate set of HSMs for .ARPA but administer them within the
ICANN root ceremony

3) Transition ARPA to next generation technology which avoids the need to
meet to perform ceremonies in person.




On Fri, Aug 7, 2020 at 12:49 PM Kim Davies  wrote:

> Folks,
>
>
>
> I wanted to draw attention to an Internet-Draft under development that
> seeks to remove the unique interdependency that the .arpa zone has with the
> root zone, by virtue of the zone being served by the root servers:
>
>
>
>
> https://www.ietf.org/id/draft-iana-arpa-authoritative-servers-01.txt
>
>
>
> We are looking for additional review of the proposed changes before taking
> further steps.
>
>
>
> kim
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony

[Phillip Hallam-Baker]

It is an interesting problem and one that we did not have to consider when
we built the VeriSign root.

I don't have a practical answer to the immediate problem. But assuming that
this is going to remain an ongoing issue, perhaps we should start looking
at threshold signature techniques that would allow future ceremonies to be
physically separated should the need arise.

Given that this would require FIPS140 hardware to be built to the specs
etc... This is not a short fix, the horizon for deployment would be five
years minimum. But the longer we delay, the longer it will take.

I have developed an initial threshold signatures paper
https://datatracker.ietf.org/doc/draft-hallambaker-threshold-sigs/

That does not (quite) provide the answer you need. But my colleagues at
Waterloo have developed a similar scheme 'FROST' which might have what is
needed. FROST extends the work to allow signature keys to be created in a
distributed process rather than being generated centrally and then split as
mine does.

We will be discussing my proposal to adopt this as a CFRG work item at the
virtual interim on Wednesday Apr-22-2020 0900
https://datatracker.ietf.org/meeting/interim-2020-cfrg-01/session/cfrg
___
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

[Phillip Hallam-Baker]

Absolutely.

The technology is the easy bit. Deployment is the hard problem.

We are trying to make changes to a machine with ten billion components.
Every single one of which is more complex than the most complex machine
built before the moon landings and some of which are the product of more
human intellectual activity than the sum of all human thought prior to that
date.

Don't expect changing the Internet to be easy, it isn't.


On Wed, May 27, 2015 at 11:16 AM, Mark Andrews ma...@isc.org wrote:


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

 Mark

 marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db |
 sh gentypereport tlsa | grep -v all ok
 accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
 accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
 accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
 accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
 accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
 accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout
 aig. @156.154.144.6 (ns1.dns.nic.aig.): tlsa=timeout
 aig. @156.154.145.6 (ns2.dns.nic.aig.): tlsa=timeout
 aig. @156.154.159.6 (ns3.dns.nic.aig.): tlsa=timeout
 aig. @156.154.156.6 (ns4.dns.nic.aig.): tlsa=timeout
 aig. @156.154.157.6 (ns5.dns.nic.aig.): tlsa=timeout
 aig. @156.154.158.6 (ns6.dns.nic.aig.): tlsa=timeout
 al. @194.119.192.8 (ns-al.isti.cnr.it.): tlsa=timeout
 an. @65.174.238.100 (engine2.una.an.): tlsa=timeout
 an. @200.26.199.102 (engine3.una.an.): tlsa=timeout
 ao. @2c0f:f828:2::b (ns02.dns.ao.): tlsa=timeout
 ar. @2801:140::10 (a.dns.ar.): tlsa=timeout
 as. @204.74.112.1 (tld1.ultradns.net.): tlsa=timeout
 as. @204.74.113.1 (tld2.ultradns.net.): tlsa=timeout
 as. @199.7.66.1 (tld3.ultradns.org.): tlsa=timeout
 as. @199.7.67.1 (tld4.ultradns.org.): tlsa=timeout
 as. @192.100.59.11 (tld5.ultradns.info.): tlsa=timeout
 as. @198.133.199.11 (tld6.ultradns.co.uk.): tlsa=timeout
 axa. @156.154.144.20 (ns1.dns.nic.axa.): tlsa=timeout
 axa. @156.154.145.20 (ns2.dns.nic.axa.): tlsa=timeout
 axa. @156.154.159.20 (ns3.dns.nic.axa.): tlsa=timeout
 axa. @156.154.156.20 (ns4.dns.nic.axa.): tlsa=timeout
 axa. @156.154.157.20 (ns5.dns.nic.axa.): tlsa=timeout
 axa. @156.154.158.20 (ns6.dns.nic.axa.): tlsa=timeout
 best. @156.154.144.24 (ns1.dns.nic.best.): tlsa=timeout
 best. @156.154.145.24 (ns2.dns.nic.best.): tlsa=timeout
 best. @156.154.159.24 (ns3.dns.nic.best.): tlsa=timeout
 best. @156.154.156.24 (ns4.dns.nic.best.): tlsa=timeout
 best. @156.154.157.24 (ns5.dns.nic.best.): tlsa=timeout
 best. @156.154.158.24 (ns6.dns.nic.best.): tlsa=timeout
 bf. @193.50.53.3 (ns1.ird.fr.): tlsa=timeout
 bf. @2001:5a0:d00:::42c6:9163 (ns2.as6453.net.): tlsa=timeout
 bf. @66.198.145.99 (ns2.as6453.net.): tlsa=timeout
 bid. @156.154.144.25 (ns1.dns.nic.bid.): tlsa=timeout
 bid. @156.154.145.25 (ns2.dns.nic.bid.): tlsa=timeout
 bid. @156.154.159.25 (ns3.dns.nic.bid.): tlsa=timeout
 bid. @156.154.156.25 (ns4.dns.nic.bid.): tlsa=timeout
 bid. @156.154.157.25 (ns5.dns.nic.bid.): tlsa=timeout
 bid. @156.154.158.25 (ns6.dns.nic.bid.): tlsa=timeout
 biz. @156.154.124.65 (a.gtld.biz.): tlsa=timeout
 biz. @156.154.125.65 (b.gtld.biz.): tlsa=timeout
 biz. @156.154.127.65 (c.gtld.biz.): tlsa=timeout
 biz. @156.154.126.65 (e.gtld.biz.): tlsa=timeout
 biz. @209.173.58.66 (f.gtld.biz.): tlsa=timeout
 biz. @156.154.128.65 (k.gtld.biz.): tlsa=timeout
 bm. @206.53.190.202 (ns1.bm.): tlsa=timeout
 bm. @69.17.194.1 (ns2.bm.): tlsa=timeout
 bt. @2405:d000:0:100::200 (ns1.druknet.bt.): tlsa=timeout
 buzz. @156.154.144.29 (ns1.dns.nic.buzz.): tlsa=timeout
 buzz. @156.154.145.29 (ns2.dns.nic.buzz.): tlsa=timeout
 buzz. @156.154.159.29 (ns3.dns.nic.buzz.): tlsa=timeout
 buzz. @156.154.156.29 (ns4.dns.nic.buzz.): tlsa=timeout
 buzz. @156.154.157.29 (ns5.dns.nic.buzz.): tlsa=timeout
 buzz. @156.154.158.29 (ns6.dns.nic.buzz.): tlsa=timeout
 bw. @2c0f:ff00:0:4::2 (ns1.btc.bw.): tlsa=timeout
 caravan. @156.154.144.32 (ns1.dns.nic.caravan.): tlsa=timeout
 caravan. @156.154.145.32 (ns2.dns.nic.caravan.): tlsa=timeout
 caravan. @156.154.159.32 (ns3.dns.nic.caravan.): tlsa=timeout
 caravan. @156.154.156.32 (ns4.dns.nic.caravan.): tlsa=timeout
 caravan. @156.154.157.32 (ns5.dns.nic.caravan.): tlsa=timeout
 caravan. @156.154.158.32 (ns6.dns.nic.caravan.): tlsa=timeout
 cartier. @156.154.144.34 (ns1.dns.nic.cartier.): tlsa=timeout
 cartier. @156.154.145.34 (ns2.dns.nic.cartier.): tlsa=timeout
 cartier. @156.154.159.34 (ns3.dns.nic.cartier.): tlsa=timeout
 cartier. @156.154.156.34 (ns4.dns.nic.cartier.): tlsa=timeout
 cartier. @156.154.157.34 (ns5.dns.nic.cartier.): tlsa=timeout
 cartier. @156.154.158.34 (ns6.dns.nic.cartier.): tlsa=timeout
 cbn. @156.154.144.35 (ns1.dns.nic.cbn.): tlsa=timeout
 cbn. @156.154.145.35 (ns2.dns.nic.cbn.): tlsa=timeout
 cbn. @156.154.159.35 (ns3.dns.nic.cbn.): tlsa=timeout
 cbn. @156.154.156.35 (ns4.dns.nic.cbn.): tlsa=timeout
 

Re: [dns-operations] Interesting messages in our logs

[Phillip Hallam-Baker]

On Sat, Nov 1, 2014 at 1:21 PM, Paul Vixie p...@redbarn.org wrote:

   what we've learned from random-subdomain flood attacks is that the
 nxdomain limit (in BIND9 that's nxdomains-per-second) and the slip ratio
 both have to be higher than we thought. at the moment i'm going to say
 nxdomains-per-second of at least 20, and a slip ratio of 5.

  This sort of control is of course what distinguishes a prototype
implementation of a service from deployment grade.

One of the concerns I have about approaches to DPRIVE is that they tend to
start from the DNS specification and add security to that model rather than
look at real world implementations.

It is really easy to assume away the hard problems. I want to get
authentication into the client-resolver loop so that we have a
cryptographic enforcement mechanism for abuse control rather than relying
on heuristics.
___
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] Interesting messages in our logs

[Phillip Hallam-Baker]

On Sat, Nov 1, 2014 at 4:15 PM, Paul Vixie p...@redbarn.org wrote:

  Phillip Hallam-Baker ph...@hallambaker.com
  Saturday, November 01, 2014 1:08 PM

 ...

 One of the concerns I have about approaches to DPRIVE is that they tend to
 start from the DNS specification and add security to that model rather than
 look at real world implementations.

 ...


 i've briefly advised the dns-privacy@ group to avoid opacity as a goal.
 dns's control and data planes are intermixed, and any attempt to reduce the
 forwarding/recursion/caching layer to zero knowledge will be an even larger
 task than creating DNS in the first place and then tuning and tweaking it
 for the last ~25 years. we'll see what happens.


One of the most common failure modes in security designs is the mistaken
belief that there is only one security concern.

The thing is that almost every security problem is quite easily solved if
that is the only problem that is recognized. Hence my concern about a
charter that only talks about one problem.

The NSA is the cause du jour. But they are only one intelligence agency and
surveillance is only one of the potential harms people face on the net.
Russian hacker gangs trying to steal people's money or encrypt their data
and hold the keys for ransom are rather more commonly exercised threats.

Curated DNS is potentially a tool that can be used to provide protection.
But as with any sort of anti-virus there is a privacy consequence and the
introduction of a trusted third party with potentially serious intrusive
capabilities.
___
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] Interesting messages in our logs

[Phillip Hallam-Baker]

On Sat, Nov 1, 2014 at 4:48 PM, bert hubert bert.hub...@netherlabs.nl wrote:
 On Sat, Nov 01, 2014 at 04:08:56PM -0400, Phillip Hallam-Baker wrote:
 One of the concerns I have about approaches to DPRIVE is that they tend to
 start from the DNS specification and add security to that model rather than
 look at real world implementations.

 Surely you mean DNSSEC ;-)

I have given up on fixing DNSSEC. People always assume that any
criticism is an attempt at sabotage. So it takes far too long to fix
what needs fixing.
___
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

[Phillip Hallam-Baker]

On Thu, Oct 23, 2014 at 2:00 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:

 On Oct 23, 2014, at 10:29 AM, Andrew Sullivan a...@anvilwalrusden.com
 wrote:
 
  On Thu, Oct 23, 2014 at 07:25:46AM -0700, Paul Hoffman wrote:
  Speaking as someone who supports all end systems to be their own
 validating recursive resolver.
 
  Validating I get.  Why recursive?

 That's a fair question. I'm much more interested in validating than
 recursive. I don't believe that enough upstream resolvers will reliably get
 the end system answers that can be validated, so the validating end system
 will have to be able to be a recursive some of the time anyway. I suppose
 it would be better to have the end system be a validating
 stub-but-recursor-when-necessary, but that seems weird. Maybe it isn't.


I would like to push you back to 'validating records that matter to the
application layer like DANE and security policy records.'
___
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

[Phillip Hallam-Baker]

On Thu, Oct 23, 2014 at 1:36 PM, Paul Vixie p...@redbarn.org wrote:

 i encourage anyone who thinks full resolvers can run inside end hosts
 which currently run stub resolvers, to try it.

 BIND9 runs fine on windows and macos laptops. so, without even touching
 the real growth area of the edge (which is mobile devices like smart
 phones), you can get a sense of how rarely you'll be able to perform dns
 lookups, if you just switch to 127.0.0.1 as your name server (override
 this in your dhcp settings) and run a recursive dns server there.

 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 this for over a decade, but, i always have a VPN open, which
 can use TCP/80 as a backup carriage path, and the VPN is absolutely
 necessary in my experience, and, that is a rather high bar for making
 localhost do dns recursion and iteration at scale.)


I was running that for a couple of months.

It appeared to work fine but I dropped it as soon as I discovered that I
was still getting Verizon sitefinder ads placed when I got NXDOMAIN. And
the same happens on 8.8.8.8

Bottom line is that if you try to use port 53 for client-recursive you will
find yourself under MITM attack much of the time. And its not even all
malicious. A lot of ISPs are MITM the DNS traffic so they don't get one of
the big TLDs onto their case for allowing their customers to do DDoS.
___
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

[Phillip Hallam-Baker]

On Thu, Oct 23, 2014 at 2:31 PM, Paul Vixie p...@redbarn.org wrote:



   Phillip Hallam-Baker ph...@hallambaker.com
  Thursday, October 23, 2014 11:25 AM


 ...
 Bottom line is that if you try to use port 53 for client-recursive you
 will find yourself under MITM attack much of the time. And its not even all
 malicious. A lot of ISPs are MITM the DNS traffic so they don't get one of
 the big TLDs onto their case for allowing their customers to do DDoS.


 my bottom line is related and similar: rdns is hard, and can't scale to
 the actual internet access edge, currently two billion or more devices, and
 growing; we need a well guarded path (like HTTPS without any X.509 CA
 intermediaries telling us what key to trust -- SSL keying material has to
 be exchanged in some more-trustful way), to get from large numbers of stubs
 to moderate numbers of recursives.


My view precisely. Except that I am prepared to make the default mechanism
to be to use of SSL and an EV cert to jump start the process of making the
initial contact between the relying party and the resolution service. With
the option of manual keying if you choose.


So the very first time you bought your very first a machine and started it
up, you would choose your DNS resolution provider, e.g. dnsbycomodo.com. If
you are using a public resolver, you give it the DNS name of the service
provider and it uses legacy DHCP DNS and the WebPKI (preferably an EV cert)
to establish first contact over TLS. Once the service credentials are
exchanged the binding between that machine and the DNS service selected can
be permanent.

If you are using a private resolver then you are probably not providing
open service to anyone on the net. You are going to only want to provide
access to people who have been issued accounts. So the binding mechanism is
likely to involve some sort of account and PIN code activation or
confirmation of the access request from another device.



 otherwise the DNS data path leading to the edge will continue to look
 like, and be treated like, raw meat by the thin margin internet access
 providers looking to plump up their revenue by selling ads one way and
 telemetry the other way.


Since any new protocol is going to be encrypted there is no reason to use
the same port or indeed a well known port for discovery.

Looking ahead to IPv6, the large address space offers a lot of options for
DDoS mitigation
___
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 the story on gmail.fr?

[Phillip Hallam-Baker]

Seems obvious enough to me.

The domains were bought to prevent a squatter getting them and they are
parked with a company that does anti-phishing services (among other
things).

The Google DNS records are probably only intended to be read by the parking
service and would be used to signal a change in the configuration.

Well that's how I would do it.




On Mon, Jul 7, 2014 at 11:42 AM, Chris Thompson c...@cam.ac.uk wrote:

 On Jul 6 2014, Michele Neylon - Blacknight wrote:

  Gmail.ie redirects to Gmail correctly ..

 Though I've never seen them advertise Gmail using anything other than the
 .com


 gmail.uk  gmail.co.uk are delegated to ns{1,2,3,4}.google.com, but they
 give REFUSED when queried about them. Same for gmail.co.nz, gmail.es,
 gmail.in,
 but I don't think I am going to work through all the ccTLDs!

 I expect only someone from Google could really explain what they are up
 to...

 --
 Chris Thompson   University of Cambridge Information Services,
 Email: c...@uis.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue,
 Phone: +44 1223 334715   Cambridge CB3 0RB, United Kingdom.

 ___
 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] Current thinking on internal corporate/campus domain names

[Phillip Hallam-Baker]

Well you could use ADQ2EW-H5BLYG-JSUJEZX-S6QT3I-ZSA.corp

But no public CA could issue you any certificates which would mean you
can't do IMAP over TLS and many other things you would likely want to do.

But there could be a .crypt or .ppe top level domain in which there was no
registration fee.

People would simply generate a master public key pair, generated the
phingerprint (Base64s of the SHA-512-128 hash of the DER KeyInfo encoding
of the public key), this would be their second level domain.

ADQ2EW-H5BLYG-JSUJEZX-S6QT3I-ZSA.crypt

Entries in the zone would naturally be DNSSEC signed and TRANS logged. The
DNSSEC KSK would be signed by the master public key corresponding to the
zone.


You would probably not want to present a zone of that type to end users but
you might well use it as the target of a CNAME. Or the binding might be
made through a certificate.

If you ever lost your Master Key or it was disclosed you would be utterly
and totally screwed.




On Tue, Jun 24, 2014 at 1:11 PM, Colm MacCárthaigh c...@stdlib.net wrote:

 On Mon, Jun 23, 2014 at 5:41 PM, Phillip Hallam-Baker
 ph...@hallambaker.com wrote:
  As a practical matter .corp is already used for this purpose and ICANN
 has
  been forced to accept the practice. So that would be a good choice.

 One of the problems with .corp is what happens when companies,
 universities or other organisations (and their networks) merge. There
 is definitely a case for uniqueness. It would be interesting to have a
 registry for a TLD that can manage uniqueness, but also guarantee that
 the TLD will never have active public nameservers (talk about cheap to
 run!).

 --
 Colm

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

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

[Phillip Hallam-Baker]

As a practical matter .corp is already used for this purpose and ICANN has
been forced to accept the practice. So that would be a good choice.

But you can't get a CA issued certificate for .corp any more. So you will
find that a large number of applications that have embedded assumptions
about the use of WebPKI certs will cause headaches.

Many companies I have dealt with have a separate corporate domain [e.g.
paypal-inc.com]


Split horizon DNS is very common and causes a pain because there is no way
to know what view of the DNS a particular machine is seeing for a given
resolution. This is one of the issues I have looked to clear up in my
Private DNS proposal.

It is clearly undesirable for internal machine names to be publicly visible
or for a particular user or machine/user to have a view of the Internet
that varies according to where or how they connect. VPNs are abominable to
debug and use.

Each machine or user/machine combo should have the same view of the
Internet regardless of where it is accessing the net from. This is not
possible with traditional DNS but putting in an encryption and
authentication layer clears the whole situation up.


I don't know if there is a strong privacy case for Encrypting DNS traffic
or not. The big problem is that the leverage you get from encrypting the
traffic tends to be small if the adversary can perform traffic analysis.
But I can make a very strong case that Private DNS makes network admin a
lot easier.



On Mon, Jun 23, 2014 at 5:37 PM, Phil Regnauld regna...@nsrc.org wrote:

 Doug Barton (dougb) writes:
  
  * Registered domain name (e.g., somecompany.com)
  * Fantasy tld (e.g., .mycorp)
  * .local (collides zeroconf/mDNS)
 
  You missed a fourth option, which is generally my preference. Use a
  subdomain of an existing registered domain. I generally like
  is.example.com, where IS stands for Internal Systems, but feel
  free to be creative there. Generally a good idea to keep it short
  though.

 +1. Microsoft has made this their recommended way as well (after
 years of getting lambasted for suggesting .local and .corp).

 For Jim suggesting split DNS: please, no. It's troubleshooting
 hell trying to figure out what the user on the phone is seeing,
 etc.

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

[Phillip Hallam-Baker]

On Thu, May 29, 2014 at 10:29 AM, Matthew Pounsett m...@conundrum.com wrote:

 Host names are only allowed the characters [a-z] (case insensitive), [0-9], 
 and [-].  See RFCs 952 and 1123.

 Domain names may use any string as a label, so for example the underscore is 
 perfectly legal.  See RFC 2181.

This is the second time today I have come across the form 'very old
RFC amended by another old RFC'. And it worries me. Take the text in
RFC1123:

  The syntax of a legal Internet host name was specified in RFC-952
  [DNS:4].  One aspect of host name syntax is hereby changed: the
  restriction on the first character is relaxed to allow either a
  letter or a digit.  Host software MUST support this more liberal
  syntax.

A document from 1985 with an errata in 1989 is still the definitive
definition of host name. And that is a problem because all numeric
names are valid DNS hostnames.

So is 10.1.2.3 an IP address or is it potentially a valid DNS host name?

According to RFC952 as updated by RFC1123 it is. Even though it makes
no sense given what follows in RFC1123 which clearly expects that
there will never be all numeric TLDs and thus no possibility of a
confusion between host names and IP addresses.


There should be a standards track document that clearly prohibits all
numeric TLDs. Do we really want to have to trust that a future head of
ICANN faced with a choice between rejecting such a proposal and a
second luxury yacht decides to go sailing?

At any rate, given the state of the specs, I don't see cause for being
rude when people ask questions about them.

Take a look at the title of RFC 952:

DOD INTERNET HOST TABLE SPECIFICATION

Why would a reader expect this to be relevant to the Internet? It
looks to me as if it is a set of specifications that are local to the
US Department of Defense.


There is a document quality issue here. None of these specs would be
published as a proposed standard today.
___
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 Decline and Fall of BIND 10

[Phillip Hallam-Baker]

What is the next edition of BIND going to be called then, 10 or 11?

On Wed, May 14, 2014 at 2:25 PM, staticsafe m...@staticsafe.ca wrote:
 This might be of interest:

 https://ripe68.ripe.net/presentations/208-The_Decline_and_Fall_of_BIND_10.pdf
 --
 staticsafe
 https://asininetech.com
 ___
 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



-- 
Website: http://hallambaker.com/
___
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