[dns-operations] [Zonemaster] DNS zone/service checking tool features survey

[Sandoche Balakrichenan]

Hi All,

Thanks for responding one response per user.  Apologies for
cross-posting.

*Access*: All

*Close date*: 03/04/2015

*Survey*:
https://fr.surveymonkey.com/r/zonemaster


*Background*: "Afnic" and "IIS.SE" are currently in the maintenance
phase of "Zonemaster", a new DNS zone/service checking tool developed as
a replacement of their respective tools, ZoneCheck
(http://www.zonecheck.fr/) and DNSCheck (http://dnscheck.iis.se/). The
survey intends to understand the requirements of the community from such
a tool. The development of new features to be integrated to the
Zonemaster tool will be prioritized based on this survey's feedback.

All the documentation and code are public in github. More information
about the project can be obtained from here :
"https://github.com/dotse/zonemaster/blob/master/README.md";.  The web
interface can be accessed in this link "zonemaster.net" and from other
TLD extensions such as ".se", ".fr" and ".re".


Sandoche.






___
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] CloudFlare policy on ANY records changing

[Yunhong Gu]

On Mon, Mar 9, 2015 at 10:58 PM, Mark Andrews  wrote:

>
>
>
> In message <
> cagmqtqjrpx_xg_ojtshsw5yqaefkzwdma16xw7iry9pr0_f...@mail.gmail.com>
> , Yunhong Gu writes:
> >
> > Returning NOTIMP may confuse resolvers as it is not clear "what is not
> > implemented".
>
> Which is why you only change one thing at a time when trying to
> determine what is covered by NOTIMP.
>
> > A NOTIMP response to an ANY query with EDNS0 option could
> > cause a retry-without-EDNS0 query, or mislead the resolver to believe
> that
> > the nameserver does not support EDNS0.
>
> And if you retry w/o a OPT record you will still get NOTIMP, move
> onto the next nameserver and enventually return SERVFAIL.
>

Retry introduces latency, which matters a lot for resolvers. There are
situations a resolver may not want to enumerate all possibilities (e.g. the
client may already timeout before the resolver get the final response).


>
> Note there really is nothing special w.r.t. ANY here.  We have
> nameservers that return NOTIMP to TXT, MX, NS, SOA, DNSKEY etc.
> About the only query type that doesn't get NOTIMP is A.
>

ANY is indeed a little special compared to the examples you mentioned. If a
nameserver returns response for A, then it should return NODATA instead of
NOTIMP for TXT, MX, etc. Returning NODATA for ANY is a little confusing,
though it can be argued to be legitimate if only cached records are
returned.

So the problem is, why NOTIMP? REFUSED sounds like a better choice.


>
> Mark
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
___
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] CloudFlare policy on ANY records changing

[Paul Hoffman]

On Mar 10, 2015, at 6:25 AM, Yunhong Gu  wrote:
> So the problem is, why NOTIMP? REFUSED sounds like a better choice. 

+1. "REFUSED" exactly describes what is going on.

--Paul Hoffman
___
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] Saga of HBONow DNSSEC Failure

[Matthew Pounsett]

On Mar 9, 2015, at 23:50 , Livingood, Jason  
wrote:

> So earlier today HBO announced a new HBONow streaming service (at an Apple 
> event). The FQDN to order, which should have been DNSSEC-enabled, was 
> order.hbonow.com. This unfortunately suffered from a rather inconveniently 
> timed DNSSEC problem (http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/). 
> :-( Of course, these being hot Net Neutrality days in the U.S., we at Comcast 
> were quickly blamed for blocking access to ordering this new service (despite 
> failures at Google and other validators). 

I’d just like to comment how pleased I am that Comcast continues to push DNSSEC 
validation, despite taking regular hits from end users.  I keep hoping others 
will follow suit.. the more large validator operators that enable it, the fewer 
hits anyone will take for doing so.




___
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] Saga of HBONow DNSSEC Failure

[Richard Lamb]

Jason-  Thank you for sharing the details.  Another excellent real world
example.  Too bad it caused you consternation.  -Rick

 

 

From: dns-operations [mailto:dns-operations-boun...@dns-oarc.net] On Behalf
Of Livingood, Jason
Sent: Monday, March 09, 2015 8:50 PM
To: dns-operations
Subject: [dns-operations] Saga of HBONow DNSSEC Failure

 

So earlier today HBO announced a new HBONow streaming service (at an Apple
event). The FQDN to order, which should have been DNSSEC-enabled, was
order.hbonow.com. This unfortunately suffered from a rather inconveniently
timed DNSSEC problem (http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/).
:-( Of course, these being hot Net Neutrality days in the U.S., we at
Comcast were quickly blamed for blocking access to ordering this new service
(despite failures at Google and other validators). 

 

Had this persisted much longer, we might have considered a negative trust
anchor of course, assuming we had direct contact with HBO on the matter
(established after they fixed the issue & we flushed the cache). A good
example of the sentiment was the tweet "Wow. I have Comcast and can't reach
http://hbonow.com  unless I use a different network. #NetNeutrality ".
People tweeted to the FCC to alert them as well.

 

But two other I-Ds I wrote up did come in handy in some of my replies on
social media: 

http://tools.ietf.org/html/draft-livingood-dnsop-auth-dnssec-mistakes-00

and 

http://tools.ietf.org/html/draft-livingood-dnsop-dont-switch-resolvers-00

 

Which leads me simply to say that if there's any interest in progressing
these I-Ds in any way, let me know. Of course you may not find them useful
until people yell at you for other people's DNS errors. ;-) 

 

- Jason

 



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] Saga of HBONow DNSSEC Failure

[Warren Kumari]

On Tue, Mar 10, 2015 at 11:09 AM, Matthew Pounsett  wrote:
>
> On Mar 9, 2015, at 23:50 , Livingood, Jason 
>  wrote:
>
>> So earlier today HBO announced a new HBONow streaming service (at an Apple 
>> event). The FQDN to order, which should have been DNSSEC-enabled, was 
>> order.hbonow.com. This unfortunately suffered from a rather inconveniently 
>> timed DNSSEC problem (http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/). 
>> :-( Of course, these being hot Net Neutrality days in the U.S., we at 
>> Comcast were quickly blamed for blocking access to ordering this new service 
>> (despite failures at Google and other validators).
>
> I’d just like to comment how pleased I am that Comcast continues to push 
> DNSSEC validation, despite taking regular hits from end users.

+lots. Thank you Comcast, and Jason.

W

 > I keep hoping others will follow suit.. the more large validator
operators that enable it, the fewer hits anyone will take for doing
so.
>
>
>
>
> ___
> 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
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] Saga of HBONow DNSSEC Failure

[Edward Lewis]

On 3/9/15, 23:50, "Livingood, Jason" 
wrote:

>So earlier today HBO announced a new HBONow streaming service (at an
>Apple event). The FQDN to order, which should have been DNSSEC-enabled,
>was order.hbonow.com. This unfortunately suffered from a rather
>inconveniently timed DNSSEC problem
>(http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/).
> :-( Of course, these being hot Net Neutrality days in the U.S., we at
>Comcast were quickly blamed for blocking access to ordering this new
>service (despite failures at Google and other validators).

When this first surface after the "infamous NASA.GOV" incident, I sent a
private apology because I (as well as others) knew this day would come -
when an ISP would get the brunt of someone's DNSSEC misfire.  (Others
include many who worked on the original design and deployment workshops.)

This time I'll offer a public apology.  Sorry, Comcast.

The only way I can make this up to you is to better my efforts at making
DNSSEC an easier to run, less clumsy protocol.  The protocol is what it is
- when something doesn't check out, it goes dark.  The mitigation is
better tools to explain this and to manage this.  The negative trust
anchor draft addresses the latter.

Oh, and, Jason, a squirrel has managed to chew through my mom's cable, can
you fix that for me?  Perhaps Comcast could install little squirrel
feeders in the neighborhood.


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] CloudFlare policy on ANY records changing

[Evan Hunt]

On Tue, Mar 10, 2015 at 07:53:51AM -0700, Paul Hoffman wrote:
> On Mar 10, 2015, at 6:25 AM, Yunhong Gu  wrote:
> > So the problem is, why NOTIMP? REFUSED sounds like a better choice. 
> 
> +1. "REFUSED" exactly describes what is going on.

Another +1. It's comparable to AXFR/IXFR from an unauthorized client.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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] CloudFlare policy on ANY records changing

[Paul Hoffman]

On Mar 10, 2015, at 8:46 AM, David C Lawrence  wrote:
> 
> Paul Hoffman writes:
>> On Mar 10, 2015, at 6:25 AM, Yunhong Gu  wrote:
>>> So the problem is, why NOTIMP? REFUSED sounds like a better choice. 
>> 
>> +1. "REFUSED" exactly describes what is going on.
> 
> One down side there, however, is that REFUSED as understood by
> resolvers commonly has the semantic currently that the name is not
> hosted by the server at all.  What used to be root referrals for lame
> delegations is now REFUSED to minimize response size.

If a resolver is sending an ANY before it sends its actual request, that could 
be a problem. However, they shouldn't be doing that.

It is likely that any response we think of (even no response at all) will cause 
some deployed resolvers to get the wrong idea. Having said that, it is 
perfectly reasonable for an operator to not want to reply to an ANY, given the 
unclarity of what it is expected to send back and the opportunity for malicious 
intelligence gathering. So us saying "if you want to do this, use that" at 
least will cause future versions of things that relied on ANY to know what they 
are getting.

Also: this should probably one of the three threads on dn...@ietf.org...

--Paul Hoffman
___
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] Saga of HBONow DNSSEC Failure

[Eli Heady]

On Mar 10, 2015 12:16 PM, "Edward Lewis"  wrote:
>
...
> Perhaps Comcast could install little squirrel
> feeders in the neighborhood.
>

That they don't, and have let this problem go unabated for years,
illustrates their bias. #nutneutrality

Apologies,
Eli
___
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] CloudFlare policy on ANY records changing

[David C Lawrence]

Paul Hoffman writes:
> On Mar 10, 2015, at 8:46 AM, David C Lawrence  wrote:
> > One down side there, however, is that REFUSED as understood by
> > resolvers commonly has the semantic currently that the name is not
> > hosted by the server at all.
> 
> If a resolver is sending an ANY before it sends its actual request, that
> could be a problem. However, they shouldn't be doing that.

Yeah, we've well established they shouldn't.

Bad guys often don't care about what they shouldn't be doing, though,
and (untested assertion follows) using REFUSED responses for ANY
queries of random names could be a pretty useful vector for getting
all of the servers for a domain declared lame.

I'm not saying that ultimately the REFUSED approach is unworkable,
just that I'd like to see some practical testing of it in addition to
the support of the philosophical purity of it.


___
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] Saga of HBONow DNSSEC Failure

[Livingood, Jason]

On 3/10/15, 12:55 PM, "Eli Heady" 
mailto:eli.he...@gmail.com>> wrote:


On Mar 10, 2015 12:16 PM, "Edward Lewis" 
mailto:edward.le...@icann.org>> wrote:
>
...
> Perhaps Comcast could install little squirrel
> feeders in the neighborhood.
>

That they don't, and have let this problem go unabated for years, illustrates 
their bias. #nutneutrality

We can only take reasonable, fair, and transparently disclosed steps to prevent 
squirrels from eating coaxial cable or fiber optic cables. If we put extra 
layers of protection on cables to block feeding access specifically for 
squirrels, then of course we’d be blocking the squirrels’ access to the 
Internet (for nourishment and information). Such chew-blocking may be 
acceptable if it were on a species-neutral basis, preventing chewing equally by 
dogs, cats, owls, hawks, squirrels, bears, and others. But I’d probably have to 
run that past our Legal department. ;-)

JL
___
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] Saga of HBONow DNSSEC Failure

[Livingood, Jason]

On 3/10/15, 12:11 PM, "Edward Lewis"  wrote:

>I (as well as others) knew this day would come -
>when an ISP would get the brunt of someone's DNSSEC misfire.  (Others
>include many who worked on the original design and deployment workshops.)

It won¹t be the last time! ;-)

>The only way I can make this up to you is to better my efforts at making
>DNSSEC an easier to run, less clumsy protocol.

Works for me! That¹d be awesome. :-) DNSSEC needs to be super easy to use
as an authoritative operator, running on auto-pilot after initial setup.
The simpler & more automated operations are, the less fragile the signing
infrastructure will be (and the whole thing end to end of course).

- Jason


___
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] What would it take...

[Edward Lewis]

...to prevent another DS<-->DNSKEY mishap from happening again?

I'm presenting the message to the DNS Operations list of DNS-OARC.  (Being
subscribed to so many DNS lists I keep forgetting if I'm acting as an IETF
participant or talking as a past operator of DNS or as )

In short, think about when a name server loads a zone with a DNSKEY set in
it.  If, at the parent zone, there is a DS set and none of it's contents
refer to a record in the DNSKEY set, all DNSSEC validating queries will
declare everything in the zone broken.

So, why can't the name server find the DS set, run a check and barf if
there's a problem?  Barf - either refusing to load the zone or refusing to
change the zone that is already running.

Here are some impediments:

1) The entity responsible for the set up is not likely to be a programmer.
2) Authoritative servers don't launch queries.
3) Authoritative servers don't know anything about the parent zone.
4) The owners of the zone and the operator of the DNS are not always the
same entity (person, company).

#1 - The implications of this is - tools/components are needed.  One option
are management/diagnostic tools.  Another option is an embedded in the name
server component.  More tools is great when you are the jockey, more
embedded components is great when you are the customer.

#2 - Software can do what it wants - but sometimes hidden masters are
shielded with the public Internet.  (I'll assume the case is that the parent
and child zones are on separate sets of machines - when this is't true, we
don't have the problem.)  I bet though, that it wouldn't be hard to convince
the operators of hidden masters to allow them access port 53 outside the
firewall.

#3 - There's a brute force way to overcome this, come down the root to find
the cut point.  Or this can be configured somehow (but I hate pinning).  Or
maybe just doing a straight forward use of a validating recursive server
(but that's more tools, see #1).

#4 - This is a critical aspect of the problem.  Even if the customer tells
the DNS hosting company to roll keys, the customer has to be the one who
finds the registrar to ensure the DS set is correct in the registry.  That's
four participants with the most important (customer) the least capable (or
they probably wouldn't be a customer).  Failing to automate away the
customer's problem will kill the effort, certainly stall scaling.

The first step is for the operations community to cobble together a solution
to this problem.  Perhaps a proposal goes to the IETF for the proper review
and legal protection.  And if there's a need to change other policies, an
IETF document might be the greatest asset.

This is one way to make DNSSEC less clumsy.

Please - if there are more impediments, suggest them.  I may have missed
something.  If you disagree with an impediment, speak out.





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] What would it take...

[Mark Andrews]

In message , Edward Lewis writes:
> Content-transfer-encoding: 7bit
> 
> ...to prevent another DS<-->DNSKEY mishap from happening again?
> 
> I'm presenting the message to the DNS Operations list of DNS-OARC.  (Being
> subscribed to so many DNS lists I keep forgetting if I'm acting as an IETF
> participant or talking as a past operator of DNS or as )
> 
> In short, think about when a name server loads a zone with a DNSKEY set in
> it.  If, at the parent zone, there is a DS set and none of it's contents
> refer to a record in the DNSKEY set, all DNSSEC validating queries will
> declare everything in the zone broken.
> 
> So, why can't the name server find the DS set, run a check and barf if
> there's a problem?  Barf - either refusing to load the zone or refusing to
> change the zone that is already running.

Why don't we just implement TSIG signed updates to the parent and
send a UPDATE message to the parent?  What is so hard about a
username/password pair which is all that TSIG is.
 
> Here are some impediments:
> 
> 1) The entity responsible for the set up is not likely to be a programmer.

Doesn't matter. People do username/password pairs all the time.

> 2) Authoritative servers don't launch queries.

Has NEVER been true.  SOA/IXFR queries are done regularly by
authoritative servers.  For over the last decade queries for
nameserver addresses have been done for NOTIFY.

> 3) Authoritative servers don't know anything about the parent zone.

Discoverable.

> 4) The owners of the zone and the operator of the DNS are not always the
> same entity (person, company).

Doesn't matter.

> #1 - The implications of this is - tools/components are needed.  One option
> are management/diagnostic tools.  Another option is an embedded in the name
> server component.  More tools is great when you are the jockey, more
> embedded components is great when you are the customer.
> 
> #2 - Software can do what it wants - but sometimes hidden masters are
> shielded with the public Internet.  (I'll assume the case is that the parent
> and child zones are on separate sets of machines - when this is't true, we
> don't have the problem.)  I bet though, that it wouldn't be hard to convince
> the operators of hidden masters to allow them access port 53 outside the
> firewall.
> 
> #3 - There's a brute force way to overcome this, come down the root to find
> the cut point.  Or this can be configured somehow (but I hate pinning).  Or
> maybe just doing a straight forward use of a validating recursive server
> (but that's more tools, see #1).
> 
> #4 - This is a critical aspect of the problem.  Even if the customer tells
> the DNS hosting company to roll keys, the customer has to be the one who
> finds the registrar to ensure the DS set is correct in the registry.  That's
> four participants with the most important (customer) the least capable (or
> they probably wouldn't be a customer).  Failing to automate away the
> customer's problem will kill the effort, certainly stall scaling.
> 
> The first step is for the operations community to cobble together a solution
> to this problem.  Perhaps a proposal goes to the IETF for the proper review
> and legal protection.  And if there's a need to change other policies, an
> IETF document might be the greatest asset.
> 
> This is one way to make DNSSEC less clumsy.
> 
> Please - if there are more impediments, suggest them.  I may have missed
> something.  If you disagree with an impediment, speak out.

I've already submitted a draft that would make this all possible.

Sending signed UPDATE messages is relatively trivial.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: [nznog] DNSSEC validation at Spark NZ

[Sadiq Saif]

 Forwarded Message 
Subject: [nznog] DNSSEC validation at Spark NZ
Date: Tue, 10 Mar 2015 11:45:27 +1300
From: Sebastian Castro 
Organization: .nz Registry Services
To: nz...@list.waikato.ac.nz 

Hi:

We'd like to share a short technical blog post from NZRS about Spark NZ
enabling DNSSEC validation for part of their customers.

In brief, DNSSEC related traffic coming from Spark NZ resolvers suffered
a massive increase back on Dec 16th, Spark NZ also added new DNS
backends for their service, and they are using load balancing to share
the load.

The article
https://nzrs.net.nz/content/dnssec-validation-spark-nz

Feedback and questions are welcomed!

Cheers,
-- 
Sebastian Castro
Technical Research Manager
NZRS Ltd.
desk: +64 4 495 2337
mobile: +64 21 400535
___
NZNOG mailing list
nz...@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog


___
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] [DNSOP] dnsop-any-notimp violates the DNS standards

[Darcy Kevin (FCA)]

Regarding the statement "query type ANY 'matches all RR types CURRENTLY IN THE 
CACHE'."

Actually, there's nothing in RFC 1034 that clearly *mandates* this behavior -- 
Section 3.7.1 says only that a QTYPE of * "matches all RR types", whereas 
Section 5.3.3 ("Algorithm") says to return "the answer" or "the data" if it's 
in the cache, but this is ambiguous with respect to QTYPE=* (other than the 
highly-improbable case that we have RRsets for every possible RR type, how can 
we know we have "the answer"/"the data" in our cache, given that the QTYPE 
"matches all RR types" at the node and there might be other RRsets extant which 
don't happen to be cached at the time? Is an answer really "the" answer if we 
can't be sure that it satisfies the matching rule of the QTYPE definition?).

People cite the examples of Section 6.2.2 as definitive evidence that QTYPE=* 
queries can always be satisfied by whatever happens to be laying around in a 
cache, but they don't seem to notice that those were *non-recursive* queries in 
the examples, and it's their *non-recursiveness* that gives rise to the lack of 
rigor in returning a response (as it is whenever a non-recursive query is sent 
to a DNS entity that doesn't happen to be authoritative for the relevant zone). 
The required fetching behavior of a caching resolver in response to a 
*recursive* QTYPE=* query, is basically undefined by RFC 1034. Common practice 
is to treat QTYPE=* queries as effectively non-recursive, despite RD being set 
to 1, if *any* relevant RRset exists in the cache. Possibly, this is because 
the Section 6.2.2 examples were misunderstood. Or, simply because it was easier 
to code that way. A more modern concern would be that this rigor could be 
abused for possible DoS attacks. But, at this point in D!
 NS history, I doubt we can roll back the clock and force everyone to be 
rigorous in fetching answers for QTYPE=* queries. So the answers are inherently 
unreliable, and that situation is not likely to change, unless and until 
someone invents an "ALL" QTYPE/RR-type/meta-type. 


- Kevin

-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Wouters
Sent: Monday, March 09, 2015 10:48 AM
To: D. J. Bernstein
Cc: dn...@ietf.org; dns-operati...@dns-oarc.net
Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS 
standards

On Mon, 9 Mar 2015, D. J. Bernstein wrote:

> My "qmail" software is very widely deployed (on roughly 1 million SMTP 
> server IP addresses) and, by default, relies upon ANY queries in a way 
> that is guaranteed to work by the mandatory DNS standards.

And you've been told for two decades that this was wrong?

> Specifically, query type ANY "matches all RR types" for that node on 
> that server.

Wrong, query type ANY "matches all RR types CURRENTLY IN THE CACHE". So the 
result of qmail's ANY query is completely meaningless and qmail cannot derive 
any conclusion from the absence of any record from that query.

So if the MX or  record has expired from the cache but another RRtype with 
larger TTL (say NS) is still in there, your ANY query will fail to find 
records. qmail with this feature is broken.

Additionally, Tony Finch did a write up of qmail's ANY problems too:
https://fanf.livejournal.com/10.html

> In new software today I would sacrifice these efficiency benefits for 
> the sake of simplicity, but this doesn't mean that I'm going to 
> frivolously inflict retroactive punishment upon administrators who 
> have installed standards-compliant software and done nothing wrong.

You have had 10 years to fix it. Luckilly, I believe most distributions 
shipping qmail add the patch to fix this already.

> I understand how a sufficiently large site might acquire the 
> impression that it can safely take radical action at its own whim, 
> violating the existing protocol standards

Uhm, we pointd out qmail's _bug_ for a decade. I'm quite sure even you do not 
need to interop with BIND4 anymore.

> Apparently Firefox recently deployed ANY queries. I haven't looked at 
> the details but I gather that they're related to the well-known 
> annoyances of handling  etc. Firefox was browbeaten into reverting 
> this change on the basis of highly questionable claims regarding
> amplification: "It can return enormous result sets, and some 
> authoritative servers have taken to refusing ANY queries because of 
> the frequency with which such queries show up in amplification 
> attacks" -> "I'm concerned about amplification and the perception 
> thereof by security monitors."

No, they were also told that ANY queries only return data from the cache, and 
using ANY queries means you might miss actual A or  records. This has 
nothing to do with ANY queries and amplification.

> The common theme of CNAME/MX/A and A/ is that there's widepread 
> interest in being able to easily retrieve 

Re: [dns-operations] What would it take...

[Edward Lewis]

On 3/10/15, 16:45, "Mark Andrews"  wrote:
>
>Why don't we just implement TSIG signed updates...

In the sense of "baby steps first" - what I'm driving towards "error
detection", ensuring that the zone-to-be is in line with it's environment.
 Getting to "error correction" is the next level, but complicates things.

> 
>> Here are some impediments:
>> 
>> 1) The entity responsible for the set up is not likely to be a
>>programmer.
>
>Doesn't matter. People do username/password pairs all the time.

The point was missed - the solution to this has to rely on updating tools,
not expecting folks to modify code, write a few scripts, set up cron jobs.
 As someone familiar with coding, I could write this up for myself, but in
general operations staff aren't going to develop anything very detailed.

>> 2) Authoritative servers don't launch queries.
>
>Has NEVER been true.  SOA/IXFR queries are done regularly by
>authoritative servers.  For over the last decade queries for
>nameserver addresses have been done for NOTIFY.

Okay, but, the queries are sent to IP addresses held in configurations or
in authoritative data, not relying on what is learned at sea.  They
certainly don't iterate.

I could quibble and say that messages sent by AXFR clients (RFC 5936),
which are called queries, aren't exactly the same as queries sent when
resolving a name - they share format and software but the trust model is
different.  And that matters here because I've held the belief that
authoritative servers do not want to base their answers (authoritative
answers) on information learned from outside their bailiwick.

>> 3) Authoritative servers don't know anything about the parent zone.
>
>Discoverable.

True, unless (as mentioned later) the master is firewalled off from the
Internet (okay, lame argument).  Yet we don't have tools that do this.
Why not?

>> 4) The owners of the zone and the operator of the DNS are not always the
>> same entity (person, company).
>
>Doesn't matter.

(I don't know what you mean by "doesn't matter" other than you are
disagreeing.)

I raised this impediment to try to point the solution into tools (and
standards) and not relying on processes.  The world we live in has managed
to build business relationships that do not align with the needed
communications to make things work smoothly.  (This is why I called DNSSEC
"clumsy" at a Centr meeting in October 2013 - clumsy as in, it can be made
to work but needs more expertise than is evidently available in the labor
market.  Evident by the frequency of defects.)

>I've already submitted a draft that would make this all possible.
>
>Sending signed UPDATE messages is relatively trivial.

Which one?  Is there an implementation of this?  Any operational
experience?


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] CloudFlare policy on ANY records changing

[Fred Morris]

On Tue, 10 Mar 2015, Chris Adams wrote:
> A problem with ever using ANY to get "more information" from a cache is
> the client's/applications's assumption that all requests will go to the
> same server.  Even if a client sends requests to the same IP, anycast
> can mean they go to a different server.

So so true. You can use it in some vague way to fingerprint anycast
DNS services. DAMHIK!

--

Fred Morris

___
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 would it take...

[Mark Andrews]

In message , Edward Lewis writes:
> >
> >Why don't we just implement TSIG signed updates...
> 
> In the sense of "baby steps first" - what I'm driving towards "error
> detection", ensuring that the zone-to-be is in line with it's environment.
> Getting to "error correction" is the next level, but complicates things.

Why do we need "baby steps"?  

> >> Here are some impediments:
> >> 
> >> 1) The entity responsible for the set up is not likely to be a
> >>programmer.
> >
> >Doesn't matter. People do username/password pairs all the time.
> 
> The point was missed - the solution to this has to rely on updating tools,
> not expecting folks to modify code, write a few scripts, set up cron jobs.
>  As someone familiar with coding, I could write this up for myself, but in
> general operations staff aren't going to develop anything very detailed.

key "user" {
algorithm "hmac-sha256";
secret "";
};

zone example.net {
...
dnssec-update-parent { key user [server  ] };
};

or

zone example.net {
...
dnssec-update-parent {
name "user";
password "";
[parent ];
[server ];
[port ];
};
};

The server would then use the credentials to send a signed update
request with the required DS records.  It is trivial to work out
the parent zone provided normal delegations are being done.  It is
also possible to find where to send the update requests to
automatically.

> >> 2) Authoritative servers don't launch queries.
> >
> >Has NEVER been true.  SOA/IXFR queries are done regularly by
> >authoritative servers.  For over the last decade queries for
> >nameserver addresses have been done for NOTIFY.
> 
> Okay, but, the queries are sent to IP addresses held in configurations or
> in authoritative data, not relying on what is learned at sea.  They
> certainly don't iterate.

Yes, they do iterate and have done for over 15 years now.  Just
because you havn't noticed that they do this doesn't mean that it
is not been being done.

> I could quibble and say that messages sent by AXFR clients (RFC 5936),
> which are called queries, aren't exactly the same as queries sent when
> resolving a name - they share format and software but the trust model is
> different.  And that matters here because I've held the belief that
> authoritative servers do not want to base their answers (authoritative
> answers) on information learned from outside their bailiwick.
> 
> >> 3) Authoritative servers don't know anything about the parent zone.
> >
> >Discoverable.
> 
> True, unless (as mentioned later) the master is firewalled off from the
> Internet (okay, lame argument).  Yet we don't have tools that do this.
> Why not?

nsupdate will update the parent zone automatically if the first
record of the update section is a DS record (remove or add).

6ffc3748 (Mark Andrews   2010-05-18 06:18:23 + 3093)
tmprdataset = ISC_LIST_HEAD(firstname->list);
64c43af4 (Mark Andrews   2010-03-09 03:46:12 + 3094)
if (section == DNS_SECTION_UPDATE &&
64c43af4 (Mark Andrews   2010-03-09 03:46:12 + 3095)
!dns_name_equal(firstname, dns_rootname) &&
6ffc3748 (Mark Andrews   2010-05-18 06:18:23 + 3096)
tmprdataset->type == dns_rdatatype_ds) {
64c43af4 (Mark Andrews   2010-03-09 03:46:12 + 3097)
unsigned int labels = dns_name_countlabels(name);
64c43af4 (Mark Andrews   2010-03-09 03:46:12 + 3098)
dns_name_getlabelsequence(name, 1, labels - 1, name);
64c43af4 (Mark Andrews   2010-03-09 03:46:12 + 3099)
}

It could be made more robust by looping over all the update section
looking for DS records but it works for the usual case.

For NS it needs to be a explict decision as they exist at both the parent
and the child.  I have a feature request to add a "at parent" directive
to nsupdate to handle this.

The following will send a signed update to the parent zone.

% nsupdate
key name secret
update del zone ds
update add zone ttl ds ...
send
quit
%

> >> 4) The owners of the zone and the operator of the DNS are not always the
> >> same entity (person, company).
> >
> >Doesn't matter.
> 
> (I don't know what you mean by "doesn't matter" other than you are
> disagreeing.)

It doesn't matter.  All that matters is that credentials to do the
update are with the party that needs to initiate the update.

> I raised this impediment to try to point the solution into tools (and
> standards) and not relying on processes.  The world we live in has managed
> to build business relationships that do not align with the needed
> communications to make things work smoothly.  (This is why I called DNSSEC
> "clumsy" at a Centr meeting in October 2013 - clumsy as in, it can be made
> to work but needs more expertise than is evidently availab

Re: [dns-operations] What would it take...

[P Vixie]

Tsig won't scale for something like this. Please consider sig0.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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 would it take...

[Mark Andrews]

In message <1fb3db93-eb08-4864-9d3c-e48da9fc5...@redbarn.org>, P Vixie writes:
> Tsig won't scale for something like this. Please consider sig0.

I've got no objection to sig(0) but why won't it scale?  There is
a existing relationship so public key cyptography isn't needed.
Sig(0) would require the KEY record to be in the parent zone or to
be held by the registrar in a seperate database.  In the later case
you either need a database of KEY records or a database of TSIG
keys.  As far as I can tell there is no difference in the scaling
requirements.

Sig(0) might be marginally more secure as only one side holds
material than needs to be kept private.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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