25 Úno
2019
25 Úno
'19
10:32
Hi,
I'm not sure if it was already discussed on this list.
Why is BIND's dig getting a AD flag and kdig not?
Obviously sends dig the AD flag by default, but why have you decided this way?
dig +noall +comments @dotns1.aco.net univie.ac.at soa +qr
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52963
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d2171ad4016ceb3d
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52963
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
kdig +noall +header @dotns1.aco.net univie.ac.at soa +qr
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 25583
;; Flags: rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 25583
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0
cheers,
-arsen
25 Úno
25 Úno
10:51
Moin!
On 25 Feb 2019, at 10:32, Arsen STASIC wrote:
Hi,
I'm not sure if it was already discussed on this list.
Why is BIND's dig getting a AD flag and kdig not?
Binds dig is using EDNS0 and
other unnecessary stuff like cookies per
default, while kdig per default emulates and old style DNS client
without bells and whistles, and thus does not get AD, as this was only
defined with DNSSEC (RFC2535/3655/4035). Having EDNS0 support even
without setting DO is considered to be able to interpret the AD bit,
while clients without EDNS0 are considered not to be able to interpret
it and thus don’t get it.
So long
-Ralf
—--
Ralf Weber
11:00
Moin!
Ok forget the last sentence, bind is also setting the AD
bit on the
query and this actually triggers it, though the RFC where this is
defined currently doesn’t come to my mind. So to get AD with kdig do:
kdig +adflag +noall +header @dotns1.aco.net univie.ac.at soa +qr
So long
-Ralf
—--
Ralf Weber
Hi,
I'm not sure if it was already discussed on this list.
Why is BIND's dig getting a AD flag and kdig not?
Binds dig is using EDNS0 and
other unnecessary stuff like cookies per
default, while kdig per default emulates and old style DNS client
without bells and whistles, and thus does not get AD, as this was only
defined with DNSSEC (RFC2535/3655/4035). Having EDNS0 support even
without setting DO is considered to be able to interpret the AD bit,
while clients without EDNS0 are considered not to be able to interpret
it and thus don’t get it. 
11:09
On 2/25/19 11:00 AM, Ralf Weber wrote:
bind is also setting the AD bit on the query and this
actually
triggers it, though the RFC where this is defined currently doesn’t
come to my mind.
Yes, I don't remember which RFC, but it is standardized that if you
specify AD flag in query, the resolver should set it according to the
status even when you didn't specify DO flag. That can be a useful
combination when you don't want to validate yourself and thus have no
need for records like RRSIG. If there is neither DO nor AD in query,
the AD flag in reply should never be set (even if EDNS is used).
--Vladimir
11:01
Hi Ralf,
You are correct. This is rather a philosophical question :-) So far we haven't decided
on the main purpose of kdig.
For me kdig is a generic tool for advanced DNS testing. It means the defaults are simple
(e.g. no EDNS, DNS cookies).
The opposite approach is to consider kdig as a tool which knows best how the query should
look like ;-)
Anyway, we are open to change the defaults if it makes sense. So, what do our dear users
think?
Best,
Daniel
On 2/25/19 10:51 AM, Ralf Weber wrote:
Moin!
On 25 Feb 2019, at 10:32, Arsen STASIC wrote:
Hi,
I'm not sure if it was already discussed on this list.
Why is BIND's dig getting a AD flag and kdig not?
Binds dig is using EDNS0 and
other unnecessary stuff like cookies per default, while kdig per default emulates and old
style DNS client without bells and whistles, and thus does not get AD, as this was only
defined with DNSSEC (RFC2535/3655/4035). Having EDNS0 support even without setting DO is
considered to be able to interpret the AD bit, while clients without EDNS0 are considered
not to be able to interpret it and thus don’t get it.
So long
-Ralf
—--
Ralf Weber
11:15
Anyway, we are open to change the defaults if it makes
sense. So, what do our dear users think?
It should mimic how knot resolver sends upstream queries as best as
possible. So, I would expect it to use the DO-bit and EDNS0 by default
with whatever EDNS0 buffer size knot resolver is using by default.
Daniel
11:20
Moin!
On 25 Feb 2019, at 11:01, Daniel Salzman wrote:
Anyway, we are open to change the defaults if it makes
sense. So, what
do our dear users think?
As you asked. I started to use kdig because it supported
TLS, but I like
it’s simplistic approach of not setting anything by default and asking
for A ( I tried getdns_query which defaults to NS as default query type
:-( ). So the current default behaviour is fine with me as it still
emulates the most used clients.
So long
-Ralf
—--
Ralf Weber
Principal Architect, Carrier Division
Akamai Technologies GmbH
Parkring 20-22, 85748 Garching
phone: +49.89.9400.6174
mobile: +49.151.22659325
Geschäftsführer: David Matthew McDonald Aitken, Justyna Kalina
Jankowska
Sitz der Gesellschaft: Garching
Amtsgericht München HRB 129886
27 Úno
27 Úno
10:36
Hi Daniel,
Moin Ralf,
Ralf, I also used kdig because of it's TLS support!
And Daniel, you are right, it's a philosophical question!
I came from dig and I was puzzled due to different behavior and it took me
some time to figure out the differences. If something is called that
similar (kdig vs. dig) maybe users expect same behavior? Maybe you could
ship a .kdigrc file, if that is supported by kdig, which mimics dig and
describe the differences in the man pages?
Cheers,
-arsen
* Daniel Salzman <daniel.salzman(a)nic.cz> [2019-02-25 11:01 (+0100)]:
Hi Ralf,
You are correct. This is rather a philosophical question :-) So far we haven't decided
on the main purpose of kdig.
For me kdig is a generic tool for advanced DNS testing. It means the defaults are simple
(e.g. no EDNS, DNS cookies).
The opposite approach is to consider kdig as a tool which knows best how the query should
look like ;-)
Anyway, we are open to change the defaults if it makes sense. So, what do our dear users
think?
Best,
Daniel
On 2/25/19 10:51 AM, Ralf Weber wrote:
> Moin!
>
>
> On 25 Feb 2019, at 10:32, Arsen STASIC wrote:
>
>> Hi,
>>
>> I'm not sure if it was already discussed on this list.
>> Why is BIND's dig getting a AD flag and kdig not?
> Binds dig is using EDNS0 and other unnecessary stuff like cookies per default, while
kdig per default emulates and old style DNS client without bells and whistles, and thus
does not get AD, as this was only defined with DNSSEC (RFC2535/3655/4035). Having EDNS0
support even without setting DO is considered to be able to interpret the AD bit, while
clients without EDNS0 are considered not to be able to interpret it and thus don’t get
it.
>
> So long
> -Ralf
> —--
> Ralf Weber
>
2136
days inactive
2138
days old
7 comments
5 participants
participants (5)
-
Arsen STASIC -
Daniel Salzman -
Daniel Stirnimann -
Ralf Weber -
Vladimír Čunát