subject:"Inline signing fails dnsviz test."

Re: Inline signing fails dnsviz test - STILL [LONG]

2021-05-16 Thread G.W. Haywood via bind-users


Hello again,

On Sun, 16 May 2021, I wrote:


...  If you can't agree their numbers then
you're some information ...


Having screen troubles.  The word 'missing' is missing.

--

73,
Ged.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

2021-05-16 Thread G.W. Haywood via bind-users


Hi there,

On Sun, 16 May 2021, Dan Egli wrote:

... I'm aware of the buddyns.com servers not responding. Noting I can 
do about that. They CLAIM I've had over 300k requests in the last couple 
of weeks and have exceeded my monthly cap. I say Bull Crap ...


I'd be inclined to believe them, but you could monitor the traffic
directly e.g. with tcpdump.  If you can't agree their numbers then
you're some information, I'd be dissatisfied with that.

But FWIW I've no complaints about the service from Hurricane Electric.

Meanwhile, I found that the google nameservers are currently not working 
either. I can query my domain at places like 1.1.1.1 and 1.0.0.1 no 
problem. But if I query at 8.8.8.8 or 8.8.4.4 I get servfail even though 
I have completely disabled DNSSEC for this zone.


Something somewhere seems, er, unusual.

Your problems aren't being compounded by some dumb firewall are they?

Some long TTL?

Just shootin' the fish, I don't know nearly as much about this stuff
at the guys already helping you.

--

73,
Ged.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

2021-05-16 Thread Ondřej Surý

Even jupiter.eglifamily.name. doesn’t return DNSSEC signed zone:

$ dig +norec +dnssec IN mx newideatest.site @jupiter.eglifamily.name.

; <<>> DiG 9.17.11-1+0~20210318.53+debian10~1.gbp0184f1-Debian <<>> +norec 
+dnssec IN mx newideatest.site @jupiter.eglifamily.name.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41775
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 4f4d8ab87a8cc424010060a0e1211ad492152d054053 (good)
;; QUESTION SECTION:
;newideatest.site.  IN  MX

;; ANSWER SECTION:
newideatest.site.   120 IN  MX  0 athena.newideatest.site.
newideatest.site.   120 IN  MX   gw.kictanet.or.ke.

;; Query time: 152 msec
;; SERVER: 209.141.58.25#53(jupiter.eglifamily.name.) (UDP)
;; WHEN: Sun May 16 11:08:49 CEST 2021
;; MSG SIZE  rcvd: 129

First fix this ^^^

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

> On 16. 5. 2021, at 10:47, Dan Egli  wrote:
> 
> Yea, I'm aware of the buddyns.com servers not responding. Noting I can do 
> about that. They CLAIM I've had over 300k requests in the last couple of 
> weeks and have exceeded my monthly cap. I say Bull Crap and am looking to 
> move to different servers.
> 
> Meanwhile, I found that the google nameservers are currently not working 
> either. I can query my domain at places like 1.1.1.1 and 1.0.0.1 no problem. 
> But if I query at 8.8.8.8 or 8.8.4.4 I get servfail even though I have 
> completely disabled DNSSEC for this zone.
> 
> Once I get rid of BuddyNS and place it with a working secondary I'll re-apply 
> the DNSSEC setup and try again.
> 
> On 5/16/2021 1:03 AM, Ondřej Surý wrote:
>> I think Mark jumped on something else, your zone is seriously broken and not 
>> because of DNSSEC:
>> 
>> https://dnssec-analyzer.verisignlabs.com/newideatest.site 
>> 
>> 
>> All of these NSes must have the correct zone content and not be broken:
>> 
>> newideatest.site.   3600IN  NS  jupiter.eglifamily.name.
>> newideatest.site.   3600IN  NS  
>> uz5qfm8n244kn4qz8mh437w9kzvpudduwyldp5361v9n0vh8sx5ucu.free.ns.buddyns.com.
>> newideatest.site.   3600IN  NS  
>> uz5154v9zl2nswf05td8yzgtd0jl6mvvjp98ut07ln0ydp2bqh1skn.free.ns.buddyns.com.
>> newideatest.site.   3600IN  NS  
>> uz52u1wtmumlrx5fwu6nmv22ntcddxcjjw41z8sfd6ur9n7797lrv9.free.ns.buddyns.com.
>> newideatest.site.   3600IN  NS  
>> uz5w6sb91zt99b73bznfkvtd0j1snxby06gg4hr0p8uum27n0hf6cd.free.ns.buddyns.com.
>> 
>> --
>> Ondřej Surý — ISC (He/Him)
>> 
>> My working hours and your working hours may be different. Please do not feel 
>> obligated to reply outside your normal working hours.
>> 
>>> On 16. 5. 2021, at 8:45, Dan Egli via bind-users  
>>> wrote:
>>> 
>>> Upgrade to WHAT? You said it was fixed in 9.11.25, but isn't that a lot 
>>> OLDER than 9.16.15, which is what I'm running?
>>> jupiter ~ # named -v
>>> BIND 9.16.15 (Stable Release) 
>>> jupiter ~ # dig -v
>>> DiG 9.16.15
>>> 
>>> 
>>> On 5/16/2021 12:06 AM, Mark Andrews wrote:
 
> On 16 May 2021, at 10:17, Dan Egli via bind-users 
>  wrote:
> 
> On 5/10/2021 12:38 PM, Tony Finch wrote:
>> Dan Egli 
>>  wrote:
>> 
>>> Still not working for me. The dig doesn't report anything, and I don't 
>>> HAVE a
>>> keyfile since i'm using inline signing. Or does inline signing still 
>>> require a
>>> key to be generated?
>>> 
>> Yes, you need to do your own key management with inline-signing using
>> dnssec-keygen. The new dnssec-policy feature can do automatic key
>> management for you.
>> 
>> Tony.
>> 
> So, I updated the settings. Now I have keyfiles generated by bind, as 
> well as a binary .zone.signed in addition to the plain text .zone which 
> has no DNSSEC information at all in it. I ran the signing routine and 
> bind said it was signed good. So I obtained the DS and put in the 
> registrar. Now I am getting SERVFAIL errors whenever I try to query my 
> zone from another name server. Here's what I did:
> 
> #dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
> newideatest.site. IN DS 49236 13 2 
> 
> Ok. Copy the long hash to the Registrar, plug it in. Check, done that.
> 
>  # dig mx newideatest.site @8.8.4.4
> 
> ; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;newideatest.site.  IN  MX
> 
> ;; Query time: 50 msec
> ;; SERVER: 8.8.4.4#53(8.8.4.4)
> ;; WHEN: S

Re: Inline signing fails dnsviz test - STILL [LONG]

2021-05-16 Thread Dan Egli via bind-users

Yea, I'm aware of the buddyns.com servers not responding. Noting I can 
do about that. They CLAIM I've had over 300k requests in the last couple 
of weeks and have exceeded my monthly cap. I say Bull Crap and am 
looking to move to different servers.


Meanwhile, I found that the google nameservers are currently not working 
either. I can query my domain at places like 1.1.1.1 and 1.0.0.1 no 
problem. But if I query at 8.8.8.8 or 8.8.4.4 I get servfail even though 
I have completely disabled DNSSEC for this zone.


Once I get rid of BuddyNS and place it with a working secondary I'll 
re-apply the DNSSEC setup and try again.


On 5/16/2021 1:03 AM, Ondřej Surý wrote:
I think Mark jumped on something else, your zone is seriously broken 
and not because of DNSSEC:


https://dnssec-analyzer.verisignlabs.com/newideatest.site 



All of these NSes must have the correct zone content and not be broken:

newideatest.site.       3600    IN      NS  jupiter.eglifamily.name.
newideatest.site.       3600    IN      NS 
 uz5qfm8n244kn4qz8mh437w9kzvpudduwyldp5361v9n0vh8sx5ucu.free.ns.buddyns.com.
newideatest.site.       3600    IN      NS 
 uz5154v9zl2nswf05td8yzgtd0jl6mvvjp98ut07ln0ydp2bqh1skn.free.ns.buddyns.com.
newideatest.site.       3600    IN      NS 
 uz52u1wtmumlrx5fwu6nmv22ntcddxcjjw41z8sfd6ur9n7797lrv9.free.ns.buddyns.com.
newideatest.site.       3600    IN      NS 
 uz5w6sb91zt99b73bznfkvtd0j1snxby06gg4hr0p8uum27n0hf6cd.free.ns.buddyns.com.


--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do 
not feel obligated to reply outside your normal working hours.


On 16. 5. 2021, at 8:45, Dan Egli via bind-users 
 wrote:


Upgrade to WHAT? You said it was fixed in 9.11.25, but isn't that a 
lot OLDER than 9.16.15, which is what I'm running?

jupiter ~ # named -v
BIND 9.16.15 (Stable Release) 
jupiter ~ # dig -v
DiG 9.16.15


On 5/16/2021 12:06 AM, Mark Andrews wrote:


On 16 May 2021, at 10:17, Dan Egli via bind-users 
 wrote:


On 5/10/2021 12:38 PM, Tony Finch wrote:

Dan Egli 
 wrote:

Still not working for me. The dig doesn't report anything, and I 
don't HAVE a
keyfile since i'm using inline signing. Or does inline signing 
still require a

key to be generated?


Yes, you need to do your own key management with inline-signing using
dnssec-keygen. The new dnssec-policy feature can do automatic key
management for you.

Tony.

So, I updated the settings. Now I have keyfiles generated by bind, 
as well as a binary .zone.signed in addition to the plain text 
.zone which has no DNSSEC information at all in it. I ran the 
signing routine and bind said it was signed good. So I obtained the 
DS and put in the registrar. Now I am getting SERVFAIL errors 
whenever I try to query my zone from another name server. Here's 
what I did:


#dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - 
newideatest.site

newideatest.site. IN DS 49236 13 2 

Ok. Copy the long hash to the Registrar, plug it in. Check, done that.

 # dig mx newideatest.site @8.8.4.4

; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;newideatest.site.  IN  MX

;; Query time: 50 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Sat May 15 18:12:44 MDT 2021
;; MSG SIZE  rcvd: 45
ServFail?! WHAT?
This is a known bug fixed in BIND 9.11.25.  Upgrade.  Once the DS is 
added to .site for

newideatest.site the resolution will work.



--
Dan Egli
From my Test Server


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


ISC funds the development of this software with paid support 
subscriptions. Contact us at https://www.isc.org/contact/ for more 
information.



bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


--
Dan Egli
From my Test Server



OpenPGP_0x11B7451DF2015959.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

2021-05-16 Thread Mark Andrews

Sorry, miss read your version 11 vs 16.  That said it is hard to work out what 
is going wrong when
you keep changing things and don’t actually have nameservers that are 
responding.   You had servers
that where giving DNSSEC responses, then ones that are returning unsigned 
responses and now ones
that are not answering.

> On 16 May 2021, at 16:44, Dan Egli  wrote:
> 
> Upgrade to WHAT? You said it was fixed in 9.11.25, but isn't that a lot OLDER 
> than 9.16.15, which is what I'm running?
> jupiter ~ # named -v
> BIND 9.16.15 (Stable Release) 
> jupiter ~ # dig -v
> DiG 9.16.15
> 
> 
> On 5/16/2021 12:06 AM, Mark Andrews wrote:
>> 
>>> On 16 May 2021, at 10:17, Dan Egli via bind-users 
>>>  wrote:
>>> 
>>> On 5/10/2021 12:38 PM, Tony Finch wrote:
 Dan Egli 
  wrote:
 
> Still not working for me. The dig doesn't report anything, and I don't 
> HAVE a
> keyfile since i'm using inline signing. Or does inline signing still 
> require a
> key to be generated?
> 
 Yes, you need to do your own key management with inline-signing using
 dnssec-keygen. The new dnssec-policy feature can do automatic key
 management for you.
 
 Tony.
 
>>> So, I updated the settings. Now I have keyfiles generated by bind, as well 
>>> as a binary .zone.signed in addition to the plain text .zone which has no 
>>> DNSSEC information at all in it. I ran the signing routine and bind said it 
>>> was signed good. So I obtained the DS and put in the registrar. Now I am 
>>> getting SERVFAIL errors whenever I try to query my zone from another name 
>>> server. Here's what I did:
>>> 
>>> #dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
>>> newideatest.site. IN DS 49236 13 2 
>>> 
>>> Ok. Copy the long hash to the Registrar, plug it in. Check, done that.
>>> 
>>>  # dig mx newideatest.site @8.8.4.4
>>> 
>>> ; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 512
>>> ;; QUESTION SECTION:
>>> ;newideatest.site.  IN  MX
>>> 
>>> ;; Query time: 50 msec
>>> ;; SERVER: 8.8.4.4#53(8.8.4.4)
>>> ;; WHEN: Sat May 15 18:12:44 MDT 2021
>>> ;; MSG SIZE  rcvd: 45
>>> ServFail?! WHAT?
>> This is a known bug fixed in BIND 9.11.25.  Upgrade.  Once the DS is added 
>> to .site for
>> newideatest.site the resolution will work.
>>   
> 
> -- 
> Dan Egli
> From my Test Server
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

2021-05-16 Thread Ondřej Surý

I think Mark jumped on something else, your zone is seriously broken and not 
because of DNSSEC:

https://dnssec-analyzer.verisignlabs.com/newideatest.site

All of these NSes must have the correct zone content and not be broken:

newideatest.site.   3600IN  NS  jupiter.eglifamily.name.
newideatest.site.   3600IN  NS  
uz5qfm8n244kn4qz8mh437w9kzvpudduwyldp5361v9n0vh8sx5ucu.free.ns.buddyns.com.
newideatest.site.   3600IN  NS  
uz5154v9zl2nswf05td8yzgtd0jl6mvvjp98ut07ln0ydp2bqh1skn.free.ns.buddyns.com.
newideatest.site.   3600IN  NS  
uz52u1wtmumlrx5fwu6nmv22ntcddxcjjw41z8sfd6ur9n7797lrv9.free.ns.buddyns.com.
newideatest.site.   3600IN  NS  
uz5w6sb91zt99b73bznfkvtd0j1snxby06gg4hr0p8uum27n0hf6cd.free.ns.buddyns.com.

--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 16. 5. 2021, at 8:45, Dan Egli via bind-users  
> wrote:
> 
> Upgrade to WHAT? You said it was fixed in 9.11.25, but isn't that a lot 
> OLDER than 9.16.15, which is what I'm running?
> jupiter ~ # named -v
> BIND 9.16.15 (Stable Release) 
> jupiter ~ # dig -v
> DiG 9.16.15
> 
> 
>> On 5/16/2021 12:06 AM, Mark Andrews wrote:
>> 
 On 16 May 2021, at 10:17, Dan Egli via bind-users 
  wrote:
>>> 
>>> On 5/10/2021 12:38 PM, Tony Finch wrote:
 Dan Egli 
  wrote:
 
> Still not working for me. The dig doesn't report anything, and I don't 
> HAVE a
> keyfile since i'm using inline signing. Or does inline signing still 
> require a
> key to be generated?
> 
 Yes, you need to do your own key management with inline-signing using
 dnssec-keygen. The new dnssec-policy feature can do automatic key
 management for you.
 
 Tony.
 
>>> So, I updated the settings. Now I have keyfiles generated by bind, as well 
>>> as a binary .zone.signed in addition to the plain text .zone which has no 
>>> DNSSEC information at all in it. I ran the signing routine and bind said it 
>>> was signed good. So I obtained the DS and put in the registrar. Now I am 
>>> getting SERVFAIL errors whenever I try to query my zone from another name 
>>> server. Here's what I did:
>>> 
>>> #dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
>>> newideatest.site. IN DS 49236 13 2 
>>> 
>>> Ok. Copy the long hash to the Registrar, plug it in. Check, done that.
>>> 
>>>  # dig mx newideatest.site @8.8.4.4
>>> 
>>> ; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 512
>>> ;; QUESTION SECTION:
>>> ;newideatest.site.  IN  MX
>>> 
>>> ;; Query time: 50 msec
>>> ;; SERVER: 8.8.4.4#53(8.8.4.4)
>>> ;; WHEN: Sat May 15 18:12:44 MDT 2021
>>> ;; MSG SIZE  rcvd: 45
>>> ServFail?! WHAT?
>> This is a known bug fixed in BIND 9.11.25.  Upgrade.  Once the DS is added 
>> to .site for
>> newideatest.site the resolution will work.
>>   
> 
> -- 
> Dan Egli
> From my Test Server
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

2021-05-15 Thread Dan Egli via bind-users

Upgrade to WHAT? You said it was fixed in 9.11.25, but isn't that a lot 
OLDER than 9.16.15, which is what I'm running?

jupiter ~ # named -v
BIND 9.16.15 (Stable Release) 
jupiter ~ # dig -v
DiG 9.16.15


On 5/16/2021 12:06 AM, Mark Andrews wrote:



On 16 May 2021, at 10:17, Dan Egli via bind-users  
wrote:

On 5/10/2021 12:38 PM, Tony Finch wrote:

Dan Egli 
  wrote:


Still not working for me. The dig doesn't report anything, and I don't HAVE a
keyfile since i'm using inline signing. Or does inline signing still require a
key to be generated?


Yes, you need to do your own key management with inline-signing using
dnssec-keygen. The new dnssec-policy feature can do automatic key
management for you.

Tony.


So, I updated the settings. Now I have keyfiles generated by bind, as well as a 
binary .zone.signed in addition to the plain text .zone which has no DNSSEC 
information at all in it. I ran the signing routine and bind said it was signed 
good. So I obtained the DS and put in the registrar. Now I am getting SERVFAIL 
errors whenever I try to query my zone from another name server. Here's what I 
did:

#dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
newideatest.site. IN DS 49236 13 2 

Ok. Copy the long hash to the Registrar, plug it in. Check, done that.

  # dig mx newideatest.site @8.8.4.4

; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;newideatest.site.  IN  MX

;; Query time: 50 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Sat May 15 18:12:44 MDT 2021
;; MSG SIZE  rcvd: 45
ServFail?! WHAT?

This is a known bug fixed in BIND 9.11.25.  Upgrade.  Once the DS is added to 
.site for
newideatest.site the resolution will work.
   


--
Dan Egli
From my Test Server



OpenPGP_0x11B7451DF2015959.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

2021-05-15 Thread Mark Andrews



> On 16 May 2021, at 10:17, Dan Egli via bind-users  
> wrote:
> 
> On 5/10/2021 12:38 PM, Tony Finch wrote:
>> Dan Egli 
>>  wrote:
>> 
>>> Still not working for me. The dig doesn't report anything, and I don't HAVE 
>>> a
>>> keyfile since i'm using inline signing. Or does inline signing still 
>>> require a
>>> key to be generated?
>>> 
>> Yes, you need to do your own key management with inline-signing using
>> dnssec-keygen. The new dnssec-policy feature can do automatic key
>> management for you.
>> 
>> Tony.
>> 
> 
> So, I updated the settings. Now I have keyfiles generated by bind, as well as 
> a binary .zone.signed in addition to the plain text .zone which has no DNSSEC 
> information at all in it. I ran the signing routine and bind said it was 
> signed good. So I obtained the DS and put in the registrar. Now I am getting 
> SERVFAIL errors whenever I try to query my zone from another name server. 
> Here's what I did:
> 
> #dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
> newideatest.site. IN DS 49236 13 2 
> 
> Ok. Copy the long hash to the Registrar, plug it in. Check, done that.
> 
>  # dig mx newideatest.site @8.8.4.4
> 
> ; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;newideatest.site.  IN  MX
> 
> ;; Query time: 50 msec
> ;; SERVER: 8.8.4.4#53(8.8.4.4)
> ;; WHEN: Sat May 15 18:12:44 MDT 2021
> ;; MSG SIZE  rcvd: 45
> ServFail?! WHAT?

This is a known bug fixed in BIND 9.11.25.  Upgrade.  Once the DS is added to 
.site for
newideatest.site the resolution will work.
  
> So I go to DNSVIZ and run their test. 
> Errors (9)
> 
>   • newideatest.site/A: No RRSIG covering the RRset was returned in the 
> response. (31.220.30.73, 45.77.29.133, 103.6.87.125, 119.252.20.56, 
> 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e, 
> 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
>   • newideatest.site/: No RRSIG covering the RRset was returned in 
> the response. (31.220.30.73, 45.77.29.133, 103.6.87.125, 
> 119.252.20.56, 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5, 
> 2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
>   • newideatest.site/DNSKEY (alg 13, id 49236): No RRSIG covering the 
> RRset was returned in the response. (31.220.30.73, 45.77.29.133, 
> 103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3, 
> 2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, 
> UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_512_D_KN)
>   • newideatest.site/MX: No RRSIG covering the RRset was returned in the 
> response. (31.220.30.73, 45.77.29.133, 103.6.87.125, 119.252.20.56, 
> 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e, 
> 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_512_D_KN)
>   • newideatest.site/NS: No RRSIG covering the RRset was returned in the 
> response. (31.220.30.73, 45.77.29.133, 103.6.87.125, 119.252.20.56, 
> 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e, 
> 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
>   • newideatest.site/SOA: No RRSIG covering the RRset was returned in the 
> response. (31.220.30.73, 45.77.29.133, 103.6.87.125, 119.252.20.56, 
> 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e, 
> 2a04:bdc7:100:1b::3, TCP_-_EDNS0_4096_D_N, UDP_-_EDNS0_4096_D_KN, 
> UDP_-_EDNS0_4096_D_KN_0x20)
>   • newideatest.site/TXT: No RRSIG covering the RRset was returned in the 
> response. (31.220.30.73, 45.77.29.133, 103.6.87.125, 119.252.20.56, 
> 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e, 
> 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
>   • site to newideatest.site: No valid RRSIGs made by a key corresponding 
> to a DS RR were found covering the DNSKEY RRset, resulting in no secure entry 
> point (SEP) into the zone. (31.220.30.73, 45.77.29.133, 103.6.87.125, 
> 119.252.20.56, 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5, 
> 2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN, 
> UDP_-_EDNS0_512_D_KN)
>   • site to newideatest.site: The DS RRset for the zone included 
> algorithm 13 (ECDSAP256SHA256), but no DS RR matched a DNSKEY with algorithm 
> 13 that signs the zone's DNSKEY RRset. (31.220.30.73, 45.77.29.133, 
> 103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3, 
> 2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, 
> UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_512_D_KN)
> Warnings (13)
> 
>   • newideatest.site/A: The server responded with no OPT record, rather 
> than with RCODE FORMERR. (31.220.30.73, 45.77.29.133, 103.6.87.125, 
> 119.252.20.56, 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5, 
> 2403:2500:400

Re: Inline signing fails dnsviz test - STILL [LONG]

2021-05-15 Thread Dan Egli via bind-users


On 5/10/2021 12:38 PM, Tony Finch wrote:

Dan Egli  wrote:

Still not working for me. The dig doesn't report anything, and I don't HAVE a
keyfile since i'm using inline signing. Or does inline signing still require a
key to be generated?

Yes, you need to do your own key management with inline-signing using
dnssec-keygen. The new dnssec-policy feature can do automatic key
management for you.

Tony.



So, I updated the settings. Now I have keyfiles generated by bind, as 
well as a binary .zone.signed in addition to the plain text .zone which 
has no DNSSEC information at all in it. I ran the signing routine and 
bind said it was signed good. So I obtained the DS and put in the 
registrar. Now I am getting SERVFAIL errors whenever I try to query my 
zone from another name server. Here's what I did:


#dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
newideatest.site. IN DS 49236 13 2 

Ok. Copy the long hash to the Registrar, plug it in. Check, done that.

 # dig mx newideatest.site @8.8.4.4

; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;newideatest.site.  IN  MX

;; Query time: 50 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Sat May 15 18:12:44 MDT 2021
;; MSG SIZE  rcvd: 45

ServFail?! WHAT?  So I go to DNSVIZ and run their test.


 Errors (9)

 * newideatest.site/A: No RRSIG covering the RRset was returned in the
   response. (31.220.30.73, 45.77.29.133, 103.6.87.125, 119.252.20.56,
   2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
   2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
 * newideatest.site/: No RRSIG covering the RRset was returned in
   the response. (31.220.30.73, 45.77.29.133, 103.6.87.125,
   119.252.20.56, 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
   2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
 * newideatest.site/DNSKEY (alg 13, id 49236): No RRSIG covering the
   RRset was returned in the response. (31.220.30.73, 45.77.29.133,
   103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3,
   2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e,
   2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_512_D_KN)
 * newideatest.site/MX: No RRSIG covering the RRset was returned in the
   response. (31.220.30.73, 45.77.29.133, 103.6.87.125, 119.252.20.56,
   2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
   2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN,
   UDP_-_EDNS0_512_D_KN)
 * newideatest.site/NS: No RRSIG covering the RRset was returned in the
   response. (31.220.30.73, 45.77.29.133, 103.6.87.125, 119.252.20.56,
   2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
   2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
 * newideatest.site/SOA: No RRSIG covering the RRset was returned in
   the response. (31.220.30.73, 45.77.29.133, 103.6.87.125,
   119.252.20.56, 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
   2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, TCP_-_EDNS0_4096_D_N,
   UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_4096_D_KN_0x20)
 * newideatest.site/TXT: No RRSIG covering the RRset was returned in
   the response. (31.220.30.73, 45.77.29.133, 103.6.87.125,
   119.252.20.56, 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
   2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
 * site to newideatest.site: No valid RRSIGs made by a key
   corresponding to a DS RR were found covering the DNSKEY RRset,
   resulting in no secure entry point (SEP) into the zone.
   (31.220.30.73, 45.77.29.133, 103.6.87.125, 119.252.20.56,
   2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
   2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN,
   UDP_-_EDNS0_512_D_KN)
 * site to newideatest.site: The DS RRset for the zone included
   algorithm 13 (ECDSAP256SHA256), but no DS RR matched a DNSKEY with
   algorithm 13 that signs the zone's DNSKEY RRset. (31.220.30.73,
   45.77.29.133, 103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3,
   2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e,
   2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_512_D_KN)


 Warnings (13)

 * newideatest.site/A: The server responded with no OPT record, rather
   than with RCODE FORMERR. (31.220.30.73, 45.77.29.133, 103.6.87.125,
   119.252.20.56, 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5,
   2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
 * newideatest.site/: The server responded with no OPT record,
   rather than with RCODE FORMERR. (31.220.30.73, 45.77.29.133,
   103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3,
   2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e,
   2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
 * newideatest.site/DNSKEY (alg 13, id 49

Re: Inline signing fails dnsviz test.

2021-05-10 Thread Dan Egli via bind-users

Okay, so I added the policy, and things MOSTLY look okay. But when I 
retake the verification test, I get errors about no RRSIGs found. What 
do I do to resolve that issue?


On 5/10/2021 12:38 PM, Tony Finch wrote:

Dan Egli  wrote:

Still not working for me. The dig doesn't report anything, and I don't HAVE a
keyfile since i'm using inline signing. Or does inline signing still require a
key to be generated?

Yes, you need to do your own key management with inline-signing using
dnssec-keygen. The new dnssec-policy feature can do automatic key
management for you.

Tony.


--
Dan Egli
From my Test Server



OpenPGP_0x11B7451DF2015959.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test.

2021-05-10 Thread Tony Finch

Dan Egli  wrote:
>
> Still not working for me. The dig doesn't report anything, and I don't HAVE a
> keyfile since i'm using inline signing. Or does inline signing still require a
> key to be generated?

Yes, you need to do your own key management with inline-signing using
dnssec-keygen. The new dnssec-policy feature can do automatic key
management for you.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Lundy, Fastnet: Southwest 5 to 7, backing southeast 4 to 6 for a time.
Moderate or rough, occasionally very rough in southwest Fastnet.
Thundery rain. Good, occasionally poor.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test.

2021-05-10 Thread Dan Egli


On 5/10/2021 12:17 PM, Tony Finch wrote:

Dan Egli  wrote:

Where do I get the DS record, since i'm using bind's inline signing?

Use the dnssec-dsfromkey tool, e.g. from a key file (make sure it's the
KSK file)

$ grep This Kcam.ac.uk.+013+32840.key
; This is a key-signing key, keyid 32840, for cam.ac.uk.
$ dnssec-dsfromkey -2 Kcam.ac.uk.+013+32840.key
cam.ac.uk. IN DS 32840 13 2 
2BDAF21907420CE792AF02B55071953BC2BDB64B5126710E12AF89F711322B85

or from your DNSKEY RRset (safest to run this on your primary to be sure
the keys aren't mangled)

$ dig cam.ac.uk dnskey | dnssec-dsfromkey -2 -f - cam.ac.uk
cam.ac.uk. IN DS 32840 13 2 
2BDAF21907420CE792AF02B55071953BC2BDB64B5126710E12AF89F711322B85

Tony.


Still not working for me. The dig doesn't report anything, and I don't 
HAVE a keyfile since i'm using inline signing. Or does inline signing 
still require a key to be generated? The walkthrough I was looking at 
didn't seem to indicate that.


 dig @localhost newideatest.site dnskey

; <<>> DiG 9.16.12 <<>> @localhost newideatest.site dnskey
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38832
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f932880860047837010060997aea2f4ce09bf11a954c (good)
;; QUESTION SECTION:
;newideatest.site.  IN  DNSKEY

;; AUTHORITY SECTION:
newideatest.site.   120 IN  SOA newideatest.site. 
dan.newideatest.site. 5 120 240 604800 86400


;; Query time: 10 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon May 10 12:26:50 MDT 2021
;; MSG SIZE  rcvd: 113

So, of course dnssec-dsfromkey does't work:

 dig @localhost newideatest.site dnskey | dnssec-dsfromkey -2 -f - 
newideatest.site

dnssec-dsfromkey: fatal: no DNSKEY RR for newideatest.site in input


--
Dan Egli
From my Test Server



OpenPGP_0x11B7451DF2015959.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test.

2021-05-10 Thread Tony Finch

Dan Egli  wrote:
>
> Where do I get the DS record, since i'm using bind's inline signing?

Use the dnssec-dsfromkey tool, e.g. from a key file (make sure it's the
KSK file)

$ grep This Kcam.ac.uk.+013+32840.key
; This is a key-signing key, keyid 32840, for cam.ac.uk.
$ dnssec-dsfromkey -2 Kcam.ac.uk.+013+32840.key
cam.ac.uk. IN DS 32840 13 2 
2BDAF21907420CE792AF02B55071953BC2BDB64B5126710E12AF89F711322B85

or from your DNSKEY RRset (safest to run this on your primary to be sure
the keys aren't mangled)

$ dig cam.ac.uk dnskey | dnssec-dsfromkey -2 -f - cam.ac.uk
cam.ac.uk. IN DS 32840 13 2 
2BDAF21907420CE792AF02B55071953BC2BDB64B5126710E12AF89F711322B85

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Berwick upon Tweed to Whitby: South backing southeast, 3 to 5,
occasionally 6 at first. Slight or moderate becoming slight. Showers,
perhaps thundery later. Good occasionally moderate later.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test.

2021-05-10 Thread Dan Egli

They do, and I had forgotten that. But I don't know where to get the DS 
record I'd place. I tried querying bind, but all I got back was 
someone's SOA record:


; <<>> DiG 9.16.12 <<>> @localhost ds eglifamily.name
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62605
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8761a3c0b39eccab01006099729d88739143bbe8c230 (good)
;; QUESTION SECTION:
;eglifamily.name.   IN  DS

;; AUTHORITY SECTION:
name.   10794   IN  SOA ac1.nstld.com. 
info.verisign-grs.com. 1620669036 1800 900 604800 86400


;; Query time: 10 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon May 10 11:51:25 MDT 2021
;; MSG SIZE  rcvd: 142

Where do I get the DS record, since i'm using bind's inline signing?

On 5/10/2021 3:29 AM, John W. Blue via bind-users wrote:

Hello Dan.

Does your registrar have the ability via a UI to place a DS record in 
the .name zone?


And if so, have you done that already?

John

Sent from Nine <http://www.9folders.com/>

*From:* Dan Egli 
*Sent:* Monday, May 10, 2021 12:20 AM
*To:* bind-users@lists.isc.org
*Subject:* Inline signing fails dnsviz test.

I tried to setup inline signing on my DNS server, and after reading the
results from DNSVIZ, i'd say I was PARTIALLY successful, but there still
seems to be a lot missing.

You can check the status on dnsviz yourself with the names
eglifamily.name and newideatest.site. Both resulted in nearly identical
responses, wtih a lot of warning and some errors. A few of those errors
I could blame on my backup DNS provider. You get what you pay for and
they are free. But not everything could be blamed on them.

I've attached a PNG of the output. Hopefully it comes through.
Meanwhile, here's the zone statements from my named.conf:

view "standard" IN {
 zone "eglifamily.name" {
 type master;
 file "pri/eglifamily.zone";
 allow-query { any; };
 allow-transfer {
   108.61.224.67; 116.203.6.3; 107.191.99.111;
185.22.172.112; 103.6.87.125; 192.184.93.99; 119.252.20.56;
31.220.30.73; 185.34.136.178; 185.136.176.247; 45.77.29.133;
116.203.0.64; 167.88.161.228; 199.195.249.208; 104.244.78.122;
2605:6400:30:fd6e::3; 2605:6400:10:65::3; 2605:6400:20:d5e::3;
2a01:4f8:1c0c:8122::3; 2001:19f0:7001:381::3; 2a06:fdc0:fade:2f7::1;
2a00:dcc7:d3ff:88b2::1; 2a04:bdc7:100:1b::3;
2401:1400:1:1201::1:7853:1a5; 2604:180:1:92a::3; 2403:2500:4000::f3e;
2a00:1838:20:2::cd5e:68e9; 2604:180:2:4cf::3; 2a01:4f8:1c0c:8115::3;
2001:19f0:6400:8642::3;
 };
//  also-notify { 1.2.3.4; }; // none for now
 allow-update { trusted; };
 key-directory "/var/bind/pri/keys";
 auto-dnssec maintain;
 inline-signing yes;
 };

 zone "newideatest.site" {
 type master;
 file "pri/newideatest.zone";
 allow-query { any; };
 allow-transfer {
   108.61.224.67; 116.203.6.3; 107.191.99.111;
185.22.172.112; 103.6.87.125; 192.184.93.99; 119.252.20.56;
31.220.30.73; 185.34.136.178; 185.136.176.247; 45.77.29.133;
116.203.0.64; 167.88.161.228; 199.195.249.208; 104.244.78.122;
2605:6400:30:fd6e::3; 2605:6400:10:65::3; 2605:6400:20:d5e::3;
2a01:4f8:1c0c:8122::3; 2001:19f0:7001:381::3; 2a06:fdc0:fade:2f7::1;
2a00:dcc7:d3ff:88b2::1; 2a04:bdc7:100:1b::3;
2401:1400:1:1201::1:7853:1a5; 2604:180:1:92a::3; 2403:2500:4000::f3e;
2a00:1838:20:2::cd5e:68e9; 2604:180:2:4cf::3; 2a01:4f8:1c0c:8115::3;
2001:19f0:6400:8642::3;
 };
//  also-notify { 1.2.3.4; }; // none for now
 allow-update { trusted; };
 key-directory "/var/bind/pri/keys";
 auto-dnssec maintain;
 inline-signing yes;
 };

--

Dan Egli
 From my Test Server


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


--
Dan Egli
From my Test Server



OpenPGP_0x11B7451DF2015959.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development

Re: Inline signing fails dnsviz test.

2021-05-10 Thread John W. Blue via bind-users

Hello Dan.

Does your registrar have the ability via a UI to place a DS record in the .name 
zone?

And if so, have you done that already?

John

Sent from Nine<http://www.9folders.com/>

From: Dan Egli 
Sent: Monday, May 10, 2021 12:20 AM
To: bind-users@lists.isc.org
Subject: Inline signing fails dnsviz test.

I tried to setup inline signing on my DNS server, and after reading the
results from DNSVIZ, i'd say I was PARTIALLY successful, but there still
seems to be a lot missing.

You can check the status on dnsviz yourself with the names
eglifamily.name and newideatest.site. Both resulted in nearly identical
responses, wtih a lot of warning and some errors. A few of those errors
I could blame on my backup DNS provider. You get what you pay for and
they are free. But not everything could be blamed on them.

I've attached a PNG of the output. Hopefully it comes through.
Meanwhile, here's the zone statements from my named.conf:

view "standard" IN {
 zone "eglifamily.name" {
 type master;
 file "pri/eglifamily.zone";
 allow-query { any; };
 allow-transfer {
   108.61.224.67; 116.203.6.3; 107.191.99.111;
185.22.172.112; 103.6.87.125; 192.184.93.99; 119.252.20.56;
31.220.30.73; 185.34.136.178; 185.136.176.247; 45.77.29.133;
116.203.0.64; 167.88.161.228; 199.195.249.208; 104.244.78.122;
2605:6400:30:fd6e::3; 2605:6400:10:65::3; 2605:6400:20:d5e::3;
2a01:4f8:1c0c:8122::3; 2001:19f0:7001:381::3; 2a06:fdc0:fade:2f7::1;
2a00:dcc7:d3ff:88b2::1; 2a04:bdc7:100:1b::3;
2401:1400:1:1201::1:7853:1a5; 2604:180:1:92a::3; 2403:2500:4000::f3e;
2a00:1838:20:2::cd5e:68e9; 2604:180:2:4cf::3; 2a01:4f8:1c0c:8115::3;
2001:19f0:6400:8642::3;
 };
//  also-notify { 1.2.3.4; }; // none for now
 allow-update { trusted; };
 key-directory "/var/bind/pri/keys";
 auto-dnssec maintain;
 inline-signing yes;
 };

 zone "newideatest.site" {
 type master;
 file "pri/newideatest.zone";
 allow-query { any; };
 allow-transfer {
   108.61.224.67; 116.203.6.3; 107.191.99.111;
185.22.172.112; 103.6.87.125; 192.184.93.99; 119.252.20.56;
31.220.30.73; 185.34.136.178; 185.136.176.247; 45.77.29.133;
116.203.0.64; 167.88.161.228; 199.195.249.208; 104.244.78.122;
2605:6400:30:fd6e::3; 2605:6400:10:65::3; 2605:6400:20:d5e::3;
2a01:4f8:1c0c:8122::3; 2001:19f0:7001:381::3; 2a06:fdc0:fade:2f7::1;
2a00:dcc7:d3ff:88b2::1; 2a04:bdc7:100:1b::3;
2401:1400:1:1201::1:7853:1a5; 2604:180:1:92a::3; 2403:2500:4000::f3e;
2a00:1838:20:2::cd5e:68e9; 2604:180:2:4cf::3; 2a01:4f8:1c0c:8115::3;
2001:19f0:6400:8642::3;
 };
//  also-notify { 1.2.3.4; }; // none for now
 allow-update { trusted; };
 key-directory "/var/bind/pri/keys";
 auto-dnssec maintain;
 inline-signing yes;
 };

--

Dan Egli
 From my Test Server

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test.

2021-05-09 Thread Ondřej Surý

I would recommend starting here: 
https://bind9.readthedocs.io/en/latest/dnssec-guide.html

--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 10. 5. 2021, at 7:19, Dan Egli  wrote:
> 
> I tried to setup inline signing on my DNS server, and after reading the 
> results from DNSVIZ, i'd say I was PARTIALLY successful, but there still 
> seems to be a lot missing.
> 
> You can check the status on dnsviz yourself with the names eglifamily.name 
> and newideatest.site. Both resulted in nearly identical responses, wtih a lot 
> of warning and some errors. A few of those errors I could blame on my backup 
> DNS provider. You get what you pay for and they are free. But not everything 
> could be blamed on them.
> 
> I've attached a PNG of the output. Hopefully it comes through. Meanwhile, 
> here's the zone statements from my named.conf:
> 
> view "standard" IN {
> zone "eglifamily.name" {
> type master;
> file "pri/eglifamily.zone";
> allow-query { any; };
> allow-transfer {
>   108.61.224.67; 116.203.6.3; 107.191.99.111; 185.22.172.112; 
> 103.6.87.125; 192.184.93.99; 119.252.20.56; 31.220.30.73; 185.34.136.178; 
> 185.136.176.247; 45.77.29.133; 116.203.0.64; 167.88.161.228; 199.195.249.208; 
> 104.244.78.122; 2605:6400:30:fd6e::3; 2605:6400:10:65::3; 
> 2605:6400:20:d5e::3; 2a01:4f8:1c0c:8122::3; 2001:19f0:7001:381::3; 
> 2a06:fdc0:fade:2f7::1; 2a00:dcc7:d3ff:88b2::1; 2a04:bdc7:100:1b::3; 
> 2401:1400:1:1201::1:7853:1a5; 2604:180:1:92a::3; 2403:2500:4000::f3e; 
> 2a00:1838:20:2::cd5e:68e9; 2604:180:2:4cf::3; 2a01:4f8:1c0c:8115::3; 
> 2001:19f0:6400:8642::3;
> };
> //  also-notify { 1.2.3.4; }; // none for now
> allow-update { trusted; };
> key-directory "/var/bind/pri/keys";
> auto-dnssec maintain;
> inline-signing yes;
> };
> 
> zone "newideatest.site" {
> type master;
> file "pri/newideatest.zone";
> allow-query { any; };
> allow-transfer {
>   108.61.224.67; 116.203.6.3; 107.191.99.111; 185.22.172.112; 
> 103.6.87.125; 192.184.93.99; 119.252.20.56; 31.220.30.73; 185.34.136.178; 
> 185.136.176.247; 45.77.29.133; 116.203.0.64; 167.88.161.228; 199.195.249.208; 
> 104.244.78.122; 2605:6400:30:fd6e::3; 2605:6400:10:65::3; 
> 2605:6400:20:d5e::3; 2a01:4f8:1c0c:8122::3; 2001:19f0:7001:381::3; 
> 2a06:fdc0:fade:2f7::1; 2a00:dcc7:d3ff:88b2::1; 2a04:bdc7:100:1b::3; 
> 2401:1400:1:1201::1:7853:1a5; 2604:180:1:92a::3; 2403:2500:4000::f3e; 
> 2a00:1838:20:2::cd5e:68e9; 2604:180:2:4cf::3; 2a01:4f8:1c0c:8115::3; 
> 2001:19f0:6400:8642::3;
> };
> //  also-notify { 1.2.3.4; }; // none for now
> allow-update { trusted; };
> key-directory "/var/bind/pri/keys";
> auto-dnssec maintain;
> inline-signing yes;
> };
> 
> -- 
> 
> Dan Egli
> From my Test Server
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test - STILL [LONG]

Re: Inline signing fails dnsviz test - STILL [LONG]

Re: Inline signing fails dnsviz test - STILL [LONG]

Re: Inline signing fails dnsviz test - STILL [LONG]

Re: Inline signing fails dnsviz test - STILL [LONG]

Re: Inline signing fails dnsviz test - STILL [LONG]

Re: Inline signing fails dnsviz test - STILL [LONG]

Re: Inline signing fails dnsviz test - STILL [LONG]

Re: Inline signing fails dnsviz test - STILL [LONG]

Re: Inline signing fails dnsviz test.

Re: Inline signing fails dnsviz test.

Re: Inline signing fails dnsviz test.

Re: Inline signing fails dnsviz test.

Re: Inline signing fails dnsviz test.

Re: Inline signing fails dnsviz test.

Re: Inline signing fails dnsviz test.

16 matches

Site Navigation

Mail list logo

Footer information