Inline signing fails dnsviz test - STILL [LONG]

Ondřej Surý ondrej at isc.org
Sun May 16 09:10:08 UTC 2021


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: 4f4d8ab87a8cc4240100000060a0e1211ad492152d054053 (good)
;; QUESTION SECTION:
;newideatest.site.		IN	MX

;; ANSWER SECTION:
newideatest.site.	120	IN	MX	0 athena.newideatest.site.
newideatest.site.	120	IN	MX	9999 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)
ondrej at isc.org

> On 16. 5. 2021, at 10:47, Dan Egli <dan at newideatest.site> 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 <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 <bind-users at lists.isc.org> 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) <id:4469e3e>
>>> 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 <bind-users at lists.isc.org> wrote:
>>>>> 
>>>>> On 5/10/2021 12:38 PM, Tony Finch wrote:
>>>>>> Dan Egli <dan at newideatest.site>
>>>>>>  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 <LONG HASH>
>>>>> 
>>>>> 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>
>>> _______________________________________________
>>> 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 at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> --
> Dan Egli
> From my Test Server
> 
> <OpenPGP_0x11B7451DF2015959.asc>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210516/4f55102b/attachment-0001.bin>


More information about the bind-users mailing list