subject:"dig query"

Re: use dig query

2021-10-25 Thread Ondřej Surý

Dig arguments are positional and they always were. See the Simple Usage and 
Multiple Queries sections in the manual page for details.

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 26. 10. 2021, at 4:53, Champion Xie  wrote:
> 
> 
> Sorry, there is no clear description of the problem
> I describe the question again
> 
> Any parameters of the dig command should not be in sequence, 
> such as below
> dig 1.1.1.1.in-addr.arpa PTR +trace +nodnssec  VS   dig 1.1.1.1.in-addr.arpa 
> PTR +nodnssec  +trace 
> 
> The output of these two commands after execution cannot achieve the same 
> effect
> 
> Mark Andrews  于2021年10月25日周一 下午12:44写道：
>> Works fine for me.
>> 
>> % bin/dig/dig 1.1.1.1.in-addr.arpa +trace
>> 
>> ; <<>> DiG 9.14.8 <<>> 1.1.1.1.in-addr.arpa +trace
>> ;; global options: +cmd
>> .   331767  IN  NS  f.root-servers.net.
>> .   331767  IN  NS  j.root-servers.net.
>> .   331767  IN  NS  k.root-servers.net.
>> .   331767  IN  NS  l.root-servers.net.
>> .   331767  IN  NS  i.root-servers.net.
>> .   331767  IN  NS  e.root-servers.net.
>> .   331767  IN  NS  h.root-servers.net.
>> .   331767  IN  NS  b.root-servers.net.
>> .   331767  IN  NS  m.root-servers.net.
>> .   331767  IN  NS  g.root-servers.net.
>> .   331767  IN  NS  c.root-servers.net.
>> .   331767  IN  NS  d.root-servers.net.
>> .   331767  IN  NS  a.root-servers.net.
>> .   331767  IN  RRSIG   NS 8 0 518400 2021110417 
>> 2021102216 14748 . 
>> FERgiY720i+bYmHhXGQ2OU7NOoSM8Mhg/OedgoJrJ3Zs17/IJwUnEOkd 
>> EPq98F8ar7Epc9/H0p0ZxQflKrL40q/+6S/KLoR5ecoem7Vp3JN4HMI7 
>> U7z9gobvmBS2f7vekrFp60AXtihCcAypaWRhyl2IZUK7u11tNbN95It+ 
>> D/7IZLa3mFrVgMmeNRdd4uoOWzHxBZ4OusHNlnJ/rvE2smIS9RwEUbDW 
>> iu9/psMZpfEBY5XOLg9ubKog/jma+T6OEINEdH0mzGtv4WoYAStd17Ax 
>> mKHsf1N9PW8rNW+c63Y36VQYXhF+ikhPG3i1Q/a9tJVbN31u5EUtz2yV eUklXw==
>> ;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
>> 
>> in-addr.arpa.   172800  IN  NS  a.in-addr-servers.arpa.
>> in-addr.arpa.   172800  IN  NS  b.in-addr-servers.arpa.
>> in-addr.arpa.   172800  IN  NS  c.in-addr-servers.arpa.
>> in-addr.arpa.   172800  IN  NS  d.in-addr-servers.arpa.
>> in-addr.arpa.   172800  IN  NS  e.in-addr-servers.arpa.
>> in-addr.arpa.   172800  IN  NS  f.in-addr-servers.arpa.
>> in-addr.arpa.   86400   IN  DS  47054 8 2 
>> 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
>> in-addr.arpa.   86400   IN  DS  53696 8 2 
>> 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
>> in-addr.arpa.   86400   IN  DS  63982 8 2 
>> AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
>> in-addr.arpa.   86400   IN  RRSIG   DS 8 2 86400 2021110700 
>> 2021102423 52399 arpa. 
>> cW2ERU/EJzAVftlJSuGmnhXMKaLWDpaP5ZKyw69/x0r5u7wSuksZ9Din 
>> Y/dQi2ggf31k4nFBjLuBPU/FVCqoCc2VmF8RW4L4hIvo1OkcH5j0qMBI 
>> UcnSU8XmRbp7zE0wZfzUaNVX0VHKYr6Z0dMWuhSeB7V4moJ3L6pz0Zj+ 
>> H6zdAaepqE0GRN/DhzuscMEL755BMypHSauBhIuf/J33p1dr4LRfe/mf 
>> 0J0SGB9Cxj555h504vXoCmwf96qwWNTyGzakwVTRVRvtMbIsg+8nJHJ4 
>> pcPHq3kOtrTYdY38z4BtJV0klaJIL2JYNUqFQkOeZRWsNLymz6gnfnBb Pr2oVA==
>> ;; Received 861 bytes from 2001:500:1::53#53(h.root-servers.net) in 308 ms
>> 
>> 1.in-addr.arpa. 86400   IN  NS  ns2.apnic.net.
>> 1.in-addr.arpa. 86400   IN  NS  ns3.lacnic.net.
>> 1.in-addr.arpa. 86400   IN  NS  apnic.authdns.ripe.net.
>> 1.in-addr.arpa. 86400   IN  NS  rirns.arin.net.
>> 1.in-addr.arpa. 86400   IN  NS  apnic1.dnsnode.net.
>> 1.in-addr.arpa. 86400   IN  DS  23004 13 2 
>> 3582737862817D55F8F7473BC58E620CFD4A0E1EF88F05C42C963113 3E32E894
>> 1.in-addr.arpa. 86400   IN  RRSIG   DS 8 3 86400 20211107150454 
>> 2021101714 51651 in-addr.arpa. 
>> FwkrCN7wo52nR6w5E6oyxrxOYWW+gzGK2EaWf0UgCELSKuZLqNFqnlLY 
>> +NWtott7UzXJmSl1OxmO74o13+mKJcgbYaTdbCQCeGgda68hxooP+LQ3 
>> AxEXnKYwyI803nOG9LVxIt03ln8S9r3bOje0i+AvZMjX5D+nO2fbW6K6 rVw=
>> ;; Received 408 bytes from 2001:500:87::87#53(b.in-addr-servers.arpa) in 348 
>> ms
>> 
>> 1.1.1.in-addr.arpa. 86400   IN  NS  ns7.cloudflare.com.
>> 1.1.1.in-addr.arpa. 86400   IN  NS  ns3.cloudflare.com.
>> 99g3opuj99svu7j0634fc9ib4os7hqim.1.in-addr.arpa. 3600 IN NSEC3 1 0 5 
>> 70A93501FFC3E41D 99PTB70MBGKHRHBLB8TLUG7DII191IOA NS
>>

Re: use dig query

2021-10-25 Thread Champion Xie

Sorry, there is no clear description of the problem
I describe the question again

Any parameters of the dig command should not be in sequence,
such as below
dig 1.1.1.1.in-addr.arpa PTR +trace +nodnssec  VS   dig
1.1.1.1.in-addr.arpa PTR +nodnssec  +trace

The output of these two commands after execution cannot achieve the same
effect

Mark Andrews  于2021年10月25日周一 下午12:44写道：

> Works fine for me.
>
> % bin/dig/dig 1.1.1.1.in-addr.arpa +trace
>
> ; <<>> DiG 9.14.8 <<>> 1.1.1.1.in-addr.arpa +trace
> ;; global options: +cmd
> .   331767  IN  NS  f.root-servers.net.
> .   331767  IN  NS  j.root-servers.net.
> .   331767  IN  NS  k.root-servers.net.
> .   331767  IN  NS  l.root-servers.net.
> .   331767  IN  NS  i.root-servers.net.
> .   331767  IN  NS  e.root-servers.net.
> .   331767  IN  NS  h.root-servers.net.
> .   331767  IN  NS  b.root-servers.net.
> .   331767  IN  NS  m.root-servers.net.
> .   331767  IN  NS  g.root-servers.net.
> .   331767  IN  NS  c.root-servers.net.
> .   331767  IN  NS  d.root-servers.net.
> .   331767  IN  NS  a.root-servers.net.
> .   331767  IN  RRSIG   NS 8 0 518400
> 2021110417 2021102216 14748 .
> FERgiY720i+bYmHhXGQ2OU7NOoSM8Mhg/OedgoJrJ3Zs17/IJwUnEOkd
> EPq98F8ar7Epc9/H0p0ZxQflKrL40q/+6S/KLoR5ecoem7Vp3JN4HMI7
> U7z9gobvmBS2f7vekrFp60AXtihCcAypaWRhyl2IZUK7u11tNbN95It+
> D/7IZLa3mFrVgMmeNRdd4uoOWzHxBZ4OusHNlnJ/rvE2smIS9RwEUbDW
> iu9/psMZpfEBY5XOLg9ubKog/jma+T6OEINEdH0mzGtv4WoYAStd17Ax
> mKHsf1N9PW8rNW+c63Y36VQYXhF+ikhPG3i1Q/a9tJVbN31u5EUtz2yV eUklXw==
> ;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
>
> in-addr.arpa.   172800  IN  NS  a.in-addr-servers.arpa.
> in-addr.arpa.   172800  IN  NS  b.in-addr-servers.arpa.
> in-addr.arpa.   172800  IN  NS  c.in-addr-servers.arpa.
> in-addr.arpa.   172800  IN  NS  d.in-addr-servers.arpa.
> in-addr.arpa.   172800  IN  NS  e.in-addr-servers.arpa.
> in-addr.arpa.   172800  IN  NS  f.in-addr-servers.arpa.
> in-addr.arpa.   86400   IN  DS  47054 8 2
> 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
> in-addr.arpa.   86400   IN  DS  53696 8 2
> 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
> in-addr.arpa.   86400   IN  DS  63982 8 2
> AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
> in-addr.arpa.   86400   IN  RRSIG   DS 8 2 86400
> 2021110700 2021102423 52399 arpa.
> cW2ERU/EJzAVftlJSuGmnhXMKaLWDpaP5ZKyw69/x0r5u7wSuksZ9Din
> Y/dQi2ggf31k4nFBjLuBPU/FVCqoCc2VmF8RW4L4hIvo1OkcH5j0qMBI
> UcnSU8XmRbp7zE0wZfzUaNVX0VHKYr6Z0dMWuhSeB7V4moJ3L6pz0Zj+
> H6zdAaepqE0GRN/DhzuscMEL755BMypHSauBhIuf/J33p1dr4LRfe/mf
> 0J0SGB9Cxj555h504vXoCmwf96qwWNTyGzakwVTRVRvtMbIsg+8nJHJ4
> pcPHq3kOtrTYdY38z4BtJV0klaJIL2JYNUqFQkOeZRWsNLymz6gnfnBb Pr2oVA==
> ;; Received 861 bytes from 2001:500:1::53#53(h.root-servers.net) in 308 ms
>
> 1.in-addr.arpa. 86400   IN  NS  ns2.apnic.net.
> 1.in-addr.arpa. 86400   IN  NS  ns3.lacnic.net.
> 1.in-addr.arpa. 86400   IN  NS  apnic.authdns.ripe.net.
> 1.in-addr.arpa. 86400   IN  NS  rirns.arin.net.
> 1.in-addr.arpa. 86400   IN  NS  apnic1.dnsnode.net.
> 1.in-addr.arpa. 86400   IN  DS  23004 13 2
> 3582737862817D55F8F7473BC58E620CFD4A0E1EF88F05C42C963113 3E32E894
> 1.in-addr.arpa. 86400   IN  RRSIG   DS 8 3 86400
> 20211107150454 2021101714 51651 in-addr.arpa.
> FwkrCN7wo52nR6w5E6oyxrxOYWW+gzGK2EaWf0UgCELSKuZLqNFqnlLY
> +NWtott7UzXJmSl1OxmO74o13+mKJcgbYaTdbCQCeGgda68hxooP+LQ3
> AxEXnKYwyI803nOG9LVxIt03ln8S9r3bOje0i+AvZMjX5D+nO2fbW6K6 rVw=
> ;; Received 408 bytes from 2001:500:87::87#53(b.in-addr-servers.arpa) in
> 348 ms
>
> 1.1.1.in-addr.arpa. 86400   IN  NS  ns7.cloudflare.com.
> 1.1.1.in-addr.arpa. 86400   IN  NS  ns3.cloudflare.com.
> 99g3opuj99svu7j0634fc9ib4os7hqim.1.in-addr.arpa. 3600 IN NSEC3 1 0 5
> 70A93501FFC3E41D 99PTB70MBGKHRHBLB8TLUG7DII191IOA NS
> 99g3opuj99svu7j0634fc9ib4os7hqim.1.in-addr.arpa. 3600 IN RRSIG NSEC3 13 4
> 3600 20211105031842 20211021014842 2679 1.in-addr.arpa.
> PrGfRRQwXHSY237HPzTEAepc5ylC2v99BOEGlzfwIAN6lbYEapX2AoqL
> YzlBnk4PyfftZS+xURjjkS+kxzLWcA==
> ;; Received 333 bytes from 203.119.95.53#53(ns2.apnic.net) in 29 ms
>
> 1.1.1.in-addr.arpa. 3600IN  SOA alec.ns.cloudflare.com.
> dns.cloudflare.com. 2036583626 1 2400 604800 3600
> ;; Received 111 bytes from 162.159.4.8#53(ns7.cloudflare.com) in 17 ms
>
> % bin/dig/dig

Re: use dig query

2021-10-24 Thread Mark Andrews

Works fine for me.

% bin/dig/dig 1.1.1.1.in-addr.arpa +trace 

; <<>> DiG 9.14.8 <<>> 1.1.1.1.in-addr.arpa +trace
;; global options: +cmd
.   331767  IN  NS  f.root-servers.net.
.   331767  IN  NS  j.root-servers.net.
.   331767  IN  NS  k.root-servers.net.
.   331767  IN  NS  l.root-servers.net.
.   331767  IN  NS  i.root-servers.net.
.   331767  IN  NS  e.root-servers.net.
.   331767  IN  NS  h.root-servers.net.
.   331767  IN  NS  b.root-servers.net.
.   331767  IN  NS  m.root-servers.net.
.   331767  IN  NS  g.root-servers.net.
.   331767  IN  NS  c.root-servers.net.
.   331767  IN  NS  d.root-servers.net.
.   331767  IN  NS  a.root-servers.net.
.   331767  IN  RRSIG   NS 8 0 518400 2021110417 
2021102216 14748 . FERgiY720i+bYmHhXGQ2OU7NOoSM8Mhg/OedgoJrJ3Zs17/IJwUnEOkd 
EPq98F8ar7Epc9/H0p0ZxQflKrL40q/+6S/KLoR5ecoem7Vp3JN4HMI7 
U7z9gobvmBS2f7vekrFp60AXtihCcAypaWRhyl2IZUK7u11tNbN95It+ 
D/7IZLa3mFrVgMmeNRdd4uoOWzHxBZ4OusHNlnJ/rvE2smIS9RwEUbDW 
iu9/psMZpfEBY5XOLg9ubKog/jma+T6OEINEdH0mzGtv4WoYAStd17Ax 
mKHsf1N9PW8rNW+c63Y36VQYXhF+ikhPG3i1Q/a9tJVbN31u5EUtz2yV eUklXw==
;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

in-addr.arpa.   172800  IN  NS  a.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  b.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  c.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  d.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  e.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  f.in-addr-servers.arpa.
in-addr.arpa.   86400   IN  DS  47054 8 2 
5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa.   86400   IN  DS  53696 8 2 
13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa.   86400   IN  DS  63982 8 2 
AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa.   86400   IN  RRSIG   DS 8 2 86400 2021110700 
2021102423 52399 arpa. 
cW2ERU/EJzAVftlJSuGmnhXMKaLWDpaP5ZKyw69/x0r5u7wSuksZ9Din 
Y/dQi2ggf31k4nFBjLuBPU/FVCqoCc2VmF8RW4L4hIvo1OkcH5j0qMBI 
UcnSU8XmRbp7zE0wZfzUaNVX0VHKYr6Z0dMWuhSeB7V4moJ3L6pz0Zj+ 
H6zdAaepqE0GRN/DhzuscMEL755BMypHSauBhIuf/J33p1dr4LRfe/mf 
0J0SGB9Cxj555h504vXoCmwf96qwWNTyGzakwVTRVRvtMbIsg+8nJHJ4 
pcPHq3kOtrTYdY38z4BtJV0klaJIL2JYNUqFQkOeZRWsNLymz6gnfnBb Pr2oVA==
;; Received 861 bytes from 2001:500:1::53#53(h.root-servers.net) in 308 ms

1.in-addr.arpa. 86400   IN  NS  ns2.apnic.net.
1.in-addr.arpa. 86400   IN  NS  ns3.lacnic.net.
1.in-addr.arpa. 86400   IN  NS  apnic.authdns.ripe.net.
1.in-addr.arpa. 86400   IN  NS  rirns.arin.net.
1.in-addr.arpa. 86400   IN  NS  apnic1.dnsnode.net.
1.in-addr.arpa. 86400   IN  DS  23004 13 2 
3582737862817D55F8F7473BC58E620CFD4A0E1EF88F05C42C963113 3E32E894
1.in-addr.arpa. 86400   IN  RRSIG   DS 8 3 86400 20211107150454 
2021101714 51651 in-addr.arpa. 
FwkrCN7wo52nR6w5E6oyxrxOYWW+gzGK2EaWf0UgCELSKuZLqNFqnlLY 
+NWtott7UzXJmSl1OxmO74o13+mKJcgbYaTdbCQCeGgda68hxooP+LQ3 
AxEXnKYwyI803nOG9LVxIt03ln8S9r3bOje0i+AvZMjX5D+nO2fbW6K6 rVw=
;; Received 408 bytes from 2001:500:87::87#53(b.in-addr-servers.arpa) in 348 ms

1.1.1.in-addr.arpa. 86400   IN  NS  ns7.cloudflare.com.
1.1.1.in-addr.arpa. 86400   IN  NS  ns3.cloudflare.com.
99g3opuj99svu7j0634fc9ib4os7hqim.1.in-addr.arpa. 3600 IN NSEC3 1 0 5 
70A93501FFC3E41D 99PTB70MBGKHRHBLB8TLUG7DII191IOA NS
99g3opuj99svu7j0634fc9ib4os7hqim.1.in-addr.arpa. 3600 IN RRSIG NSEC3 13 4 3600 
20211105031842 20211021014842 2679 1.in-addr.arpa. 
PrGfRRQwXHSY237HPzTEAepc5ylC2v99BOEGlzfwIAN6lbYEapX2AoqL 
YzlBnk4PyfftZS+xURjjkS+kxzLWcA==
;; Received 333 bytes from 203.119.95.53#53(ns2.apnic.net) in 29 ms

1.1.1.in-addr.arpa. 3600IN  SOA alec.ns.cloudflare.com. 
dns.cloudflare.com. 2036583626 1 2400 604800 3600
;; Received 111 bytes from 162.159.4.8#53(ns7.cloudflare.com) in 17 ms

% bin/dig/dig 1.1.1.1.in-addr.arpa +trace +nodnssec

; <<>> DiG 9.14.8 <<>> 1.1.1.1.in-addr.arpa +trace +nodnssec
;; global options: +cmd
.   331756  IN  NS  k.root-servers.net.
.   331756  IN  NS  i.root-servers.net.
.   331756  IN  NS  g.root-servers.net.
.   331756  IN  NS  j.root-servers.net.
.   331756  IN  NS  b.root-servers.net.
.   331756  IN  NS

use dig query

2021-10-24 Thread Champion Xie

 dig version 9.14.8

Using the following command can not achieve the desired effect, dnssec
information will still be output
dig 1.1.1.1.in-addr.arpa   +trace +nodnssec

Normally, the parameters should not be in sequence


-- 
Best Regards!!
champion_xie
___
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

dig query

2012-08-13 Thread John Williams

I've a system with two interfaces; a management and a data interface.  My 
default route is set out to the data interface.  

doing a 


dig +tcp someIP.com @some.resolver 


works fine.

If I want a UDP based query, I have to specify -b option and provide IP of the 
interface otherwise it fails.

Why is that?

I would imagine the query would travel out the default route of the host.

Thanks.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dig query

2012-08-13 Thread Kevin Oberman

On Mon, Aug 13, 2012 at 10:18 AM, John Williams john.1...@yahoo.com wrote:
 I've a system with two interfaces; a management and a data interface.  My
 default route is set out to the data interface.

 doing a

 dig +tcp someIP.com @some.resolver

 works fine.

 If I want a UDP based query, I have to specify -b option and provide IP of
 the interface otherwise it fails.

 Why is that?

 I would imagine the query would travel out the default route of the host.

It certainly should. You might try a traceroute to the server and
confirm how it goes out.
But the problem is probably NOT how it goes out, but how it comes
back. '-b' sets the source address of the packets that will appear in
the IP header, but does not specify the route it should take. Sounds
line the default ADDRESS placed in the outgoing packets night not be
what you expect and that the return path might be hitting a firewall
that allows TCP established packets. Of course, established does not
work or UDP, but by forcing the source, the response is hitting the
data interface, where it is permitted.

This is largely guesswork, but use of tcpdump and looking at the the
counter/logs of any firewall should confirm this or let you move on to
other options.
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dig query

2010-01-06 Thread Pamela Rock

The following dig query

dig gov +dnssec +noadflag @10.10.10.1

produces the following flags in the header section:

;; flags: qr rd ra ad;

Question - what is the relation with the +dnssec and +noadflag options in the 
query.  I would think the query would produce a signed response with no ad bit 
in the header section.  Why does ad show up when I specify +noadflag?

Thanks!!


  
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dig query

2010-01-06 Thread Alan Clegg

Pamela Rock wrote:
 The following dig query
 
 dig gov +dnssec +noadflag @10.10.10.1
 
 produces the following flags in the header section:
 
 ;; flags: qr rd ra ad;
 
 Question - what is the relation with the +dnssec and +noadflag
 options in the query.  I would think the query would produce a signed
 response with no ad bit in the header section.  Why does ad show up
 when I specify +noadflag?

AD is set when authentication is successful by the server to whom you
are sending the query.  The +noadflag says don't set the AD bit in the
outbound query (which is the default).

AlanC
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dig query

2010-01-06 Thread Alan Clegg

Tony Finch wrote:
 On Wed, 6 Jan 2010, Pamela Rock wrote:
 Does that imply that +adflag sets the ad bit on the query and the
 response where +dnssec only sets the ad bit on the responce?
 
 The AD flag is meaningless in a query. In a response it tells you whether
 the server is authoritative or not. It has nothing to do with DNSSEC.

Actually, BIND implements something a bit different..

If a query is sent with the AD bit set, the the flag is NOT reset if the
upstream server succeeds in validating the data, even if the DO bit is
not set.  If the data is not authenticated, the AD bit is reset in the
response.

This allows one to send a query to a BIND server that proves data to be
validated (set AD on query, watch for AD on response) without having all
of the DNSSEC related data (signatures, etc) in the response packet.

AlanC
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dig query

2010-01-06 Thread Jeremy C. Reed

On Wed, 6 Jan 2010, Michael Sinatra wrote:

 I tried this out and I noticed that both BIND and unbound appear to 
 behave the same way when using dig in this manner.  So both of the 
 major validating implementations support it.  I don't see specific 
 reference to using the AD flag in queries in the RFCs (at least on a 
 cursory glance), but it's a very useful feature.

See bottom of 4.7 in 
http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-09
about using AD in query.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dig query

2010-01-06 Thread Evan Hunt

 I don't see specific reference to using the AD flag in queries in the
 RFCs (at least on a cursory glance), but it's a very useful feature.

We're kind of flying under the RFC's radar, as I understand it.  The RFC
says the server must ignore the AD flag in a query.  What we do, though,
is clear the AD flag when answering if the signatures don't validate, but
*leave it alone* if they do.  So if you did happen to set the AD flag, and
the answer validated, then it would still be set when you got your response.

I don't know of any RFC that expressly describes this usage (though I may
have missed one), but in any case it's not forbidden, and it's useful, so...

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: use dig query

Re: use dig query

Re: use dig query

use dig query

dig query

Re: dig query

dig query

Re: dig query

Re: dig query

Re: dig query

Re: dig query

11 matches

Site Navigation

Mail list logo

Footer information