Re: DiG "unexpected source" with a Subnet-Router anycast address

[François-Xavier Le Bail]

--- On Mon, 9/12/11, Kevin Darcy  wrote:

> You should either a) pursue with your network hardware
> vendor why its device is responding to a query to the SRAA
> with a different source address, thus breaking the rules of
> DNS resolution, or b) select a working resolver address in
> the Global Unicast range and be happy.

Yes, I will "dig" the a) case before other solutions.

> >> On 9/7/2011 10:48 AM, François-Xavier Le Bail
> wrote:
> >>> Hello,
> >>> 
> >>> I send with DiG 9.7.3 a request to a
> router/DNS
> >> forwarder with the Subnet-Router anycast address
> of the
> >> router (SRAA, RFC 2373, § 2.6.1).
> >>> The answer is :
> >>> reply from unexpected source: >> router>#53, expected#53
> >>> Is there an option to relax the IPv6 address
> >> request/reply control for this use case ?
> >>> Best regards,
> >>> François-Xavier Le Bail


___
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: updating Bind made it slower

[Tom Schmitt]

> > I just updated a couple of my DNS-servers from the rather old version
> > 9.4.1 to a newer version 9.8.0-P4.
> >
> > After this I have problem with outages. Looking into it, I found that
> > the time for a "rndc reload" has nearly doubled!
> 
> This has been pointed out to me before; do you really need "reload", or 
> would "reconfig" suffice?
> 

I will try it if this is reducing the times and if a reload is realy not 
needed. If it works, I will change my updating-scripts.
Thank you!
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
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: updating Bind made it slower

[Peter Andreev]

2011/9/27 Tom Schmitt :
>
>> > I just updated a couple of my DNS-servers from the rather old version
>> > 9.4.1 to a newer version 9.8.0-P4.
>> >
>> > After this I have problem with outages. Looking into it, I found that
>> > the time for a "rndc reload" has nearly doubled!
>>
>> This has been pointed out to me before; do you really need "reload", or
>> would "reconfig" suffice?
>>
>
> I will try it if this is reducing the times and if a reload is realy not 
> needed. If it works, I will change my updating-scripts.
> Thank you!

It is not clear in your question, are you use "rndc reload" or "rndc
reload zone.name"? Latter will be faster in case if you change one or
few zones in one pass of your updating-script.

> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> ___
> 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
>

-- 
--
AP
___
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: updating Bind made it slower

[Tom Schmitt]

> It is not clear in your question, are you use "rndc reload" or "rndc
> reload zone.name"? Latter will be faster in case if you change one or
> few zones in one pass of your updating-script.

I generate from my database the complete named.conf, especially including new 
zones and then trigger a "rndc reload" to make this new config activ.

This process is now taking much more time, leading to outages in the 
DNS-service :-(

I'll try to replace it with rndc reconfig. Not sure if this really is 
sufficient.

Tom.
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
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

servfail are not cached!

[Issam Harrathi]

I discover that servfail are not cached. is it normal?
explanation:
I have a cache-recursing server and i try www.blabla.com (which exist) and
then i stop the dns server of www.blabla.com. Then (after ttl expired) from
my cache-recusing server i try dig @0 www.blabla.com and i receive a
servfail, all this is OK. But this result is not cached means each time i do
my dig my server will try to contact the dns server of blabla.com.

Thanks;
Issam Harrathi.
___
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: updating Bind made it slower

[Peter Andreev]

2011/9/27 Tom Schmitt :
>
>
>> It is not clear in your question, are you use "rndc reload" or "rndc
>> reload zone.name"? Latter will be faster in case if you change one or
>> few zones in one pass of your updating-script.
>
> I generate from my database the complete named.conf, especially including new 
> zones and then trigger a "rndc reload" to make this new config activ.

In this case "rndc reconfig" should be sufficient. This command tells
BIND to re-read config file and load all new zones without touching
any previously loaded zones.
>
> This process is now taking much more time, leading to outages in the 
> DNS-service :-(
>
> I'll try to replace it with rndc reconfig. Not sure if this really is 
> sufficient.
>
> Tom.
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> ___
> 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
>



-- 
--
AP
___
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

allow-transfer not covering ixfr requests?

[Torsten Segner]

I recently observered a rather strange phaenomenon.
By accident I have configured a nameserver to allow queries from NS1 and NS2 
and allow transfers from NS3 und NS4.
So far so good... 
Naturally NS1 and NS2 could do all kinds of queries but no zone transfers.

NS3 and NS4 weren't allowed to ask anything but were able to request axfr 
transfers.

The odd part is that both NS3 and NS4 weren't able to request ixfr transfers. 
Shouldn't allow-transfer cover these kind of transfer requests as well?


Ciao
Torsten


PS: All nameservers are running on a self-compiled 9.8.1
___
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: servfail are not cached!

[Evan Hunt]

> I discover that servfail are not cached. is it normal?

Yes, that's normal.

Temporary negative caching of SERVFAIL responses for a limited period (up
to 30 seconds, if I recall correctly) is permitted by the DNS protocol,
and we've discussed implementing it in BIND9, but haven't had time yet.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: servfail are not cached!

[Issam Harrathi]

As i test it's not cached at all, and you say here it's cached for 30
seconds?!
i'm using 9.7.2-P3.

2011/9/27 Evan Hunt 

> > I discover that servfail are not cached. is it normal?
>
> Yes, that's normal.
>
> Temporary negative caching of SERVFAIL responses for a limited period (up
> to 30 seconds, if I recall correctly) is permitted by the DNS protocol,
> and we've discussed implementing it in BIND9, but haven't had time yet.
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
>
___
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: servfail are not cached!

[Ben Croswell]

Actually he said the DNS protocol allows for it and ISC had been considering
adding it.

-Ben Croswell
On Sep 27, 2011 11:38 AM, "Issam Harrathi"  wrote:
> As i test it's not cached at all, and you say here it's cached for 30
> seconds?!
> i'm using 9.7.2-P3.
>
> 2011/9/27 Evan Hunt 
>
>> > I discover that servfail are not cached. is it normal?
>>
>> Yes, that's normal.
>>
>> Temporary negative caching of SERVFAIL responses for a limited period (up
>> to 30 seconds, if I recall correctly) is permitted by the DNS protocol,
>> and we've discussed implementing it in BIND9, but haven't had time yet.
>>
>> --
>> Evan Hunt -- e...@isc.org
>> Internet Systems Consortium, Inc.
>>
___
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: servfail are not cached!

[Jan-Piet Mens]

On Tue Sep 27 2011 at 17:32:22 CEST, Issam Harrathi wrote:

> and you say here it's cached for 30 seconds?!

Evan said:

> and we've discussed implementing it in BIND9, but haven't had time yet.

In other words, they are *not* cached in BIND9.

-JP
___
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: updating Bind made it slower

[Tom Schmitt]

> In this case "rndc reconfig" should be sufficient. This command tells
> BIND to re-read config file and load all new zones without touching
> any previously loaded zones.

This was my understanding (after reading the text from rndc) as well.
But to my surprise:

I tested "rndc reload" against "rndc reconfig" on five differrent servers, 
Solaris and Linux, 9.8.0 and 9.4.1. On all servers the same result:
Both commands take roughly the same amount of time! Sometime rndc reconfig even 
took a bit longer.

I have not the slightest clue why, I had suspected that rndc reconfig would be 
much faster, especially is there is no altering in the config at all.

But the results are clear: rndc reconfig is no solution for me.
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!   
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
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: allow-transfer not covering ixfr requests?

[Tom Schmitt]

> 
> The odd part is that both NS3 and NS4 weren't able to request ixfr
> transfers. 
> Shouldn't allow-transfer cover these kind of transfer requests as well?
> 


First: Do you have statements "provide ixfr;" and "request ixfr;" in your 
config?

Second: To do a ixfr a server is first sending a query for the SOA of the zone 
to determine if a update is necessary. If your servers aren't allowed to do a 
query, how should they get the SOA? And without a SOA, you don't have the 
serial number of the zone, so you can't do IXFR.

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
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: updating Bind made it slower

[Warren Kumari]

On Sep 27, 2011, at 3:52 PM, Tom Schmitt wrote:

> 
>> In this case "rndc reconfig" should be sufficient. This command tells
>> BIND to re-read config file and load all new zones without touching
>> any previously loaded zones.
> 
> This was my understanding (after reading the text from rndc) as well.
> But to my surprise:
> 
> I tested "rndc reload" against "rndc reconfig" on five differrent servers, 
> Solaris and Linux, 9.8.0 and 9.4.1. On all servers the same result:
> Both commands take roughly the same amount of time! Sometime rndc reconfig 
> even took a bit longer.
> 
> I have not the slightest clue why, I had suspected that rndc reconfig would 
> be much faster, especially is there is no altering in the config at all.


How are you testing this? 

'time rndc reconfing'? Or do you stop answering queries and time that? How long 
do things take? How big is your config? 

W

> 
> But the results are clear: rndc reconfig is no solution for me.
> -- 
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! 
> Jetzt informieren: http://www.gmx.net/de/go/freephone
> ___
> 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: updating Bind made it slower

[michoski]

On 9/27/11 1:15 PM, "Warren Kumari"  wrote:
> On Sep 27, 2011, at 3:52 PM, Tom Schmitt wrote:
>> I tested "rndc reload" against "rndc reconfig" on five differrent servers,
>> Solaris and Linux, 9.8.0 and 9.4.1. On all servers the same result:
>> Both commands take roughly the same amount of time! Sometime rndc reconfig
>> even took a bit longer.
>> 
>> I have not the slightest clue why, I had suspected that rndc reconfig would
>> be much faster, especially is there is no altering in the config at all.
> 
> How are you testing this?
> 
> 'time rndc reconfing'? Or do you stop answering queries and time that? How
> long do things take? How big is your config?

Why not try the latest version, really?  Pick a test host.  Install 9.8.1+.
Time it again.  Then let's talk.

When there are blog posts from ISC which essentially address this issue, it
would be good to at least try the suggested solution before complaining too
loudly.

-- 
By nature, men are nearly alike;
by practice, they get to be wide apart.
-- Confucius

___
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

dnssec question. confused.

[Brad Bendily]

When trying the DNSSEC check command from:
https://www.dns-oarc.net/oarc/services/replysizetest

behind our corporate firewall, I get:
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"Tested at 2011-09-27 20:32:34 UTC"
"205.172.49.177 sent EDNS buffer size 4096"
"205.172.49.177 DNS reply size limit is at least 490"


Which, based on the website tells me our firewall is blocking 
or filtering EDNS/DNSSEC packets.



However, what I'm confused about is when I run this command:
dig +dnssec eeoc.gov

I get:

; <<>> DiG 9.7.3-P1 <<>> +dnssec eeoc.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40572
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;eeoc.gov.  IN  A

;; ANSWER SECTION:
eeoc.gov.   19499   IN  A   64.94.64.52
eeoc.gov.   19499   IN  RRSIG   A 7 2 21600 20111208014816 
20110909014816 52909 eeoc.gov. 
AW5Ny32xDP7+m4XxCSS7q/zuK8RBc+la70Zmg0A/Pe1+p0agkrzbxaHM 
GgvKldSKCzVgo7XPGR3LqcGIFDl0CPaaSTxTntlZkdh6x2qS4mM/49+B 
9podxzbV3V4LcNpR4c4jyteAa5Uxaz3WSRr1T69PpJyIZZ53JmexkMPi 
yOjMcp1IqeSJ0P/06CuZccemo+f/fjGW8xfG/slOp2XJlmbPo1EfJnlw 
i07YstZVszHxsgmRUXssEUmkWi3eqAw4Ug2QiRa+zz3JpmgBnC0G7Kxd 
SXUJLuvfNdDrtJ9T5anNVRVxCVq499gaJQnWBXKKVVaC9w/BcPnGuSRy OZTyPg==

;; AUTHORITY SECTION:
eeoc.gov.   66519   IN  NS  dnssec10.datamtn.com.
eeoc.gov.   66519   IN  NS  dnssec14.datamtn.com.
eeoc.gov.   66519   IN  NS  dnssec11.datamtn.com.
eeoc.gov.   66519   IN  NS  dnssec12.datamtn.com.
eeoc.gov.   66519   IN  NS  dnssec9.datamtn.com.

;; ADDITIONAL SECTION:
dnssec9.datamtn.com.3114IN  2001:49f0:a02a:1000::238
dnssec11.datamtn.com.   3114IN  2001:470:1:7a::147
dnssec9.datamtn.com.3114IN  RRSIG    7 3 10800 2025185428 
20110827185428 21352 datamtn.com. 
Ngz7Bl2VWqhIY5Uh8bHJjwyAWQXcEM7qaAH8JSJ5VM5qMelfVA1pV+Y6 
RltfXpACQxRpHsayiArGZulzp1XX4yW6+qsHiKLJOcRiS5kmjexBPUlK 
zyU3cp7BC5dprHyPBpXKbHExuGlvqrg1aqRJtAmH6Q7tkp2wWqEuO3Ku 
LBvvGXN46U+sYPsd98YixlLLTtj2qFo7/vhPN8ao2g6HuFBVIUTU4LuV 
d7Wjz+r4Xj722w6RFgZFu9qFwYsOQwTGlon4zqDvflzESSWSjFdzHCZ0 
prkagjXwcZYMlQGRMgnmHlEEvvg+lKMdl4imHLx/LKLD+feCzp2d4PFj 9byoYA==
dnssec9.datamtn.com.3114IN  RRSIG    8 3 10800 2025185428 
20110827185428 61898 datamtn.com. 
NtPfKvEs6DF0Bac9ZbCfi0b0QdeVMSlaNXAyDFSjo4J8uQUYllDwt101 
C78VAiXplumZRM/9Vv7fg1/Ds/qCd6wC6wdTR3S8mtDOpLHVhuZTSGI1 
jBVBXYjzBdqIBitydwD6vs+VaPsfd352NBqE8teFQJhbVAI98+d9BO4x 
/Qx+i2HJOPdQyVRq6dj2NYg1GT4ODDb6VmQUOb01XgIyX/pLt+7AdtId 
1FFbA9LfO4xvYTCKAO3LbPvdU7nJ2+mCMu5CNQFNiwAbSHT3letupzpH 
yLUNrjhcO0cj/vVf1YrrIzZXF69zKGYfsCP876zKoVtlrUe1dZ0bersP 4I9klg==
dnssec11.datamtn.com.   3114IN  RRSIG    7 3 10800 2025185428 
20110827185428 21352 datamtn.com. 
Lgt6Wq5JvvAF6BKUUoPSiv6lx0yqQ3HAFoClEcg11V7XhIngeaTperu7 
7lytmKl53yZUxarFbQdJ/NxwwNVl/F2Os5RkNHkAjVTkku1mjoMeqEhF 
NDe+cvYOOo0EASc9LhmHo2qgkyhjGAt1FtbmrOG9Gwr5OdUM5l2EgcGj 
bRvH1Sfv5le68ST1+74sQPKmp+3n0gopfKUlcYuDDw/mUKXR8lo3MCTv 
xe6q6NbwHNHWBCgUw4rqX4ZdVArL4WumKvkufeieDJpMhKwHlWHyPvu9 
pX1IsZRyQPo9RqnmSpG+yjR59ixbb23LyO6alrEDJTyaJZL8uHfwiTQ8 4V29tQ==
dnssec11.datamtn.com.   3114IN  RRSIG    8 3 10800 2025185428 
20110827185428 61898 datamtn.com. 
vtFFEZbruIfnwSGAdlXukUn40SOEIZY9QXrHh6CfOl3WkQduSnbvgS5T 
+e2QN6GDcZgigGON8yHHTS8DI8ld/tCxxVkwB3ISkqkQHrjyyRD6+8IR 
J2BWsdMTyAhe9PygLR1FkfCt1JDaDnAbOKOniMT+6DRlnE7ZW7KfvZT/ 
7j5qG+xDixCXUHyhnstbv9vmMPTxnK1ASy6nz7ErnA/DUMleO484xIgM 
6Pc8uqy3Onw4Yfn4l5R66tQwC0yoSVwqmEyIWNWyx1SNQLFzUc1hySaF 
aQs1L/Zyu9e/wSHdZUeGiOwx5cz3yWE2NsF3tagxukkL9vNu2s/nyjzR 3igT3g==

;; Query time: 1 msec
;; SERVER: 10.120.11.107#53(10.120.11.107)
;; WHEN: Tue Sep 27 15:34:07 2011
;; MSG SIZE  rcvd: 1726


Which tells me my DNSSEC queries are working, right?
I noticed in the "OPT PSEUDOSECTION" udp=4096.

This started because, as the DNS admin, I was informed today that we could not 
resolve
this domain, eeoc.gov. Which was true. As I started digging into it, and 
performing a
dig from an offsite server which was working, I found that the domain 
"eeoc.gov" is 
running DNSSEC. So, I assumed the problem was with our firewall blocking or 
filtering
the DNSSEC traffic. But then after researching for a few hours, I found we were 
able
to resolve the domain, through no changes of DNS. 
It could be that "datamtn.com", their authoritative NS are performing
maintenance or something. So, all this research led me to the information above.

Are we getting EDNS/DNSSEC responses or no?
thanks
bb
___
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

Re: dnssec question. confused.

[Doug Barton]

On 09/27/2011 13:45, Brad Bendily wrote:
> dig +dnssec eeoc.gov

Try that again with +notcp.

FYI, on a "clean" network the response I get to that query is 3,918 bytes.


hth,

Doug

-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.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

RE: Compelling Reason for Deploying DNSSEC

[Brad Bendily]

Maybe some of the links mentioned here will help you...

https://www.dnssec-deployment.org/index.php/deployment-case-studies/dnssec-why-threats/

 bb

> -Original Message-
> From: bind-users-bounces+brad.bendily=la@lists.isc.org 
> [mailto:bind-users-bounces+brad.bendily=la@lists.isc.org] 
> On Behalf Of Paul Romano
> Sent: Tuesday, September 13, 2011 9:14 PM
> To: bind-users@lists.isc.org
> Subject: Compelling Reason for Deploying DNSSEC
> 
> This message has been archived. View the original item 
>  aultId=1A7E9674FC71C7441BE84C3D2569B6D0E111evsite01&Savese
> tId=201109246825425~20110914021954~Z~00C9484BE585306D182F5
> B10903EFF51> 
> 
> I am trying to justify deploying DNSSEC to my management.  We 
> have many domains and I want to use this project as an 
> opportunity to review and classify our many domains (legacy, 
> defensive, current production, etc.).  Since money is very 
> tight we need
> Attachments:
> ATT1.txt  (0 KB)  
> 
___
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: "if exists host-name" for IPv6 DDNS?

[WBrown]

Matthew wrote on 09/23/2011 03:21:06 AM:

> On 23/09/2011 00:39, Joachim Tingvold wrote:
> > Or replace :: with _, 
> 
> '_' is an illegal character in hostnames in the DNS...

Yeah, I got hosed by that one by a consultant. 

How about replace all : with a -.  :: becomes --.   No rule against that, 
is there?  And much simpler.



Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.
___
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: dnssec question. confused.

[Mark Andrews]

In message <798e3caf2fcc264481d8f75fb3d0bfd91b538...@mailmbx10.mail.la.gov>, Br
ad Bendily writes:
> 
> When trying the DNSSEC check command from:
> https://www.dns-oarc.net/oarc/services/replysizetest
> 
> behind our corporate firewall, I get:
> rst.x476.rs.dns-oarc.net.
> rst.x485.x476.rs.dns-oarc.net.
> rst.x490.x485.x476.rs.dns-oarc.net.
> "Tested at 2011-09-27 20:32:34 UTC"
> "205.172.49.177 sent EDNS buffer size 4096"
> "205.172.49.177 DNS reply size limit is at least 490"
> 
> 
> Which, based on the website tells me our firewall is blocking 
> or filtering EDNS/DNSSEC packets.
>
> However, what I'm confused about is when I run this command:
> dig +dnssec eeoc.gov
> 
> I get:
> 
> ; <<>> DiG 9.7.3-P1 <<>> +dnssec eeoc.gov
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40572
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 7
> 
[snipped]
> 
> ;; Query time: 1 msec
> ;; SERVER: 10.120.11.107#53(10.120.11.107)
> ;; WHEN: Tue Sep 27 15:34:07 2011
> ;; MSG SIZE  rcvd: 1726
> 
> 
> Which tells me my DNSSEC queries are working, right?

Not optimally.  Named will work around some firewall breakage by
retrying the queries the time oute with smaller EDNS UDP buffer
size of 512 bytes which allow the response to get through the
firewall.  Often those responses will have TC=1 set so named will
then ask the query again but this time over TCP.  So instead of a
single UDP query and response you end up with multiple UDP queries
and a TCP connection.

You should have your firewall configured to pass EDNS UDP packets
up to 4096 bytes of UDP payload.  The two queries below generate
such a response from the authoritative nameservers and can't be
resolved from behind a firewall that blocks such responses (TCP
fallback will fail).

dig edns-v4-ok.isc.org txt
dig edns-v6-ok.isc.org txt

> I noticed in the "OPT PSEUDOSECTION" udp=4096.

Because you were talking to the local recursive nameserver which is also
behind the firewall.

> This started because, as the DNS admin, I was informed today that we could no
> t resolve
> this domain, eeoc.gov. Which was true. As I started digging into it, and perf
> orming a
> dig from an offsite server which was working, I found that the domain "eeoc.g
> ov" is 
> running DNSSEC. So, I assumed the problem was with our firewall blocking or f
> iltering
> the DNSSEC traffic. But then after researching for a few hours, I found we we
> re able
> to resolve the domain, through no changes of DNS. 
> It could be that "datamtn.com", their authoritative NS are performing
> maintenance or something. So, all this research led me to the information abo
> ve.

There could have been many causes.
 
> Are we getting EDNS/DNSSEC responses or no?

Yes but not optimally.

> thanks
> bb
> ___
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: dnssec question. confused.

[Marc Lampo]

Hello,

1) the dig command, as shown, does not ask an authoritative name server
for eeoc.gov.
   but rather addresses a locally configured caching name server
(10.120.11.107).
   (which may explain the difference in size - 1726 bytes -
as opposed to the 3918 bytes of Doug Barton)
   ((some data may already have timed out of the local cache, observe the
TTL values))

2) I'd say : yes, you receive DNSSEC responses.
   But your caching name server is not validating them : the AD bit is not
set in the answer.

3) The OPT RR, with length 4096, is in the *reply*.
   The server indicates that itself is willing to accept DNS over UDP
packets
up till that size (eg. for dynamic updates).
   (while EDNS0 RFC does not explicitly state replying with EDNS0 is
mandatory,
if a query came in with EDNS0,
there is also a statement that claims this (sending EDNS0 and looking
in the reply)
is a way, for a (dynamic update) client, to find out what the server
is willing to
accept.  This statement seems to imply that EDNS0 in a reply, should
be there if
the client sent EDNS0.
Any other opinions in the list ?)
   In order to see the packet size in the outgoing query packet,
use something like wireshark.

4) "DNSSEC query" is not precise enough !
   For one thing, DNSSEC requires EDNS0, EDNSO announces a buffersize,
which can vary.
   As long as (!) the buffersize is sufficient, UDP will be used,
but DNS queries can also be sent over TCP (and is your firewall
allowing that ?).

   My suggestion (from a device that is allowed to send DNS queries to the
Internet), try :

dig @dnssec9.datamtn.com. eeoc.gov. +dnssec
dig @dnssec9.datamtn.com. eeoc.gov. +dnssec +bufsize=512
and
dig @dnssec9.datamtn.com. eeoc.gov. +dnssec +vc

 (and don't forget to have your caching NS validate DNSSEC answers,
  because providing signatures that are ignored by clients
  makes the Internet *less* safe)

Kind regards,

Marc Lampo
Security Officer
EURid



-Original Message-
From: Brad Bendily [mailto:brad.bend...@la.gov] 
Sent: 27 September 2011 10:45 PM
To: bind-users@lists.isc.org
Subject: dnssec question. confused.


When trying the DNSSEC check command from:
https://www.dns-oarc.net/oarc/services/replysizetest

behind our corporate firewall, I get:
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"Tested at 2011-09-27 20:32:34 UTC"
"205.172.49.177 sent EDNS buffer size 4096"
"205.172.49.177 DNS reply size limit is at least 490"


Which, based on the website tells me our firewall is blocking 
or filtering EDNS/DNSSEC packets.



However, what I'm confused about is when I run this command:
dig +dnssec eeoc.gov

I get:

; <<>> DiG 9.7.3-P1 <<>> +dnssec eeoc.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40572
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;eeoc.gov.  IN  A

;; ANSWER SECTION:
eeoc.gov.   19499   IN  A   64.94.64.52
eeoc.gov.   19499   IN  RRSIG   A 7 2 21600 20111208014816
20110909014816 52909 eeoc.gov.
AW5Ny32xDP7+m4XxCSS7q/zuK8RBc+la70Zmg0A/Pe1+p0agkrzbxaHM
GgvKldSKCzVgo7XPGR3LqcGIFDl0CPaaSTxTntlZkdh6x2qS4mM/49+B
9podxzbV3V4LcNpR4c4jyteAa5Uxaz3WSRr1T69PpJyIZZ53JmexkMPi
yOjMcp1IqeSJ0P/06CuZccemo+f/fjGW8xfG/slOp2XJlmbPo1EfJnlw
i07YstZVszHxsgmRUXssEUmkWi3eqAw4Ug2QiRa+zz3JpmgBnC0G7Kxd
SXUJLuvfNdDrtJ9T5anNVRVxCVq499gaJQnWBXKKVVaC9w/BcPnGuSRy OZTyPg==

;; AUTHORITY SECTION:
eeoc.gov.   66519   IN  NS  dnssec10.datamtn.com.
eeoc.gov.   66519   IN  NS  dnssec14.datamtn.com.
eeoc.gov.   66519   IN  NS  dnssec11.datamtn.com.
eeoc.gov.   66519   IN  NS  dnssec12.datamtn.com.
eeoc.gov.   66519   IN  NS  dnssec9.datamtn.com.

;; ADDITIONAL SECTION:
dnssec9.datamtn.com.3114IN  2001:49f0:a02a:1000::238
dnssec11.datamtn.com.   3114IN  2001:470:1:7a::147
dnssec9.datamtn.com.3114IN  RRSIG    7 3 10800
2025185428 20110827185428 21352 datamtn.com.
Ngz7Bl2VWqhIY5Uh8bHJjwyAWQXcEM7qaAH8JSJ5VM5qMelfVA1pV+Y6
RltfXpACQxRpHsayiArGZulzp1XX4yW6+qsHiKLJOcRiS5kmjexBPUlK
zyU3cp7BC5dprHyPBpXKbHExuGlvqrg1aqRJtAmH6Q7tkp2wWqEuO3Ku
LBvvGXN46U+sYPsd98YixlLLTtj2qFo7/vhPN8ao2g6HuFBVIUTU4LuV
d7Wjz+r4Xj722w6RFgZFu9qFwYsOQwTGlon4zqDvflzESSWSjFdzHCZ0
prkagjXwcZYMlQGRMgnmHlEEvvg+lKMdl4imHLx/LKLD+feCzp2d4PFj 9byoYA==
dnssec9.datamtn.com.3114IN  RRSIG    8 3 10800
2025185428 20110827185428 61898 datamtn.com.
NtPfKvEs6DF0Bac9ZbCfi0b0QdeVMSlaNXAyDFSjo4J8uQUYllDwt101
C78VAiXplumZRM/9Vv7fg1/Ds/qCd6wC6wdTR3S8mtDOpLHVhuZTSGI1
jBVBXYjzBdqIBitydwD6vs+VaPsfd352NBqE8teFQJhbVAI98+d9BO4x
/Qx+i2HJOPdQyVRq6dj2NYg1GT4ODDb6VmQUOb01XgIyX/pLt+7AdtId
1FFbA9LfO4xvYTCKAO3LbPvdU7nJ2+mCMu5CNQFNiwAbSHT3letupzpH
yLUNrjhcO0cj/vVf1YrrIz

Re: "if exists host-name" for IPv6 DDNS?

[Jan-Piet Mens]

> > '_' is an illegal character in hostnames in the DNS...
> 
> Yeah, I got hosed by that one by a consultant. 

MCSE per chance? [Sorry; couldn't resist.]

-JP
___
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