DNSSEC regulatory requirements?

[Josh Kuo]

Hi all,

I know this is a strange request. I am trying to encourage more people to
deploy DNSSEC (either authoritative or recursive/validating). Are there any
compliance or regulatory requirements that suggest/recommend the use of
DNSSEC?

The only one I know of is the very dated US OMB memo from 2008. I see
several European domains have better DNSSEC deployment rates (such as .de).
Are there any regulations or friendly recommendations from some kind of
governing body at work here?

Thank you.

-Josh
-- 
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

Re: Does DNSSEC increased packet size reach end computers?

[Josh Kuo]

You are correct. Normal stub resolvers on desktop clients or mobile devices
only see the AD flag (or SERVFAIL when validation fails). They will only
get all the additional DNSSEC record types if they used the +dnssec option
in dig (which sets the DO bit in the outbound query).

On Tue, Apr 11, 2023 at 3:12 PM Bob Harold  wrote:

> I was in the process of setting up a test server with DNSSEC signed
> domains, and asking users to point at the test server to see if the larger
> packets affected their application, when I realized I might be wrong.
> DNS Resolvers will get bigger responses from DNS Authoritative servers
> because of DNSSEC signatures.  But clients, running stub resolvers, will
> likely set the +AD flag and expect the DNS Resolver to validate, but the
> client will get a response that does not include any DNSSEC records.  Is
> that correct?
>
> So I only need to worry about increased packet sizes between DNS Resolvers
> and DNS Authoritative servers?
>
> (Granted, the actual answer size to the client could be large enough to
> cause fall-back to TCP, but that is not because of DNSSEC.)
>
> --
> Bob Harold
> --
> 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
>
-- 
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

Question regarding delv and custom local trust anchor

[Josh Kuo]

Hello,
I am trying to use delv (version 19.8.2 on Ubuntu 0.22.04) to troubleshoot
using a custom trust anchor. However, I am getting very strange results
from delv. The short of it is, I must point delv at another validating
resolver (such as @8.8.8.8) for the custom trust anchors (-a) to work.

First, I use the correct trust anchor (right.key), I query twice, with and
without @8.8.8.8:

$ *cat right.key*
trust-anchors {
. initial-key 257 3 8
"AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=";
};


*$ delv -a right.key www.example.com . A*;; broken
trust chain resolving 'www.example.com/A/IN': 127.0.0.53#53
;; resolution failed: broken trust chain


*$ delv -a right.key www.example.com . A @8.8.8.8
*; fully validated
www.example.com. 10545 IN A 93.184.216.34
www.example.com. 10545 IN RRSIG A 13 3 86400 20230626193619 20230605194008
44029 example.com. grjd2rY82fZuYxz3laDCQKu2ZbcOmy4/eApedHRVFsMGOGwmLJ3FU08D
2dr4BWtpVm12HAgyt0euyGCcQLDErg==

Then, I tested it with a purposely misconfigured key. Again, two queries,
with and without @8.8.8.8:

*$ cat wrong.key*
trust-anchors {
. initial-key 257 3 8
"AwEAAcxpNx7yHa+8KpYjdi8wPJw8cXusWGo2deQsPANOJFDhF4Dx2NTrEjvIDMGymLpXLSj7PpAzbhBwcKMQ/WEUprTl7Dfn26HYXFl3K0U4AahZO99seYkQao82n21VkfjguSv1SXmzerrwsGXP91CncXJ7Apz8wieJDLe3u4gA/DkqvjeCtE+sf+DcSqalnKgY6TWmKFX0VPPL2W3TXwLHyfVh5AWV2mGpugJ4YUoqtmDgXwOjUvkZDxQFsliE/iYc1S9tYVD40fbfL3l8vRXoVfListNNQBKh7oDXpPKEXgOn5kl8V05hcG1LAbB0jtOtPdgs+BJ+3WN0o2q+PSo9QVE=";
};


*$ delv -a wrong.key www.example.com . A*;; broken
trust chain resolving 'www.example.com/A/IN': 127.0.0.53#53
;; resolution failed: broken trust chain


*$ delv -a wrong.key www.example.com . A @8.8.8.8
*;; validating ./DNSKEY: no valid signature found (DS)
;; no valid RRSIG resolving './DNSKEY/IN': 8.8.8.8#53
;; broken trust chain resolving 'com/DS/IN': 8.8.8.8#53
;; broken trust chain resolving 'com/DNSKEY/IN': 8.8.8.8#53
;; broken trust chain resolving 'example.com/DS/IN': 8.8.8.8#53
;; broken trust chain resolving 'example.com/DNSKEY/IN': 8.8.8.8#53
;; broken trust chain resolving 'www.example.com/A/IN': 8.8.8.8#53
;; resolution failed: broken trust chain

This has me scratching my head... I know delv is capable of acting as a
validating resolver. And I want it to. What am I doing wrong? What other
information can I provide? +vtrace?

A note about why I am doing this seemingly pointless exercise: Back in
2018/2019 during the first root key rollover, several others experienced
the issue where the trust anchor on their validating resolver(s) did not
change, resulting in SERVFAIL. Not everyone has access to the validating
resolver's configuration, in fact, some of them had to prove to their ISP
or whoever is running the validating resolver that it's the trust anchor
that needs to be updated. This is an exercise that I am planning to teach
others, so when/if this happens again the next time the root key rolls,
they know how to use delv to produce evidence to show their DNS
administrators to update the trust anchor.

Thanks in advance.

-Josh
-- 
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

Re: Question about resolver

[Josh Kuo]

DS = Delegation Signer, it is the record type that a signed child upload to
the parent zone. It's difficult to say for sure without more information
such as which domain name you are trying to resolve, but looks like it is
probably due to a mis-matching DS record between the child and the parent
(security lameness).

You can use tools such as https://dnssec-analyzer.verisignlabs.com/online
to help you analyze further. If you need to refresh your knowledge on how
DNSSEC works, see the ISC DNSSEC Guide:
https://bind9.readthedocs.io/en/v9.18.14/dnssec-guide.html

-Josh

On Wed, Apr 24, 2024 at 7:31 PM J Doe  wrote:

> Hello,
>
> I run BIND 9.18.26 as a recursive, validating resolver.  In my logs, I
> noticed the following:
>
>  22-Apr-2024 19:25:59.614 lame-servers: info: chase DS servers
>  resolving '180.96.34.in-addr.arpa/DS/IN': 216.239.34.102#53
>
> What does "chase DS servers" mean ?
>
> Thanks,
>
> - J
> --
> 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
>
-- 
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

Re: Question about resolver

[Josh Kuo]

>
> In this particular case, isn't the resolver attempting to do a reverse
> lookup of the IP address that's listed ?
>
>
You are right, I missed that this is a reverse-mapping zone. In that case,
run DNSSEC analyzer on the domain "180.96.34.in-addr.arpa" and you'll see
the problem. Reverse-mapping zones work the same as forward-mapping zones,
they also need to be delegated properly.

If you prefer a more visual output, try DNSViz:
https://dnsviz.net/d/180.96.34.in-addr.arpa/dnssec/
-- 
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

Re: Should Root Servers Always be Queried First? bind9.7.7

[Josh Kuo]

In other words, if your goal is to identify latency in your resolver, it's
probably best to run tcpdump on the resolver itself, and analyze the
traffic capture to see if there are any latency. The +trace shows you what
"should" happen.


On Wed, Nov 7, 2012 at 3:05 PM, david  wrote:

>
> The +trace option ignores the resolver that you specify after the "@" sign,
> and begins at the root.
>
>
>  -DTK
>
> -Original Message-
> From: bind-users-bounces+root=nachtmaus...@lists.isc.org
> [mailto:bind-users-bounces+root=nachtmaus...@lists.isc.org] On Behalf Of
> Martin McCormick
> Sent: Wednesday, November 07, 2012 1:13 PM
> To: bind-users@lists.isc.org
> Subject: Should Root Servers Always be Queried First? bind9.7.7
>
> If I do:
>
> dig @localhost +short +trace somehost.okstate.edu
>
> on a server authoritative for the okstate.edu domain, I would expect
> resolution via that authoritative system. I do get it but the query takes
> the scenic route and I get all the root name servers just as if the query
> was for some host outside our domains.
>
>
> Why? We are having issues with random latency right now so I
> started
> checking everything I could and that is how I discovered this. I don't know
> if that is normal or not ___
> 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
>
> ___
> 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
>
___
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: Digging to the final IP

[Josh Kuo]

If all you are after is one of the final IP addresses (not the entire 
set), then using a "dumb" client might be easier. For instance, 'ping'.


$ ping -q -c1 www.google.com
PING www.google.com (203.66.155.113): 56 data bytes


If you want to get more than one IP address, then you'll need an 
intelligent client such as 'host' or 'dig:


$ host www.google.com
www.google.com has address 203.66.155.49
www.google.com has address 203.66.155.50
www.google.com has address 203.66.155.44
...
www.google.com has address 203.66.155.45
www.google.com has IPv6 address 2404:6800:4008:c03::67



On 10/20/14, 12:03 PM, Fajar A. Nugraha wrote:

What are you using this for?

If it's part of a script, it might be easier to just use gethostbyname. For
example, in php: http://php.net/manual/en/function.gethostbyname.php ,
Returns the IPv4 address or a string containing the unmodified hostname on
failure.



___
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


___
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: Access external hosts with internal split DNS resolver

[Josh Kuo]

Add www.mydomain.co.nz to your internal zone, that is one common way to deal 
with it. With BIND you can keep the common records in a separate file and use 
"include" statement to avoid double entry.



> On Aug 9, 2015, at 12:50 AM, Dave Koelmeyer 
>  wrote:
> 
>> On 09/08/15 16:44, Dave Koelmeyer wrote:
>> 
>> - lookups to www.mydomain.co.nz fail, where www.mydomain.com is my
>> public webserver defined in my domain registrar's zone file
> 
> Correction: this should obviously read "lookups to www.mydomain.co.nz
> fail, where www.mydomain.co.nz is my public webserver defined in my
> domain registrar's zone file".
> 
> 
> -- 
> Dave Koelmeyer
> http://blog.davekoelmeyer.co.nz
> GPG Key ID: 0x238BFF87
> ___
> 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
___
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: recursive resolver

[Josh Kuo]

In order for us to help you better, you need to provide more information.
What makes you think The recursive resolver is slow? Do you have syslog? Is
the BIND instance slow, or is it the operating system (low RAM? Slow disk?)
or is this a network-related issue?

On Thu, Mar 12, 2020 at 11:00 AM ShubhamGoyal  wrote:

>  Dear sir,
> how can we improve my DNS Recursive
> resolver speed.
>
> Best Regards,
> Shubham Goyal
> Cyber Security Group
> Centre for Development of Advanced Computing
> Bangalore
>
> [image: 150th Anniversary Mahatma Gandhi]
>
> 
>
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
>
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies and the original message. Any unauthorized review, use,
> disclosure, dissemination, forwarding, printing or copying of this email
> is strictly prohibited and appropriate legal action will be taken.
> 
>
> ___
> 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
>
___
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: DNS error, from a newbee to the real experts..

[Josh Kuo]

>From what you posted, it appears when you query the recursive server NS1
(192.168.14.10), it returns no error, it gives back NXDOMAIN with the AD
flag. That would indicate DNSSEC worked. That does not match the log
messages you posted, that would indicate there's a DNSSEC validation error,
and you should have received SERVFAIL.

On Mon, Jul 20, 2020 at 11:47 PM Weeltin  wrote:

> Hi Josh,
>
> Thanks for your answer, it made me go trough all the config again, just to
> make sure that it wasnt pointing to the authoritative server anywhere but
> in the configuration of the recursive server
>
> I saw that "“recursion requested but not available" when i send the query
> against the authoritative. Kind a expected that, since it aint allowed to
> do recursion.
>
> as requested i made the dig on the the authoritative server i get the
> correct answer, so i expect it has loaded the zonefiles correctly.
>
> ns2:/home/weeltin# dig @127.0.0.01 example.home
>
> ; <<>> DiG 9.14.12 <<>> @127.0.0.01 example.home
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45487
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: b9129ece5d9fbc3e6f01a2215f15a461388d4af048be37fa (good)
> ;; QUESTION SECTION:
> ;example.home. IN A
>
> ;; AUTHORITY SECTION:
> example.home. 604800 IN SOA ns2.example.home. hostmaster.example.home. 2
> 604800 86400 2419200 604800
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Mon Jul 20 14:04:17 UTC 2020
> ;; MSG SIZE  rcvd: 120
>
>
> just to be sure, i rand the dig command again on my client
>
> [weeltin@c1 ~]$ dig c1.example.home
>
> ; <<>> DiG 9.11.11-RedHat-9.11.11-1.fc31 <<>> c1.example.home
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1787
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 862cc48a975a32a324cd14e65f15ba5e3f2c972d1f753586 (good)
> ;; QUESTION SECTION:
> ;c1.example.home. IN A
>
> ;; AUTHORITY SECTION:
> . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020072000
> 1800 900 604800 86400
>
> ;; Query time: 1043 msec
> ;; SERVER: 192.168.14.10#53(192.168.14.10)
> ;; WHEN: Mon Jul 20 11:38:06 EDT 2020
> ;; MSG SIZE  rcvd: 147
>
>
> Log output from NS1 (recursive)
> 
> Jul 20 15:38:05 ns1 daemon.info named[4022]:   validating
> example.home/SOA: got insecure response; parent indicates it should be
> secure
> Jul 20 15:38:05 ns1 daemon.info named[4022]: no valid RRSIG resolving
> 'c1.example.home/DS/IN': 192.168.14.20#53
> Jul 20 15:38:06 ns1 daemon.info named[4022]: insecurity proof failed
> resolving 'c1.example.home/A/IN': 192.168.14.20#53
> 
>
> and there is no log entries on the authoritative server
>
> /Weeltin
>
> On Sun, Jul 19, 2020 at 6:05 AM Josh Kuo  wrote:
>
>> When querying your internal domain, I see the query actually ends with
>> “recursion requested but not available”, it looks like you are querying
>> directly against your auth server, so I would check the setting to ensure
>> the zone file is actually loaded correctly.
>>
>> What Mark answered is assuming you are querying the recursive which then
>> returned SERVFAIL due to DNSSEC validation, but I do not see that in the
>> information you provided.
>>
>> Can you run dig on the auth server itself, dig @ 127.0.0.1 for
>> example.home, and see what it returns?
>>
>>
>>
___
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

Re: Testing my configuration

[Josh Kuo]

dig @nameserver zone axfr

For example:

dig @10.10.10.10 my.domain.com axfr

you need to allow zone transfer.

On Wed, Dec 17, 2008 at 1:50 AM, Fred Zinsli  wrote:
> Hello all
>
> Well I have a basic setup going and it seems to function.
>
> What I am wanting to know is, is there a way of getting all of the
> information pertaining to a specific domain name.
>
> Currently I am using nslookup and dig, but I only seem to get basic
> information.
>
> IE, dig domain.com only produces ns and A record information.
> I have done things like dig txt chaos domain.com
>
> I am wanting to be able to see all entries, A,MX,PTR,CNAME,TXT,etc
>
> Any comments would be most helpful.
>
> Regards
>
> Fred
>
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problem resolving "www.lmsintl.com"

[Josh Kuo]

Make sure your Windows client is not appending any additional suffix
to your domain name by adding a . to the end of your domain name. So
for example, your nslookup command should look something similar to
this:

nslookup www.lmsintl.com.

What happens when you do "dig www.lmsintl.com. a"? Does it return the
proper answer?


On Wed, Jan 7, 2009 at 11:37 AM, Apisa, Kathy (US - MABS)
 wrote:
> I am running bind 9,4.2-P2 on windows and can resolve all external Domains
> names with the exception of www.lmsintl.com
>
>
>
> Doing a "dig www.lmsintl.com +trace returns the proper address
>
> If I do a ping or nslookup on www.lmsintl.com I get an error can't find
> www.lmsintl.com: server failed therefore I am unable to access their
> website.
>
>
>
> Any suggestions.
>
>
>
> Thanks much,
>
> Kathy Apisa
>
> 
>
> Information Technology
>
> 330-796-5963 (voice)
>
> 330-796-9805 (fax)
>
> kathy.ap...@meggitt.com
>
>
>
> This email may contain proprietary information and/or copyright material.
> This email is intended for the use of the addressee only. Any unauthorized
> use may be unlawful. If you receive this email by mistake, please advise the
> sender immediately by using the reply facility in your email software.
>
> Information contained in and/or attached to this document may be subject to
> export control regulations of the European Community, USA, or other
> countries. Each recipient of this document is responsible to ensure that
> usage and/or transfer of any information contained in this document complies
> with all relevant export control regulations. If you are in any doubt about
> the export control restrictions that apply to this information, please
> contact the sender immediately.
>
> Be aware that Meggitt may monitor incoming and outgoing emails to ensure
> compliance with the Meggitt IT User policy.
>
> This transmittal and any attached documents may contain technical data, the
> use of which may be restricted by the U.S. Arms Export Control Act and/or
> the Export Administration Act. By accepting such data, the recipient agrees
> to comply with the International Traffic in Arms Regulations (ITAR) and/or
> the Export Administration Regulations, as applicable.
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to perform nslookup of local domains

[Josh Kuo]

Looks like your DNS servers 192.243.130.42 and 192.243.160.18 are not
responding to DNS queries (thus the SERFAIL message).

When trying this from my house, this is what I get:

First, get the name servers for your domain osmre.gov from the DNS
server at 4.2.2.2:

$ dig @4.2.2.2 osmre.gov ns

; <<>> DiG 9.4.2-P2 <<>> @4.2.2.2 osmre.gov ns
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16977
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;osmre.gov. IN  NS

;; ANSWER SECTION:
osmre.gov.  28395   IN  NS  gb.osmre.gov.
osmre.gov.  28395   IN  NS  nomad.osmre.gov.

;; Query time: 22 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Fri Jan 16 10:03:40 2009
;; MSG SIZE  rcvd: 64

Next, try to query each one of the two name servers about www.osmre.gov:

(trying nomad.osmre.gov first, this failed):

$ dig @nomad.osmre.gov www.osmre.gov. a

; <<>> DiG 9.4.2-P2 <<>> @nomad.osmre.gov www.osmre.gov. a
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50624
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.osmre.gov. IN  A

;; Query time: 103 msec
;; SERVER: 192.243.130.42#53(192.243.130.42)
;; WHEN: Fri Jan 16 10:05:06 2009
;; MSG SIZE  rcvd: 31



Try the next name server gb.osmre.gov, this gave an answer:

$ dig @gb.osmre.gov www.osmre.gov. a

; <<>> DiG 9.4.2-P2 <<>> @gb.osmre.gov www.osmre.gov. a
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17158
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.osmre.gov. IN  A

;; ANSWER SECTION:
www.osmre.gov.  28800   IN  CNAME   ismhdqf07a.osmre.gov.
ismhdqf07a.osmre.gov.   28800   IN  A   192.243.130.2

;; AUTHORITY SECTION:
osmre.gov.  28800   IN  NS  nomad.osmre.gov.
osmre.gov.  28800   IN  NS  gb.osmre.gov.

;; ADDITIONAL SECTION:
gb.osmre.gov.   28800   IN  A   192.243.160.18
nomad.osmre.gov.28800   IN  A   192.243.130.42

;; Query time: 82 msec
;; SERVER: 192.243.160.18#53(192.243.160.18)
;; WHEN: Fri Jan 16 10:05:46 2009
;; MSG SIZE  rcvd: 141


>From the above results, it looks like your name server nomad.osmre.gov
(192.243.130.42) is not functioning correctly, but the server
gb.osmre.gov (192.243.160.18) is giving back answers. I am not sure
why when you try it from your location that even gb.osmre.gov will not
respond.

You can turn on query logging on BIND, and see if your queries are
actually making it all the way to the DNS servers.

Hope this helps.


On Fri, Jan 16, 2009 at 9:33 AM, Mark A. Moore  wrote:
> We are having a problem doing an nslookup locally from our BIND DNS Servers
> (Master & Secondary) for our own domains.  However we can run nslookup on
> other domains (ie yahoo, google) with no problems.  Even if we stop iptables
> we still get the same error. We see no errors when BIND starts. Below is the
> command output.  Does this have anything to do with /etc/hosts or
> /etc/resolv.conf files? We've verified permissions on the directory/files.
>
>
>
> nslookup www.osmre.gov
>
> ;; Got SERVFAIL reply from 192.243.130.42, trying next server
>
> Server: 192.243.160.18
>
> Address:192.243.160.18#53
>
>
>
> ** server can't find www.osmre.gov: SERVFAIL
>
>
>
> Thanks for any help provided.
>
> Mark
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS spoofing

[Josh Kuo]

One of the ways you can try is to setup a zone for somedomain.com on
your DNS server, assuming your users will query your DNS servers for
any outbound recursive lookups. Just create the entries you want in
somedomain.com, and your users will get those answers.

If your main DNS server is different from the DNS resolver that users
point to, you will need to create a forward zone on the resolver to
point anything in somedomain.com to your main DNS server (where your
own version of the somedomain.com data resides).

Hope this helps.

On Fri, Jan 16, 2009 at 10:11 AM, Rob Z  wrote:
> Hello,
> we need to deliberately point some of our DNS clients to a host with a
> different IP.
> Basically, when a client on a certain subnet asks for a host.somedomain.com
> they should get an address for host.mydomain.com.
> All other DNS information for somedomain.com must be valid for all of my
> clients.
> I have no control over somedomain.com DNS but I have full controll over our
> DNS servers.
> What is the best way of doing this with bind?  What are other ways of doing
> this (eg modify local resolvers)?
> Any ideas are greatly appreciated.
> --
> Rob
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS spoofing

[Josh Kuo]

Oops, I missed that part. Sorry, yes, as Ben pointed out, my proposed
solution will take over *ALL* records in somedomain.com, anything you
don't list in your somedomain.com will NOT be resolved.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: forwarding but no recursion?

[Josh Kuo]

I believe the behavior of the following configuration is to send back
the IP address of the forwarders to the clients, and rely on clients
to do the recursive query against the forwarders.


On Tue, Jan 20, 2009 at 9:25 AM,   wrote:
>
> Hello,
>
> Is this possible to disable recursion for all incoming queries except
> for those listed in zone statement with a forwarder.
>
> I know that no forwarding is allowed if we disable recursion.
>
> Something like this ( but this doesn't work I know ):
>
> I can't match people so I can't create a view.
>
> options {
>
>allow-query { any; };
>allow-query-cache { none; };
>allow-recursion { none; };
>
> };
>
> zone "example.fr" {
>
>type forward;
>forwarders { x.x.x.x; };
>forward only;
> };
>
> Thank you for your advice.
>
> Emmanuel
>
>
> *
> This message and any attachments (the "message") are confidential and 
> intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered, changed 
> or falsified.
> If you are not the intended addressee of this message, please cancel it 
> immediately and inform the sender.
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: 512 byte limit

[Josh Kuo]

> 1) If a reply is over 512 bytes, which can't in theory be done via UDP,
> should the queried server reply telling my resolver to ask again using
> TCP?  Assuming, as one normally should, that there are firewalls, the
> queried server can't simply reply TCP, as it would get blocked.

I am not sure about the UDP size question, but I am pretty sure this
is a client behavior, i.e. the server does not send back a reply to
tell the client to use TCP port, but client should try UDP, fails, and
switch to using TCP.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Some hosts not resolving from No-IP by our DNS servers

[Josh Kuo]

If I am not mistaken, when you do +trace, the trace actually comes
from your machine running 'dig', and not the DNS resolver itself.
(Others on list please correct me)

Can you perform the same 'dig' query from the DNS server, without
specifying which resolver to use? This smells like the DNS server
itself is having trouble communicating to the outside.

I would start from there to make sure the DNS server itself can
resolve these names. Also make sure recursion is enabled.


On Wednesday, March 9, 2011, Frank Pikelner
 wrote:
>
>
>
>
>
>
>
>
>
>
> Hello,
>
> I'm having a problem resolving several hosts from NO-IP. When I attempt to 
> resolve them from our DNS servers I get no reply (we can resolve other 
> hosts). I'm not certain why the resolution stops. If I force a resolution 
> using external DNS servers using dig (i.e. Google 8.8.8.8) the hosts resolve 
> without problem. Here is the trace from our DNS server:
>
>
> dig oa.in-ip.info +trace
>
> ; <<>> DiG 9.6-ESV-R1 <<>> oa.in-ip.info +trace
> ;; global options: +cmd
> .   25973   IN  NS  j.root-servers.net.
> .   25973   IN  NS  e.root-servers.net.
> .   25973   IN  NS  m.root-servers.net.
> .   25973   IN  NS  k.root-servers.net.
> .   25973   IN  NS  b.root-servers.net.
> .   25973   IN  NS  d.root-servers.net.
> .   25973   IN  NS  f.root-servers.net.
> .   25973   IN  NS  g.root-servers.net.
> .   25973   IN  NS  h.root-servers.net.
> .   25973   IN  NS  c.root-servers.net.
> .   25973   IN  NS  i.root-servers.net.
> .   25973   IN  NS  a.root-servers.net.
> .   25973   IN  NS  l.root-servers.net.
> ;; Received 436 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms
>
> info.   172800  IN  NS  d0.info.afilias-nst.org.
> info.   172800  IN  NS  b2.info.afilias-nst.org.
> info.   172800  IN  NS  b0.info.afilias-nst.org.
> info.   172800  IN  NS  a0.info.afilias-nst.info.
> info.   172800  IN  NS  a2.info.afilias-nst.info.
> info.   172800  IN  NS  c0.info.afilias-nst.info.
> ;; Received 434 bytes from 192.58.128.30#53(j.root-servers.net) in 230 ms
>
> info.   900 IN  SOA a0.info.afilias-nst.info. 
> noc.afilias-nst.info. 2009263081 3600 1800 604800 3600
> ;; Received 91 bytes from 199.249.113.1#53(a2.info.afilias-nst.info) in 3 ms
>
> Would appreciate any pointers.
>
> Thank you,
>
> Frank
>
>
>
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Migrating DNS servers, need advice on hardware

[Josh Kuo]

Small home linksys router running open WRT can do the job, with 16MB
of RAM and some low powered MIPS CPU.

On Saturday, September 19, 2009, Frank Bulk  wrote:
> Perhaps the inverse would be more interesting: what's the lowest-spec
> hardware that could host an OS that would run the latest version of BIND. =)
>
> Frank
>
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry Margolin
> Sent: Saturday, September 19, 2009 12:09 AM
> To: comp-protocols-dns-b...@isc.org
> Subject: Re: Migrating DNS servers, need advice on hardware
>
> In article ,
>  Kaya Saman  wrote:
>
>> >
>> > Since you haven't mentioned how many zones and records you're hosting,
>> > how do you expect anyone to guess how much hardware you need?
>> >
>> >
>> Yes thank you for pointing that out! I do apologize as I mentioned I've
>> just finished my studies and am as of yet quite in-experienced yet with
>> certain things so please do not frown upon me for that! - I know many
>> people here are top notch pro's and I do not fall into that category but
>> someone who is eager to get there :-)
>>
>> Anyhow, I have 4 zone files for 1 domain currently and I'm using 2
>> views; internal and external. I hope to expand too once I have more
>> finances available to me and start mirroring Linux distros and perhaps
>> even OpenSolaris and BSD as well. But for now it's fairly simple stuff!
>>
>> I have noticed however that with the current setup my secondary DNS is
>> getting used quite a bit too as both systems are doing quite a few
>> translations - luckily I have a Cisco router in place so my WAN
>> connection is stable and does not crash like with a consumer based
>> router..
>
> In private email, he told me he has 59 forward and reverse records in
> the internal view, and 22 of each in the external view.
>
> This is nothing.  A 10-year-old Pentium should be able to handle this
> without breaking a sweat.
>
> --
> Barry Margolin, bar...@alum.mit.edu
> Arlington, MA
> *** PLEASE don't copy me on replies, I'll read them in the group ***
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS records visible only for LAN computers

[Josh Kuo]

Check out "views" or "split DNS".

On Sunday, November 15, 2009, Peter Macko  wrote:
>
>
>
>
>
> Setup:I have a domain example.com that is hosted on DNS under control of my 
> internet provider.Web server www.example.com is hosted by another company.I 
> have setup a local DNS for computers on my LAN. I have a LDAP server on LAN.
> Question:I want to make LDAP visible only for computers on LAN without 
> altering DNS (of the internet provider).The name of LDAP server should be 
> ldap.example.com. Is it possible to do it?
> I can think of two solutions:1) I could create master zone for example.com on 
> DNS (on LAN). This way I have to create A record for www.example.com,but if 
> internet provider changed ip address of the web-server, computers on lan 
> would not reachwww.example.com and I would have to update A record on local 
> DNS.
> 2) Another solution is to create zonefile for subdomain local.example.com on 
> LAN DNS, so ldap.local.example.com.But this is not exactly what I want.
> What is the correct solution?
> Thank you 
> Windows Live:  Friends get your Flickr, Yelp, and Digg updates when they 
> e-mail 
> you. 
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dig +trace to find all the forwarders?

[Josh Kuo]

Hi all,

I am trying to trace a recursive outbound query. My workstation is
configured to point to the forwarder/resolver 192.168.0.2, which is a
dedicated forwarder that is configured to forward all DNS queries to the
ISP's DNS resolver. Sometimes I get name resolution failures, and I want to
know if it is the ISP's DNS resolver is forwarding recursive queries to yet
another server... when using 'dig example.com +trace', it only shows the
recursive lookup starting at the root domain, instead of showing from my
192.168.0.2 -> ISP -> ? -> root name servers.

Is there any way to discover all the forwarders/resolvers along the way
before my query hits one of the root name servers? Or is that an impossible
feat unless I have administrative access to each of the resolvers/forwarders
to look at its configuration?

Thanks in advance.

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

Re: dig +trace to find all the forwarders?

[Josh Kuo]

>
> You need administrative access to see the overides to the normal resolution
> process.
>
>
Just so I understand this completely, by administrative access you mean I
need to be able to log in to each of the resolvers (not administrative
access on my local workstation to do a 'sudo dig example.net a +trace'),
correct?

A follow up question to that... is it even possible to perform such a trace
(revealing all resolvers) with the DNS protocol? Or is this purely a
designed limitation of dig?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dig +trace to find all the forwarders?

[Josh Kuo]

What is happening is I suspect the DNS resolved IP given by my ISP is
actually forwarding recursive queries to yet-another-server(s), and is
introducing slow name resolution and timeouts. In any case, I will
have to involve the ISP in troubleshooting and (hopefully) fixing the
problem. I was hoping there is some way to mimic "traceroute" with
"dig +trace", I didn't think so, and Mark confirmed it.

On Sunday, April 25, 2010, Warren Kumari  wrote:
>
> On Apr 25, 2010, at 12:01 AM, Josh Kuo wrote:
>
>
> You need administrative access to see the overides to the normal resolution
> process.
>
>
> Just so I understand this completely, by administrative access you mean I 
> need to be able to log in to each of the resolvers (not administrative access 
> on my local workstation to do a 'sudo dig example.net a +trace'), correct?
>
> A follow up question to that... is it even possible to perform such a trace 
> (revealing all resolvers) with the DNS protocol?
>
>
> 'tis not doable[0].
>
> What is the root problem that you are trying to solve here? Is this just to 
> know because you want to, or are you trying to solve a specific issue? In the 
> very large majority of cases[1] your machine is going to be querying whatever 
> is configured in your resolv.conf (or equivalent) and those nameservers will 
> go do the resolution for you (as opposed to multiple levels of forwarders).
>
>
> [0]: I have horrid visions of someone responding back with some truly 
> horrendous kludge that involves looking up random strings and querying 
> heaps-o-servers to see if any of them had cached the answer or something 
> equally icky. Actually, you cloud see if the server that you query is the one 
> that actually touches the auth server, but this is all ugly.
>
> [1]: No hard data here -- does anyone have any sort of guestimate on fraction 
> of forwarded queries?
>
> W
>
>
> Or is this purely a designed limitation of dig?
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Another Question about SERVFAIL

[Josh Kuo]

I tried these myself, and I am still scratching my head on the results.
First, I tried to look for just ftp.cisco.com's A record, and I got back the
answer 198.133.219.241.

$ dig @4.2.2.2 ftp.cisco.com. a

; <<>> DiG 9.4.3-P3 <<>> @4.2.2.2 ftp.cisco.com. a
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60411
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;ftp.cisco.com. IN  A

;; ANSWER SECTION:
ftp.cisco.com.  60  IN  A   198.133.219.241

;; AUTHORITY SECTION:
ftp.cisco.com.  85449   IN  NS  rtp5-ddir-ns.cisco.com.
ftp.cisco.com.  85449   IN  NS  sjce-ddir-ns.cisco.com.

;; ADDITIONAL SECTION:
sjce-ddir-ns.cisco.com. 85501   IN  A   128.107.240.86

;; Query time: 184 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Tue May 25 15:48:43 2010
;; MSG SIZE  rcvd: 117

... BUT, if I tried to look for any record, I get a very different answer:

$ dig @4.2.2.2 ftp.cisco.com. any

; <<>> DiG 9.4.3-P3 <<>> @4.2.2.2 ftp.cisco.com. any
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53036
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: Messages has 2 extra bytes at end

;; QUESTION SECTION:
;ftp.cisco.com. IN  ANY

;; ANSWER SECTION:
ftp.cisco.com.  50  IN  A   169.254.1.1

;; Query time: 640 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Tue May 25 15:45:58 2010
;; MSG SIZE  rcvd: 49


Any thoughts on why? I do notice the warning message that the message has 2
extra bytes at the end, perhaps it's a malformed response for the 'any' RR
query?


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

Re: [ASK] Block Malware Generate Random Subdomain, Domain and TLD

[Josh Kuo]

You might want to check out the free service offered by Quad Nine
(9.9.9.9), they use RPZ in the backend to filter out known malicious domain
names. I do not know if they can filter out malware-related names.

On Sat, Jan 20, 2018 at 7:02 AM Syaifudin  wrote:

> Hi Daniel
>
> thank you very much for your answer.  i want ask much more but my english
> not good so once again thank you very much.
>
>
>
> --
> Sent from: http://bind-users-forum.2342410.n4.nabble.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
>
___
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: DNS load balancing: UDP or TCP ?

[Josh Kuo]

Agree with Tony on TCP not going to be tried. Have you looked at using
anycast? It is not true load balancing but it allows you to stand up
multiple DNS servers that “shares” a single IP address.

On Wed, Feb 20, 2019 at 12:25 AM Tony Finch  wrote:

> Roberto Carna  wrote:
>
> > Dear, I have to balance two DNS servers for a special reason.
>
> https://www.powerdns.com/dnsdist.html
>
> > The DNS clients are a mix of Windows, Cisco and Linux machines, so I
> > think they ask for a FQDN using UDP and after that -if there is no
> > response-, they ask the same FQDN using TCP, and so the load balancing
> > will be succesful.
>
> No, fallback to TCP relies on receiving a truncated UDP response. You
> never want a DNS client to be waiting around for a response that will
> not arrive.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Rockall, Malin: Southeast veering southwest 6 to gale 8, occasionally 5
> later.
> Rough or very rough. Rain. Moderate or poor.
> ___
> 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
>
___
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

DS record RRSIG

[Josh Kuo]

This may not be the right place to ask, if this is a better question asked
in a different list, please let me know.

I am curious as to how BIND generates and processes DS RRSIG, and this may
not be unique to BIND, since I've seen this behavior across multiple
vendors. From the following:

$ dig example.com. DS +dnssec +nocrypto

; <<>> DiG 9.12.2-P2 <<>> example.com. DS +dnssec +nocrypto
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48102
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;example.com. IN DS

;; ANSWER SECTION:
example.com. 84558 IN DS 43547 8 2 [omitted]
example.com. 84558 IN DS 31406 8 1 [omitted]
example.com. 84558 IN DS 31406 8 2 [omitted]
example.com. 84558 IN DS 31589 8 1 [omitted]
example.com. 84558 IN DS 31589 8 2 [omitted]
example.com. 84558 IN DS 43547 8 1 [omitted]
example.com. 84558 IN RRSIG DS 8 2 86400 20190709042256 20190702031256 3800
com. [omitted]

;; Query time: 228 msec
;; SERVER: 10.0.22.1#53(10.0.22.1)
;; WHEN: Wed Jul 03 01:27:42 PST 2019
;; MSG SIZE  rcvd: 455

There are 6 DS records total, but only 1 RRSIG. This leads me to believe
that the single RRSIG is generated by somehow concatenating all DS records
together. This then leads me to believe that the validating resolver needs
to process _all_ DS records, not just the ones whose key tag matches the
child zone's KSK. Is this true? It seems like a small overhead in the grand
scheme of things, but that seems inefficient, if multiple DS records are
left at the parent zone after a couple of key rollovers.

Any information on this would be appreciated.

-Josh
___
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: DS record RRSIG

[Josh Kuo]

Thank you for the clarification.

On Wed, Jul 3, 2019 at 1:49 AM Ondřej Surý  wrote:

> Yes, the whole RRSet is always signed.  Signing individual records would
> not protect against attacks stripping individual records and their RRSIGs.
>
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
>
> > On 2 Jul 2019, at 19:34, Josh Kuo  wrote:
> >
> > This may not be the right place to ask, if this is a better question
> asked in a different list, please let me know.
> >
> > I am curious as to how BIND generates and processes DS RRSIG, and this
> may not be unique to BIND, since I've seen this behavior across multiple
> vendors. From the following:
> >
> > $ dig example.com. DS +dnssec +nocrypto
> >
> > ; <<>> DiG 9.12.2-P2 <<>> example.com. DS +dnssec +nocrypto
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48102
> > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags: do; udp: 4096
> > ;; QUESTION SECTION:
> > ;example.com. IN  DS
> >
> > ;; ANSWER SECTION:
> > example.com.  84558   IN  DS  43547 8 2 [omitted]
> > example.com.  84558   IN  DS  31406 8 1 [omitted]
> > example.com.  84558   IN  DS  31406 8 2 [omitted]
> > example.com.  84558   IN  DS  31589 8 1 [omitted]
> > example.com.  84558   IN  DS  31589 8 2 [omitted]
> > example.com.  84558   IN  DS  43547 8 1 [omitted]
> > example.com.  84558   IN  RRSIG   DS 8 2 86400 20190709042256
> 20190702031256 3800 com. [omitted]
> >
> > ;; Query time: 228 msec
> > ;; SERVER: 10.0.22.1#53(10.0.22.1)
> > ;; WHEN: Wed Jul 03 01:27:42 PST 2019
> > ;; MSG SIZE  rcvd: 455
> >
> > There are 6 DS records total, but only 1 RRSIG. This leads me to believe
> that the single RRSIG is generated by somehow concatenating all DS records
> together. This then leads me to believe that the validating resolver needs
> to process _all_ DS records, not just the ones whose key tag matches the
> child zone's KSK. Is this true? It seems like a small overhead in the grand
> scheme of things, but that seems inefficient, if multiple DS records are
> left at the parent zone after a couple of key rollovers.
> >
> > Any information on this would be appreciated.
> >
> > -Josh
> > ___
> > 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
>
>
___
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: DS record RRSIG

[Josh Kuo]

Tony,

Thank you for that detailed explanation.

On Wed, Jul 3, 2019 at 2:15 AM Tony Finch  wrote:

> Josh Kuo  wrote:
> >
> > There are 6 DS records total, but only 1 RRSIG. This leads me to believe
> > that the single RRSIG is generated by somehow concatenating all DS
> records
> > together.
>
> Correct.
>
> > This then leads me to believe that the validating resolver needs to
> > process _all_ DS records, not just the ones whose key tag matches the
> > child zone's KSK.
>
> Not quite.
>
> One way to validate a delegation is:
>
> * validate the DS RRset, which is signed using the parent's DNSKEY(s)
>   [ you can see the "com" signer field in the "example.com" RRSIG ]
>
> * get the key tags from the DS RRset (the first field in the records)
>   and the key tags from the child's DNSKEY RRSIG records (between lifetime
>   fields and the signer field) and calculate the key tags of the
>   child's DNSKEY records
>
> * take the intersection of these three sets; these key tags identify keys
>   that the parent says can validate the DNSKEY RRset, and that actually do
>   validate the DNSKEY RRset, and that can be used to validate the DNSKEY
>   RRset
>
> * for each DNSKEY in the set, ensure that there is a DS record that
>   whose digest matches it [ you can skip matching attempts when the key
>   tags do not match ]
>
> * using the public keys and signatures you just identified, try to
>   validate the self-signature on the DNSKEY RRset; if any of the
>   signatures validates, it's all good! [ again the key tags let you
>   skip pointless signature validation attempts ]
>
> There are some extra complications to do with downgrade protection, but
> that's the basic idea.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> women and men working together
>
___
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