Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

[Paul Vixie]

On Friday, April 7, 2017 12:51:40 AM GMT David Conrad wrote:
> Paul,
> 
> On Apr 6, 2017, 2:24 PM -1000, Paul Vixie , wrote:
> > the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or
> > non-experienced or non-protocol-geeks;
> ... This strikes me as a bit more complicated than 7706. YMMV.

yes, it does.

> > and both approaches are appropriate only for closed internal networks
> > where the configuration is controlled by a single administration.
> If I set up an open resolver using 7706, what negative repercussions do you
> see?

you'll need some name server features that aren't otherwise standardized, and 
maybe a 
patch or two. in my preferred approach, you just load a zone, because all of 
the special 
logic is outside of the name server and its configuration.

> > the misstatement is, dnssec's purpose is not defeated, because iana's
> > signatures are checked before the zone is accepted, and new signatures
> > are added using local keys before publication.
> Meaningless given you are explicitly editing the zone as published from and
> signed by the authority.

i hear you say meaningless, but i know that you know the difference between a 
name 
space and a zone that implements that namespace, and i know you've read my 
explainations about the importance of that distinction. it's not meaningless.

> You claim you aren't modifying the namespace
> content (well, except for the root NSes), ...

what is namespace content? i know namespaces, and i know zone content.

> but the point of DNSSEC and the
> rather Byzantine structures we've built around establishing trust is that
> we don't have to believe you: you can see _everything_ having to do with
> creating the trust anchor and everything down to the leaf.

that point is not lost. dig +trace +dnssec works as expected. transitive trust 
is a real thing: 
if i trust where i got the data, because i verified the signatures, and i trust 
my own keys 
and signatures, then trading one set of trust anchors and signatures for 
another lost me 
no root-to-leaf trust, in the eyes of my target audience, who is in the case of 
my laptop, 
me.

> The only advantage(?) I see in your approach is that is allows (forces) you
> to play around with the namespace and re-sign.

it plays around with the zone content. not the namespace.

> Might be useful for neo maxi
> zoom DNSSEC nerd experimentation, however as mentioned previously, that
> doesn't strike me as something one might recommend lightheartedly.

note that since many enterprise networks do augment the iana namespace for 
internal 
use (creating problems like .home and .corp collisions), there is often a loss 
of dnssec 
integrity. my approach is one way to retain dnssec integrity in that situation, 
and has not 
been recommended lightheartedly.

> > for my many-vm's laptop environment, running on a loopback isn't a
> > solution.
> I strongly suspect you could come up with a solution that didn't use
> loopback but which also didn't require modifying the root zone, resigning
> it, and getting all relying devices to use both your NS hints and trust
> anchor. Like, perhaps running on a non-loopback address within your flock
> of laptop VMs?

i do run on a non-loopback address within my vm-local network. but unless i 
pirate the 
addresses of all the real root name servers (which i won't do), or re-sign the 
iana content 
with a local NS RRset and trust anchoe (which i am doing), then cache priming 
is going to 
cause my hints to be ignored by the other rdns servers local to me.

note that very few people will ever run multiple rdns servers inside a laptop. 
i am not 
suggesting that my use case is or will ever be common. but it works.

at a slightly broader scale, for instance my home network, it would also work. 
however, i'm 
using the yeti system here, so i can't experiment separately.

at enterprise scale, or metro or region or national scale, it would also work.

as you know i've suggested for some time now that iana build and sign a second 
root 
zone, having the same name space (which is regulated by icann and ietf) but 
having a 
different apex NS RRset (which i think can be regulated differently.) iana is 
in a perfect 
position to sign its zone using NS RR's and associated  RR's that lead to 
addresses i 
*would* be willing to pirate. this is also called "the AS112 unowned anycast 
approach".

if i could slave an iana-signed zone on my laptop that already had pirateable 
IP addresses 
reached by hints and the apex NS RRset, i would not need Perl to do what i'm 
doing. and i 
would be using the iana trust anchor. and it would be a configuration that i 
would 
recommend for all internet users.

sadly, a lot of people saying that "the namespace and the zone are the same 
thing" has 
kept that door pretty well closed. so, here i am with Perl instead.

> > http://www.circleid.com/posts/20160330_let_me_make_yeti_dns_perfectly_clear/
> Saw that a year ago and still think it 

Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

[David Conrad]

Paul,

On Apr 6, 2017, 2:24 PM -1000, Paul Vixie , wrote:
> the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or 
> non-experienced or non-protocol-geeks;

7706 doesn't recommend editing someone else's zone file, re-signing it, and 
figuring out how to replicate the hints and trust anchor to _all_ relying 
devices (and restoring the real hints/trust anchor when you're done). This 
strikes me as a bit more complicated than 7706. YMMV.

> and both approaches are appropriate only for closed internal networks where 
> the configuration is controlled by a single administration.

If I set up an open resolver using 7706, what negative repercussions do you see?

> the misstatement is, dnssec's purpose is not defeated, because iana's 
> signatures are checked before the zone is accepted, and new signatures are 
> added using local keys before publication.

Meaningless given you are explicitly editing the zone as published from and 
signed by the authority. You claim you aren't modifying the namespace content 
(well, except for the root NSes), but the point of DNSSEC and the rather 
Byzantine structures we've built around establishing trust is that we don't 
have to believe you: you can see _everything_ having to do with creating the 
trust anchor and everything down to the leaf.

The only advantage(?) I see in your approach is that is allows (forces) you to 
play around with the namespace and re-sign. Might be useful for neo maxi zoom 
DNSSEC nerd experimentation, however as mentioned previously, that doesn't 
strike me as something one might recommend lightheartedly.

> for my many-vm's laptop environment, running on a loopback isn't a solution.

I strongly suspect you could come up with a solution that didn't use loopback 
but which also didn't require modifying the root zone, resigning it, and 
getting all relying devices to use both your NS hints and trust anchor. Like, 
perhaps running on a non-loopback address within your flock of laptop VMs?

> http://www.circleid.com/posts/20160330_let_me_make_yeti_dns_perfectly_clear/

Saw that a year ago and still think it post-hoc rationalization and specious, 
but I'm sure that's just me.

Regards,
-drc

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

[Paul Vixie]

On Thursday, April 6, 2017 11:53:25 PM GMT David Conrad wrote:
> On Apr 6, 2017, 2:32 AM -1000, Paul Vixie , wrote:
> > if you want to run yeti-style, there are some perl scripts that will
> > fetch and verify the root zone, edit the apex NS and DNSKEY RRsets,
> > re-sign with your local key, and give you a zone you can run on several
> > servers inside your internal network, such that you can point your
> > "hints" and your dnssec anchor at servers you control, for all your
> > internal-network recursives,
> 
> Not so sure this is something I'd go about recommending to pretty much
> anyone other than hardcore, very experienced DNS/DNSSEC protocol geeks
> since it pretty much defeats the purpose of DNSSEC (edit the apex? ugh) and
> requires all relying devices to configure a "non-default" trust anchor or
> suffer SERVFAILs.

other than one proviso and one misstatement, i agree with this.

the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or non-
experienced or non-protocol-geeks; and both approaches are appropriate only for 
closed 
internal networks where the configuration is controlled by a single 
administration.

the misstatement is, dnssec's purpose is not defeated, because iana's 
signatures are 
checked before the zone is accepted, and new signatures are added using local 
keys 
before publication.

for my many-vm's laptop environment, running on a loopback isn't a solution.

see also:

http://www.circleid.com/posts/20160330_let_me_make_yeti_dns_perfectly_clear/

vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

[David Conrad]

On Apr 6, 2017, 2:32 AM -1000, Paul Vixie , wrote:

> if you want to run yeti-style, there are some perl scripts that will
> fetch and verify the root zone, edit the apex NS and DNSKEY RRsets,
> re-sign with your local key, and give you a zone you can run on several
> servers inside your internal network, such that you can point your
> "hints" and your dnssec anchor at servers you control, for all your
> internal-network recursives,

Not so sure this is something I'd go about recommending to pretty much anyone 
other than hardcore, very experienced DNS/DNSSEC protocol geeks since it pretty 
much defeats the purpose of DNSSEC (edit the apex? ugh) and requires all 
relying devices to configure a "non-default" trust anchor or suffer SERVFAILs.

Regards,
-drc


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-00.txt

[Wes Hardaker]

Bob Harold  writes:

> This one still needs to be fixed:

Thanks Bob.  That was a straight copy; I hope to do a new 
version immediately and will certainly make that change.
-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in state "Candidate for WG Adoption"

[Bob Harold]

On Tue, Mar 28, 2017 at 4:34 PM, IETF Secretariat <
ietf-secretariat-re...@ietf.org> wrote:

>
> The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in
> state
> Candidate for WG Adoption (entered by Tim Wicinski)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-
> tcp-requirements/
>
>
I support adoption and will review.

Minor nit:
6.5. IETF RFC 7873 - Domain Name System (DNS) Cookies

"...  should consider accept TCP ..."
change to:
"... should consider accepting TCP ..."

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New terminology for root name service

[Dan York]

On Apr 6, 2017, at 11:25 AM, Matthew Pounsett 
> wrote:



On 15 March 2017 at 13:31, Paul Hoffman 
> wrote:
Greetings again. RSSAC has published a lexicon of terms that are commonly used 
with respect to the root of the public DNS, but are not in RFC 7719. I have 
opened an issue for the terminology-bis document at 
https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/17 and would 
be intereted to hear what people think about including those terms in our 
document.


Hi Paul.  Noting there hasn't been any actual feedback on your question ... I 
think the -bis document should at least reference RSAAC026, but I think 
importing those terms (particularly the ones that are not root-specific: 
instance, publish, serve) would be useful.

Agree with Matthew (and others) that RSAAC026 should be referenced. Also agree 
that "instance", "publish" and "server" would be useful additions. I don't know 
that the specific root zone terms need to be incorporated.

I guess a general question would be (and I don't know the answer): do we 
anticipate creating RFCs that define operations and protocols used within the 
root zone?  If yes or "maybe", we should incorporate the terms.  If "probably 
not" or "no", then there could just be a new section about "Root Zone 
terminology" that specifically directs people to view RSAAC026 (and successor 
documents).

My 2 cents,
Dan

--
Dan York
Senior Manager, Content & Web Strategy, Internet Society
y...@isoc.org   +1-603-439-0024
Jabber: y...@jabber.isoc.org  Skype: danyork   
http://twitter.com/danyork

http://www.internetsociety.org/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New terminology for root name service

[Matthew Pounsett]

On 15 March 2017 at 13:31, Paul Hoffman  wrote:

> Greetings again. RSSAC has published a lexicon of terms that are commonly
> used with respect to the root of the public DNS, but are not in RFC 7719. I
> have opened an issue for the terminology-bis document at
> https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/17 and
> would be intereted to hear what people think about including those terms in
> our document.
>
>
Hi Paul.  Noting there hasn't been any actual feedback on your question ...
I think the -bis document should at least reference RSAAC026, but I think
importing those terms (particularly the ones that are not root-specific:
instance, publish, serve) would be useful.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-00.txt

[Tony Finch]

Jelte Jansen  wrote:
>
> We can certainly discuss alternative schemes, RSASSA-PSS is a potential
> alternative, which I understand is considered (much?) better. It has a
> big drawback though, in that it requires salt, which can be a big issue
> for large deployments.

As I understand it the deterministic DSA trick (RFC 6979) also works for
RSA SSA PSS.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
South Plymouth, North Biscay: Easterly or northeasterly 4 or 5. Moderate,
occasionally rough at first in north Biscay. Fair. Moderate or good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

[Paul Vixie]

Bjørn Mork wrote:
> Tony Finch  writes:
...
>> You might be able to work around the problem by adding a
>> match-recursion-only option to the recursive view, and adding a
>> non-recursive view that has allow-query-cache, and use attach-cache
>> so all views share the same cache. I have not tried this :-)
> 
> And the main objection I hear wrt RFC7706 is that it complicates the
> config :)

if you want to run yeti-style, there are some perl scripts that will
fetch and verify the root zone, edit the apex NS and DNSKEY RRsets,
re-sign with your local key, and give you a zone you can run on several
servers inside your internal network, such that you can point your
"hints" and your dnssec anchor at servers you control, for all your
internal-network recursives, the code is here:

https://github.com/BII-Lab/Yeti-Project/tree/master/script/TISF

note, my internal-network is the virtualbox shared network on my own
laptop, so while this is a complex approach, it's fewer moving parts for
me than RFC 7706 would have been.

-- 
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

[Tony Finch]

Bjørn Mork  wrote:
>
> Recently I noticed a side effect of this configuration which I consider
> unwanted and unexpected: It changes how BIND replies to requests without
> the RD bit set. BIND will normally answer such requests with a "best
> possible redirection", using any matching NS set it has in its cache.
> Which often will be the root NS.  But using the RFC7706 example config,
> BIND will REFUSE all requests without RD set.

I agree this behaviour is unhelpful and weird. It seems to come from the
following bit of the source, though the comment doesn't help very much to
explain the whys or wherefores.
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=bin/named/query.c;h=0cfdf9288fb16a8f991e7a31f3248118add691d5;hb=HEAD#l1040

/*
 * Non recursive query to a static-stub zone is prohibited; its
 * zone content is not public data, but a part of local configuration
 * and should not be disclosed.
 */
if (dns_zone_gettype(zone) == dns_zone_staticstub &&
!RECURSIONOK(client)) {
return (DNS_R_REFUSED);
}

You might be able to work around the problem by adding a
match-recursion-only option to the recursive view, and adding a
non-recursive view that has allow-query-cache, and use attach-cache
so all views share the same cache. I have not tried this :-)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire, South Utsire, Northeast Forties: Westerly 5 to 7,
occasionally gale 8 at first in Viking and South Utsire, veering northwesterly
5 or 6. Rough, becoming moderate later. Occasional drizzle, fog patches
developing. Moderate, occasionally very poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

[Bjørn Mork]

Hello,

We are currently trying out the configuration recommended by RFC7706,
serving a copy of the root zone on a loopback.  We are using BIND 9.10
and our configuration is directly copied from the example in appendix
B.1.  Even down to the actual loopback address used, as we needed a
dedicated one for this instance anyway.

Recently I noticed a side effect of this configuration which I consider
unwanted and unexpected: It changes how BIND replies to requests without
the RD bit set. BIND will normally answer such requests with a "best
possible redirection", using any matching NS set it has in its cache.
Which often will be the root NS.  But using the RFC7706 example config,
BIND will REFUSE all requests without RD set.

For the record, my expectations are: Absolutely no visible effects to
any DNS clients compared to a normal caching resolver, using the real
root servers directly.



Using the RFC7706 appedix B.1 example config, this is what I see:


bjorn@miraculix:~$ dig . soa @::1 +norecur

; <<>> DiG 9.10.3-P4-Debian <<>> . soa @::1 +norecur
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 49721
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.  IN  SOA

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Apr 06 10:25:30 CEST 2017
;; MSG SIZE  rcvd: 28


Snooping on the loopback interface, shows that the query is refused
without being referred to the local root instance (which makes sort of
sense, as that would be recursion...):

1 0.0   ::1 → ::1  Standard query 0xc239 SOA  
OPT 92 DNS
2 0.93346   ::1 → ::1  Standard query response 0xc239 
Refused SOA  OPT 92 DNS


Removing the local root zone, letting BIND fall back to its built-in
hint zone:

   view recursive {
   dnssec-validation auto;
   allow-recursion { any; };
   recursion yes;
  /* zone "." {
   type static-stub;
   server-addresses { 127.12.12.12; };
   };
 */
   };


changes this behaviour.  BIND now replies with NOERROR and an AUTHORITY
section from its hints (or actually from the cache. Note the AD flag):

bjorn@miraculix:~$ dig . soa @::1 +norecur

; <<>> DiG 9.10.3-P4-Debian <<>> . soa @::1 +norecur
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29060
;; flags: qr ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.  IN  SOA

;; AUTHORITY SECTION:
.   518378  IN  NS  a.root-servers.net.
.   518378  IN  NS  g.root-servers.net.
.   518378  IN  NS  m.root-servers.net.
.   518378  IN  NS  j.root-servers.net.
.   518378  IN  NS  h.root-servers.net.
.   518378  IN  NS  e.root-servers.net.
.   518378  IN  NS  f.root-servers.net.
.   518378  IN  NS  k.root-servers.net.
.   518378  IN  NS  d.root-servers.net.
.   518378  IN  NS  l.root-servers.net.
.   518378  IN  NS  i.root-servers.net.
.   518378  IN  NS  c.root-servers.net.
.   518378  IN  NS  b.root-servers.net.

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Apr 06 10:18:43 CEST 2017
;; MSG SIZE  rcvd: 239



Snooping on "any" reveals that there is no recursion in this case
either, as expected.  The data source is the cache:

1 0.0   ::1 → ::1  Standard query 0x7184 SOA  
OPT 92 DNS
2 0.000213074   ::1 → ::1  Standard query response 0x7184 
SOA  NS a.root-servers.net NS g.root-servers.net NS m.root-servers.net NS 
j.root-servers.net NS h.root-servers.net NS e.root-servers.net NS 
f.root-servers.net NS k.root-servers.net NS d.root-servers



The problem is that configuring a "static-stub" root zone changes how
BIND handles non RD requests.  Note that this affects *any* such
request, not only requests for root.  Example with the "static-stub"
root zone enabled:

bjorn@miraculix:~$ dig ns mork.no @::1 +norecur

; <<>> DiG 9.10.3-P4-Debian <<>> ns mork.no @::1 +norecur
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34742
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mork.no.   IN  NS

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Apr 06 10:32:45 CEST 2017
;; MSG SIZE  rcvd: 36

1 0.0   ::1 → ::1  Standard query 0x87b6 NS mork.no 
OPT 100 DNS

Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-00.txt

[Jelte Jansen]

On 2017-04-05 16:50, Mukund Sivaraman wrote:
>> Also, it is weird that a draft that is about having a fallback if a hash
>> algorithm becomes weakened uses the RSASSA-PKCS1-v1_5 signature scheme,
>> given that PKCS1 1.5 is already known to be weakened.
> 
> It was to allow simple addition of the algorithm to existing
> implementations. However, in light of your comment, we'll discuss
> revising it.
> 

We can certainly discuss alternative schemes, RSASSA-PSS is a potential
alternative, which I understand is considered (much?) better. It has a
big drawback though, in that it requires salt, which can be a big issue
for large deployments.

An advantage would be that then we not only have an alternative within
the RSA family for SHA2, but also for the signature scheme itself.

Speaking of the use-case to pick up this work; IMO having more
cryptographic algorithms ready for use is generally a good thing; we
don't have to wait until the existing ones are completely broken :)

Jelte



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop