CZ-NIC/knot

High-performance authoritative DNS server. Please support the development https://donations.nic.cz/donate/?project=knot-dns

Daniel Salzman

@salzmdan

It's valid syntax, which means use previous record owner

Vladimír Čunát

@vcunat

Oh, I'm sorry, thanks :-)

Daniel Salzman

@salzmdan

It's our zone file example ;-)

But you are right, the zone file is invalid. Because there is missing $ before ORIGIN :-D

Yevhenii Kurtov

@lessless

thanks, that was it!

Yevhenii Kurtov

@lessless

How to add CNAME record that will point to an AAAA record? I tried

ipv6cname  CNAME  ipv6

ipv6 AAAA  0:0:0:0:0:ffff:c000:204

Daniel Salzman

@salzmdan

What is the problem?

$ kdig @::1 ipv6cname.test AAAA +noall +answer

;; ANSWER SECTION:
ipv6cname.test.         3600    IN    CNAME    ipv6.test.
ipv6.test.              3600    IN    AAAA    ::ffff:192.0.2.4

Yevhenii Kurtov

@lessless

I get nothing in response dig @192.168.1.105 -p 53 ipv6cname.example.com +short

Vladimír Čunát

@vcunat

That's because you ask for A record.

CNAME points just to a different name.

Yevhenii Kurtov

@lessless

I might be doing something simple, but it still doesn't work even with the command above kdig @192.168.1.105 ipv6cname.example.com AAAA +noall +answer
@salzmdan can you please share your zone file?

Yevhenii Kurtov

@lessless

most probably - it works now :)

happy new year guys!

muellert

@muellert

Hi! I updated a few zone files, restarted knotd, and not get REFUSED for each query. Of course, zone-check and conf-check were all fine.

I'm running knot 2.9.3

Socket is open, knotc shows that the zone is loaded with the correct serial...

muellert

@muellert

Ok. Problem understood: If knot is to listen on 0.0.0.0, but something else (here: unbound) is listening on a specific IP, then knot refuses to work. It insists on grabbing all IPs, instead of just taking what's available. Unfortunately, there is no good error message about this.

Michael Felden

@mfld-pub

Does anyone have a writeup on how to manually renew ksk and zsk for a zone with mod-synthrecord and mod-onlinesign ? I took from the docs what I think are the correct steps but now I see strange errors in dnsviz and zonemaster.

They claim knot DNS responded with no DNSKEY record(s). But if I dig +ad I see good responses. Looks good and resolves fine:
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 2085
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1

Daniel Salzman

@salzmdan

@mfld-pub your problem description is too terse. What does dnsviz say?

Matt Corallo

@TheBlueMatt

just upgraded to 3.0.3 and am getting a double free on start immediately after a "warning: [XXX] zone file changed with SOA serial decreased, ignoring zone file and loading from journal"

bumping the SOAs in the failing zones works....on the first restart, but then seems to fail again because auto-dnssec-signing causes knot to bump the soa itself.

Matt Corallo

@TheBlueMatt

starts ok after stopping, bumping soa in all zones (or at least those that are dnssec-signed) and then restarting

the zones in question are in a catalog zone, with the template set to:

    storage: "/var/lib/knot"
    file: "/etc/knot/db.%s"
    zonefile-load: difference
    semantic-checks: on
    dnssec-signing: on
    dnssec-policy: default
    zonefile-sync: -1
    serial-policy: increment
    journal-content: all
    journal-max-depth: 3

Daniel Salzman

@salzmdan

@TheBlueMatt what was the previous version before upgrade to 3.0.3? Because you are talking about catalog zones. So I'm a bit confused.

Matt Corallo

@TheBlueMatt

either 3.0.2 or 3.0.1 I dont recall exactly

Michael Felden

@mfld-pub

@salzmdan
The Verisign tool says:

No DNSKEY records found
No NSEC records in response
No RRSIGs found

dnsviz says:

The DNSKEY RR was not found in the DNSKEY RR set
No RRSIG covering the RR set was found in the response

But lookups seem to succeed and come back with the AD flag.

Michael Felden

@mfld-pub

Upstream has the correct keytag, alg and hash and I waited 2 days for propagation. I must have done something wrong with keymgr so that the keys are there but not being used or something. My rollovers are all manual so my goal was to make a new ksk and zsk

Daniel Salzman

@salzmdan

@TheBlueMatt Okay, so I think the problem isn't in the transition 3.0.1/2->3.0.3 but in knot restart during the update. We will try to reproduce it.

Daniel Salzman

@salzmdan

@mfld-pub your CSK is in the ready state and you have to submit it to make it active. Use knotc <zone-name> zone-ksk-submitted

Michael Felden

@mfld-pub

@salzmdan Ahhh! Makes sense. On 3.0.3 its knotc zone-ksk-submitted <zone-name>
This is the missing step! I don't know what I saw in the docu that made me skip this part.

Will test now and report back!

Michael Felden

@mfld-pub

FIXED! I think I grasp the process now.

Thank you again @salzmdan

Yevhenii Kurtov

@lessless

How to add a wildcard record?

Phynecs

@Phynecs

@lessless like any other record, just with a wildcard at the beginning, for example like this (be aware of the rules here: https://www.knot-dns.cz/docs/2.7/html/operation.html#reading-and-editing-zones):

knotc zone-begin example.com.
knotc zone-set -- *.example.com. 3600 CNAME example.com.
knotc zone-commit --

or where should the wildcard be?

Daniel Salzman

@salzmdan

@TheBlueMatt We have reproduced a similar situation. I have to say, I hate zone file changes in combination with server automation :-D

bleve

@bleve

Should zone-backup preserve directory structure? Currently it doesn't.

Backup gets flattened to single directory structure and doesn't preserve directory for zones per template.

That means zone-backup dir can't be restored like documentation suggests, by copying backup to /var/lib/knot

Daniel Salzman

@salzmdan

No, the directory structure isn't preserved.
Please, which part of the docu should be improved?

Phynecs

@Phynecs

; <<>> DiG 9.16.10 <<>> asd.test.example.dev
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2626
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;asd.test.rievo.dev.            IN      A

;; AUTHORITY SECTION:
rievo.dev.              3600    IN      SOA     ns.example.ch. hostmaster.example.net. 2021010800 14400 3600 1209600 3600

Daniel Salzman

@salzmdan

@Phynecs Please, file an issue in https://gitlab.nic.cz/knot/knot-dns/-/issues

Phynecs

@Phynecs

ok i'll do that, just wanted to make shure it's not an obvious error, will do that this evening

bleve

@bleve

@salzmdan I think it would be good to add notification that original directory structure is not preserved. Currently there is nothing which would give hint about directory structure of backup possibly being different from original directory structure.

Daniel Salzman

@salzmdan

But it's only the case of manual zone file copying. Zone-restore preserves the location, doesn't it?

We will add a note to the documentation.

bleve

@bleve

I can test. a minute.

Yes, online restore does it right.

libor-peltan-cznic

@libor-peltan-cznic

If the Online backup was performed for all zones, it’s possible to restore the backed up data by simply copying them to their normal locations, since they’re simply copies. For example, the user can copy (overwrite) the backed up KASP database files to their configured location.

This tries to suggest that each piece of data shall be restored to its "normal location" (individually).

Where communities thrive

People

Repo info

Activity