Re: BIND 9 ARM, html/pdf not in the source?

[Ondřej Surý]

> On 16. 5. 2021, at 22:20, Chuck Aurora  wrote:
> 
> Yes, I saw that.  But the HTML markup is super nice to go to
> hyperlinked settings and related documentation sections.  Will
> the HTML documentation no longer be available at all, other
> than to access it online?

1. install sphinx-build (pip(3) install sphinx sphinx-rtd-theme)
2. make html
3. (xdg-)open doc/arm/_build/html/index.html

or just download it from:

https://bind9.readthedocs.io/_/downloads/en/v9_16_15/pdf/
https://bind9.readthedocs.io/_/downloads/en/v9_16_15/htmlzip/
https://bind9.readthedocs.io/_/downloads/en/v9_16_15/epub/

> I don't get why a free software project
> would shut out input from non-users of a third-party service.

Umm, what? The ISC GitLab is run by ISC. All the data is handled
by ISC.

But even if it wasn’t - it’s about choices where to invest the time.
Do you want us rather improving the code because we can focus
or rather the development team should invest the time to scan
multiple sources for incoming issues? I think that the rational choice
here is obvious.

I can chit-chat here as much as I like because it’s Sunday and I was
waiting for the vaccination registration to be open for my age group,
but as long as I am fully in the work mode, I need a single source of
truth for all the issues, all the merge requests, so I don’t spend much
time on searching “where the heck the information was” because it’s
all in the one place. I don’t think it’s too much to ask a little bit of
inconvenience from the users, so we can actually focus on fixing
bugs and improving the software.

Ondrej
--
Ondřej Surý (He/Him)
ond...@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: Update DNSSEC Zone

[Chuck Aurora]

On 2021-05-13 09:41, Software Info wrote:

Wow. Thanks so much for all the responses. Really appreciate it. They
made me truly realize that a lot on the info on the net may be either
incomplete or just old. I understand a bit better now.
I added the line inline-signing yes;


inline-signing is not required; you already had "update-policy local;"
which gives you a key to use with nsupdate(8)'s -l option.  This is
a perfectly valid way to maintain zone data, and in my opinion much
better than editing zone files and inline-signing.  You have taken a
step backwards.

This has the overview of both DNSSEC and dynamic zones:

http://ftp.isc.org/isc/bind/cur/9.16/doc/arm/html/advanced.html

See section "5.2. Dynamic Update".  Also see the "auto-dnssec
maintain;" option described there.  With a dynamic zone and
nsupdate, inline-signing is completely unnecessary.

For those who insist on editing zone files rather than learning how
to use nsupdate, I still recommend "update-policy local;" see Tony
Finch's post where he mentions his nsdiff tool.


as was suggested and reloaded
bind. I am now seeing the .signed, .jbk and .jnl files. The zone also
replicates to the slaves and I am seeing the NSEC, RRSIG and DNSKEY
entries in the zone files on the slaves. I also checked with the
yogaDNS client and it had no problems identifying the DNSSEC server.
So I would imagine at this point it is working. I believe as was said
too I need now to register the DS with the registrar? Hopefully that
should be it if I am not missing anything?


Yes, submitting the DS to the registrar is always the last step to
take in signing.  It's best to be sure the signing is being done
before you tell the world to accept only signed data from your zone.
We see that a lot, BTW. :)


Thanks so much again for the very informative replies.


And a highly opinionated one? :)

I'd also recommend the DNSSEC guide,

https://bind9.readthedocs.io/en/latest/dnssec-guide.html

This is all on one page; or, the same document broken down in
sections can be seen here:

http://dnsinstitute.com/documentation/dnssec-guide/dnssec-guide.html
___
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: BIND 9 ARM, html/pdf not in the source?

[Chuck Aurora]

On 2021-05-16 14:59, Ondřej Surý wrote:

yes, the generated documentation is no longer part of sources, but you
can read the rst files used to generate documentation - those are just
plain text files with little extra markup.


Yes, I saw that.  But the HTML markup is super nice to go to
hyperlinked settings and related documentation sections.  Will
the HTML documentation no longer be available at all, other
than to access it online?

(I'm currently in a bandwidth-limited ISP, so I try to limit
such things.  Fiber is ordered and coming soon!  Yay!  Those
of you who know me and where I live will understand how cool
and amazing this is. :) )

(But even with fiber and unlimited high speed connections, I
like having documentation on my trusty old laptop.)


Also yes, you need ISC GitLab account to create new issues (unless
it’s a security vulnerability then OpenPGP encrypted email is
accepted). We need to interact with the reporters from the issue and
we think this is a reasonable requirement.


FWIW I do not agree.  I don't get why a free software project
would shut out input from non-users of a third-party service.
Email works since forever.  But then, you're not shutting out
input, as we did settle this through the mailing list. :)


The README.md has to be reviewed and fixed, but I guess you don’t need
to fill the issue for this.


Thank you for the reply, Ondřej, much appreciated.


On 16. 5. 2021, at 21:50, Chuck Aurora  wrote:

... and sorry, I missed a word here:


Said README also says for reporting bugs to use Gitlab, but without
a Gitlab account I did not readily see how to do this.  Are Gitlab
accounts for bug reports now?  Can you accept one from someone who

   ^ required

does not have a Gitlab account?  Does b...@isc.org no longer work
for bug reporting?

___
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: BIND 9 ARM, html/pdf not in the source?

[Ondřej Surý]

Chuck,

yes, the generated documentation is no longer part of sources, but you can read 
the rst files used to generate documentation - those are just plain text files 
with little extra markup.

Also yes, you need ISC GitLab account to create new issues (unless it’s a 
security vulnerability then OpenPGP encrypted email is accepted). We need to 
interact with the reporters from the issue and we think this is a reasonable 
requirement.

The README.md has to be reviewed and fixed, but I guess you don’t need to fill 
the issue for this.

Ondřej
--
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 21:50, Chuck Aurora  wrote:
> 
> I was about to reply to some other post on this list, when I
> needed to look something up to be sure about it, and I looked in
> my local OS (Slackware) documentation directory for the BIND 9
> ARM.  It's there in what appears to be a format for the Sphinx
> documentation builder, but no longer shipped in HTML nor PDF.
> See doc/arm/ in the source code.
> 
> The README still says this:
> 
> "Documentation
> 
> The BIND 9 Administrator Reference Manual is included with the source
> distribution, in DocBook XML, HTML, and PDF format, in the doc/arm
> directory."
> 
> This no longer appears to be the case, going back several minor
> versions.  I don't know exactly how far, but at least through the
> 9.16.11 release, which is what I had installed at the start of my
> quest today.  (I have 9.16.15 now.)
> 
> I guess the Sphinx processing should be done prior to generating
> the tarball, is that correct?
> 
> Said README also says for reporting bugs to use Gitlab, but without
> a Gitlab account I did not readily see how to do this.  Are Gitlab
> accounts for bug reports now?  Can you accept one from someone who
> does not have a Gitlab account?  Does b...@isc.org no longer work
> for bug reporting?
> ___
> 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

BIND 9 ARM, html/pdf not in the source?

[Chuck Aurora]

I was about to reply to some other post on this list, when I
needed to look something up to be sure about it, and I looked in
my local OS (Slackware) documentation directory for the BIND 9
ARM.  It's there in what appears to be a format for the Sphinx
documentation builder, but no longer shipped in HTML nor PDF.
See doc/arm/ in the source code.

The README still says this:

"Documentation

The BIND 9 Administrator Reference Manual is included with the source
distribution, in DocBook XML, HTML, and PDF format, in the doc/arm
directory."

This no longer appears to be the case, going back several minor
versions.  I don't know exactly how far, but at least through the
9.16.11 release, which is what I had installed at the start of my
quest today.  (I have 9.16.15 now.)

I guess the Sphinx processing should be done prior to generating
the tarball, is that correct?

Said README also says for reporting bugs to use Gitlab, but without
a Gitlab account I did not readily see how to do this.  Are Gitlab
accounts for bug reports now?  Can you accept one from someone who
does not have a Gitlab account?  Does b...@isc.org no longer work
for bug reporting?
___
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]

[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]

[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]

[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]

[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]

[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]

[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