14 Kvě
2024
14 Kvě
'24
8:10
Good morning,
ISC bind is strict about CNAME of NS server:
skipping nameserver 'aa.bb.cz' because it is a CNAME, while resolving
'9.4/4.3.2.1.in-addr.arpa/PTR'.
How about Knot resolver ?
Thanks and best regards
J.Karliak
22:43
On 5/17/24 22:30, Jan-Piet Mens wrote:
I think the question is whether Knot Resolver follows the letter of the RFC, like BIND, or
whether it is less strict.
This is a good question, because ...
How about Knot
resolver ?
The question is moot as it's not permitted. RFC 1912, section 2.4 says:
"Don't use CNAMEs in combination with RRs which point to other names
like MX, CNAME, PTR and NS."
... because Knot Resolver actually does *not* follow the letter of this RFC, at least for
CNAMEs:
$ dig +noall +answer @localhost outlook.office.com
outlook.office.com. 60 IN CNAME substrate.office.com.
substrate.office.com. 300 IN CNAME outlook.office365.com.
outlook.office365.com. 60 IN CNAME ooc-g2.tm-4.office.com.
ooc-g2.tm-4.office.com. 10 IN A 52.98.241.194
...
That said, setting up a CNAME NS is certainly a bad idea if BIND can't resolve it,
because that'll kill a bunch of your audience.
Peter
--
https://desec.io/
22:48
On 17/05/2024 22.43, Peter Thomassen wrote:
I think the question is whether Knot Resolver follows
the letter of
the RFC, like BIND, or whether it is less strict.
I'm not aware of RFCs saying that resolvers should fail in such
situations. My understanding is more like it's allowed not to work.
Anyway, it would be better to continue this thread on
knot-resolver-users(a)lists.nic.cz
(I already have posted there about this a couple days ago.)
--Vladimir
114
days inactive
117
days old
3 comments
4 participants
participants (4)
-
Jan-Piet Mens -
Josef Karliak -
Peter Thomassen -
Vladimír Čunát