RE: about the A and PTR for sending mail

[Murray S. Kucherawy]

> -Original Message-
> From: bind-users-bounces+msk=cloudmark@lists.isc.org 
> [mailto:bind-users-bounces+msk=cloudmark@lists.isc.org] On Behalf Of Mark 
> Andrews
> Sent: Wednesday, November 09, 2011 7:06 PM
> To: 风河
> Cc: bind-us...@isc.org
> Subject: Re: about the A and PTR for sending mail
> 
> While there is no RFC requirement that they match is there any reason
> not to make them match (the above records don't match) given that is
> the intent of the IN-ADDR.ARPA namespace?

Ideally I would agree, but there are some passable operational reasons for this 
to happen, and there are also some good operational ones as we enter IPv6-land.

Instead, I agree with another poster who suggested a mismatch or absence of 
this data in the DNS is good input to a scoring system, but not good grounds 
for outright rejection.

-MSK
___
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: Reason for Limited number of Root DNS Servers

[Mark Andrews]

In message <002b01cca054$9be42920$d3ac7b60$@nic.in>, Gaurav Kansal writes:
> Thanks a lot Mark.
> But  I don't understand the calculation part.
> Is there any source available from which I can get detail information
> regarding the same??

The DNS protocol is defined in RFC 1034 and RFC 1035.  This all comes
from a basic analysis of how the data is packed into a DNS packet.
 
> Thanks and Regards,
> Gaurav Kansal
> 9910118448
> 
> 
> 
> -Original Message-
> From: Mark Andrews [mailto:ma...@isc.org] 
> Sent: Friday, 11 November, 2011 12:14 PM
> To: Gaurav Kansal
> Cc: bind-us...@isc.org
> Subject: Re: Reason for Limited number of Root DNS Servers
> 
> 
> In message <004c01cca034$259d4870$70d7d950$@nic.in>, Gaurav Kansal writes:
> > 
> > Dear All,
> > 
> >  
> > 
> > Somewhere I read that number of ROOT DNS servers is limited to 13 
> > because of protocol limitation of DNS and UDP.
> > 
> > Exact writing was  "A combination of limits in the DNS and certain 
> > protocols, namely the practical size of unfragmented User Datagram 
> > Protocol
> > (UDP) packets, resulted in a limited number of root server addresses 
> > that can be accommodated in DNS name query responses. This limit has 
> > determined the number of name server installations at (currently) 13 
> > clusters, serving the needs of the entire public Internet worldwide."
> > 
> > As root DNS are running in anycast so number is not an issue at all. 
> > But I don't understand where exactly is this limitation exists???
> > 
> > Please some elaborate on this.
> > 
> > Thanks and Regards,
> > 
> > Gaurav Kansal
> > 
> > 9910118448
> 
>   Actually despite the words above it has *nothing* to do
>   with unfragmented UDP and everything to with being able to
>   reassemble fragmented UDP.
> 
>   All IPv4 hosts MUST accept fragmented packets up to 576
>   octets (RFC 791).  DNS's 512 octet UDP limit was choosen to
>   ensure that the UDP datagram can always be reassembled and
>   for there to be room for some IP options in addition to the
>   IP and UDP headers.
> 
>   Originally there wasn't commonality in the root server's
>   names.  Then it was said if we make the maximum use of
>   compression how root servers can we fit into a DNS/UDP
>   message?
> 
>   The first NS record takes 31 octets (1 + 2 + 2 + 4 + 2 + 20).
> 
>   Additional a NS records for . takes 15 octets (1 octets for
>   the name, 2 octets for the class, 2 octets for the type, 4
>   octets for the ttl, 2 octet for length and 4 of actual data).
> 
>   A "A" record with a compressed ownername takes 16 octets
>   (2 octets for the name, 2 octets for the class, 2 octets for the
>   type, 4 octets for the ttl, 2 octet for length and 4 of actual
> data).
> 
>   Then there is the 12 octet header and the 5 octet question.
> 
>   Doing the math on priming queries you get the following:
> 
>   13 names uses 436 octets
>   14 names uses 467 octets
>   15 names uses 498 octets
> 
>   If you have a referral to the root with a maximum sized qname
>   it takes 482 octets (12 + 255 + 4 + 31 + 15 * 12).
>   
>   Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> 
-- 
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: DNS Bulk Query Tool

[Marco Bicca]

Hi Gaurav,

Not sure, I used dnsperf just fine on a centos box.

Thanks,
Marco

-Original Message-
From: Gaurav Kansal [mailto:gaurav.kan...@nic.in] 
Sent: Friday, November 11, 2011 1:33 AM
To: Marco Bicca; bind-users@lists.isc.org
Subject: RE: DNS Bulk Query Tool

Hi Marco,
Thanks.
Dnsperf tool is not working in my machine. I don't understand why??

Is there any other tool available? 

Thanks and Regards,
Gaurav Kansal
9910118448





-Original Message-
From: Marco Bicca [mailto:marco_bi...@symantec.com]
Sent: Thursday, 03 November, 2011 12:03 AM
To: Gaurav Kansal; bind-users@lists.isc.org
Subject: RE: DNS Bulk Query Tool

Hi Gaurav,

I would use dnsperf and the 1 million website list from Alexa:

DNSPerf:
Freebsd: http://www.freshports.org/dns/dnsperf

Depending on your OS there are available ports too.

Alexa's list:
http://s3.amazonaws.com/alexa-static/top-1m.csv.zip


Did that in the past and it worked pretty well.

Thanks,
___
Marco Bicca

-Original Message-
From: bind-users-bounces+marco_bicca=symantec@lists.isc.org
[mailto:bind-users-bounces+marco_bicca=symantec@lists.isc.org] On Behalf
Of Gaurav Kansal
Sent: Wednesday, November 02, 2011 10:49 AM
To: bind-users@lists.isc.org
Subject: DNS Bulk Query Tool

Dear All,

 

I set up a new DNS Server using Bind 9.7

For meantime I open this server for the whole world. I wanna check how many
queries it can handle.

Is this any freeware available for checking this. Is there any tool
available by which I can come to know after how much load my DNS will be
down (Or it will stop responding) ???

 

Thanks and Regards,

Gaurav Kansal

8860785630

9910118448

 


___
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



smime.p7s
Description: S/MIME cryptographic signature
___
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: OT: Bind 9.9.0B1 Inline-Signing Question

[Evan Hunt]

> I have just one question, what should inline-zone admin do? I assume
> that named automatically regenerates & removes expired RRSIGs so is it
> sufficient to put new KSK and ZSK to the key-directory when needed and
> revoke older ones? Thanks for your answer in advance.

Yes, it will keep RRSIGs refreshed (same as it does now with dynamic
zones).  Rolling keys is the same process as now; you generate a successor
key (dnssec-keygen -S) and run "rndc loadkeys " to signal the server
that there's a new key.

I should mention that there is a known operational issue in the current
version of inline-signing that you should be cautious about.  If you're
using inline-signing with a master zone, and you make changes to the zone
file, you should *not* kill and restart your server to load the new file.
Instead, use "rndc reload" or "kill -HUP " to force named to reload
the zone while it's running.  That way, named will be able to compare the
former version against the new one, and generate the proper set of diffs to
apply to the signed zone.

If you kill and restart your server to load changes to your zone, then the
signed version of the zone will fall out of sync with the raw version, and
some of your data will not be accessible to queries.  There's no way to
recover from this condition except to delete the signed zone and start
over, which generates big transfers to slaves and is generally undesirable.

We'll have a fix for this in a future release.  It's not a problem when
using inline-signing on slave zones; slaves load their data via zone
transfer, not from files, so this issue doesn't affect them at all.

-- 
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: Reason for Limited number of Root DNS Servers

[Kevin Darcy]

On 11/11/2011 4:30 AM, Gaurav Kansal wrote:

Thanks a lot Mark.
But  I don't understand the calculation part.
Is there any source available from which I can get detail information
regarding the same??



Thanks and Regards,
Gaurav Kansal
9910118448



-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Friday, 11 November, 2011 12:14 PM
To: Gaurav Kansal
Cc: bind-us...@isc.org
Subject: Re: Reason for Limited number of Root DNS Servers


In message<004c01cca034$259d4870$70d7d950$@nic.in>, Gaurav Kansal writes:

Dear All,



Somewhere I read that number of ROOT DNS servers is limited to 13
because of protocol limitation of DNS and UDP.

Exact writing was  "A combination of limits in the DNS and certain
protocols, namely the practical size of unfragmented User Datagram
Protocol
(UDP) packets, resulted in a limited number of root server addresses
that can be accommodated in DNS name query responses. This limit has
determined the number of name server installations at (currently) 13
clusters, serving the needs of the entire public Internet worldwide."

As root DNS are running in anycast so number is not an issue at all.
But I don't understand where exactly is this limitation exists???

Please some elaborate on this.

Thanks and Regards,

Gaurav Kansal

9910118448

Actually despite the words above it has *nothing* to do
with unfragmented UDP and everything to with being able to
reassemble fragmented UDP.

All IPv4 hosts MUST accept fragmented packets up to 576
octets (RFC 791).  DNS's 512 octet UDP limit was choosen to
ensure that the UDP datagram can always be reassembled and
for there to be room for some IP options in addition to the
IP and UDP headers.

Originally there wasn't commonality in the root server's
names.  Then it was said if we make the maximum use of
compression how root servers can we fit into a DNS/UDP
message?

The first NS record takes 31 octets (1 + 2 + 2 + 4 + 2 + 20).

Additional a NS records for . takes 15 octets (1 octets for
the name, 2 octets for the class, 2 octets for the type, 4
octets for the ttl, 2 octet for length and 4 of actual data).

A "A" record with a compressed ownername takes 16 octets
(2 octets for the name, 2 octets for the class, 2 octets for the
type, 4 octets for the ttl, 2 octet for length and 4 of actual
data).

Then there is the 12 octet header and the 5 octet question.

Doing the math on priming queries you get the following:

13 names uses 436 octets
14 names uses 467 octets
15 names uses 498 octets

If you have a referral to the root with a maximum sized qname
it takes 482 octets (12 + 255 + 4 + 31 + 15 * 12).

I believe you only need to read RFCs 1034 and 1035 thoroughly to 
understand the structure and size of a response packet, including label 
compression. Mark's calculations didn't include any later protocol 
extensions like EDNS0 or DNSSEC-related records, although with a modern 
resolver you might see those come into play.




- Kevin




___
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: Reason for Limited number of Root DNS Servers

[Aleksander Kurczyk]

There is more than 13 physical root servers but these servers have only 13 
domain names (a-m.root-servers.net) and ip addresses. Only 13 because of 
limitation of single DNS message to 512 bits (RFC 1035).
http://root-servers.org -- List and map of the root servers
Dnia 11 listopada 2011 6:38 Gaurav Kansal  
napisał(a):
Dear All,
 
Somewhere I read that number of ROOT DNS servers is limited to 13 because of 
protocol limitation of DNS and UDP.
Exact writing was  “A combination of limits in the DNS and certain protocols, 
namely the practical size of unfragmented User Datagram Protocol (UDP) packets, 
resulted in a limited number of root server addresses that can be accommodated 
in DNS name query responses. This limit has determined the number of name 
server installations at (currently) 13 clusters, serving the needs of the 
entire public Internet worldwide.”
 
As root DNS are running in anycast so number is not an issue at all. But I 
don’t understand where exactly is this limitation exists???
 
Please some elaborate on this.
 
 
Thanks and Regards,
Gaurav Kansal
9910118448
 
___Please visit 
https://lists.isc.org/mailman/listinfo/bind-users tounsubscribe from this 
listbind-users mailing 
listbind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users
--
Pozdrawiam,
Aleksander Kurczyk___
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: OT: Bind 9.9.0B1 Inline-Signing Question

[Jan-Piet Mens]

> So the error being logged isn't really an error, it just looks like
> one; we should probably see about silencing it.

The error is indeed confusing, maybe it should say "not yet signed" ?

11-Nov-2011 12:32:35.838 zone inline.aa/IN/internal (unsigned): loaded serial 2
11-Nov-2011 12:32:35.838 zone inline.aa/IN/internal (signed): not loaded due to 
errors.

> When you modify your static zone file and run 'rndc reload', named
> will detect the changes that you've made via the same mechanism as
> ixfr-from-differences, generate signatures for the new records, and
> add those to the signed version of the zone automatically.

Almost. rndc reload behaviour has appaently changed. What actually
happens on my copy of BIND 9.9.0b1 is:

$ rndc reload
rndc: 'reload' failed: up to date
$ echo $?
1

named (running with -g) shows:

11-Nov-2011 12:36:08.377 zone inline.aa/IN/internal (signed): (master) removed
11-Nov-2011 12:36:08.378 reloading configuration succeeded
11-Nov-2011 12:36:08.378 reloading zones failed: up to date

(The message "(master) removed" may cause the odd heart attack... :-)

$ rndc reload inline.aa
zone reload successful
$ echo $?
0

Named then prints:

11-Nov-2011 12:38:16.911 received control channel command 'reload inline.aa'
11-Nov-2011 12:38:16.912 zone inline.aa/IN/internal (unsigned): loaded serial 3
11-Nov-2011 12:38:16.912 zone inline.aa/IN/internal (signed): loaded serial 5 
(DNSSEC signed)
11-Nov-2011 12:38:16.912 zone inline.aa/IN/internal (signed): reconfiguring 
zone keys
11-Nov-2011 12:38:16.913 zone inline.aa/IN/internal (signed): next key event: 
11-Nov-2011 13:38:16.913

A second (futile) reload:

$ rndc reload inline.aa
zone reload up-to-date
$ echo $?
0

Regards,

-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: Subdomain Issue

[Matus UHLAR - fantomas]

On 10.11.11 23:54, trm asn wrote:

ns4 named[3073]: client 116.48.39.92#61358: update 'example.com/IN

' denied

[...]

ns4 named[3073]: client 116.48.39.92#64924: updating zone
'example.com/IN ': update failed: 'RRset exists

(value dependent)' prerequisite not satisfied
(NXRRSET)

[...]

Above are the logs, & it's flooded with those error messages .


none of them is relevant, but note:

- you cannot configure the zone both manually and via DNS updates. You 
can do only one.


- if you have problem with loading a zone, try reloading it and see 
what unusual is logged then.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
___
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: Subdomain Issue

[Matus UHLAR - fantomas]

On 11/09/11 15:59, trm asn wrote:

Is there any thing wrong if I declare my zone like this as below...

$TTL 300
@   IN  SOA ns4.example.com. postmaster.example.com. (
200806  ; Serial Number
10800   ; Refresh after 3 hours
3600; Retry after 1 hour
604800  ; Expire after 1 week
300 ) ; Minimum TTL of 1 day
; Name servers
IN  NS ns4.example.com
IN  NS ns2.example.com
IN  NS ns1.example.com
testINNS ns1973.hostgator.com
testINNS ns1974.hostgator.com
INA203.39.45.19
INMX mail.goole.com
wwwINCNAME example.com
aINA203.39.45.20
bINA203.39.45.21


On 10.11.11 08:58, Lyle Giese wrote:
Where are your A records for your name servers, ns1.example.com, 
ns2,example.com and ns4.example.com?


And please answer the question above, what does the named's log say 
when starting up?


The original problem was already detected by Kevin Darcy, after "trm 
asn" sent the whole zone:


the zone file above defines "test.example.com" subdomain delegated to 
ns1973.hostgator.com and ns1974.hostgator.com, along with A and MX 
records.


However, you can not delegate domain and then add records to it.  Even 
if the hostgator servers were the same example.com is running at, the 
"test.example.com" with its records must be defined in different zone 
file.


The only records in test.example.com that may be added within 
example.com zone are

- the delegation records (NS) for test.example.com
- the glue A/ records, if they exist within test.example.com

(and they all SHOULD be again defined within test.example.com zone)

As Kevin explained, commenting out the "test NS" records means that A 
ans MX below it belong to the zone @ defined zabove, where "@" means 
example.com (or whatever lies in the zone definition in named config).


uncommenting them would bean that they both belong to the "test" 
subdomain which is invalid.


For the OP: next time, simply move those delegations below:

$TTL 300
@   IN  SOA ns4.example.com. postmaster.example.com. (
 200806  ; Serial Number
 10800   ; Refresh after 3 hours
 3600; Retry after 1 hour
 604800  ; Expire after 1 week
 300 ) ; Minimum TTL of 1 day
; Name servers
 IN  NS ns4.example.com
 IN  NS ns2.example.com
 IN  NS ns1.example.com
 INA203.39.45.19
 INMX mail.goole.com
testINNS ns1973.hostgator.com
testINNS ns1974.hostgator.com
wwwINCNAME example.com
aINA203.39.45.20
bINA203.39.45.21

And, also, put the whole zone content somewhere if you have problem - in the 
first post you have ignored the content that made the zone fail.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
How does cat play with mouse? cat /dev/mouse
___
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: OT: Bind 9.9.0B1 Inline-Signing Question

[Adam Tkac]

On 11/10/2011 11:16 PM, Evan Hunt wrote:
>> I know that this isn't the forum for betas
> Sure it is. :)
>
>> We have been testing with the alphas and now with the beta. What we are
>> seeing is that whenever named starts, it initially creates the signed
>> static zone file, but never really finishes.
> What do you mean by "never really finishes"?
>
> What are the options that are set for the static zone?  You should have
> these:
>
> auto-dnssec maintain;
> inline-signing yes;
> key-directory "";
>
> ...with  set to the location of the DNSSEC signing keys for your
> zone, including at least one KSK and one ZSK, both of which are set to
> be published and active.
>
Ah, this was missing bit in my configuration, thanks for it :)

I have just one question, what should inline-zone admin do? I assume
that named automatically regenerates & removes expired RRSIGs so is it
sufficient to put new KSK and ZSK to the key-directory when needed and
revoke older ones? Thanks for your answer in advance.

Regards, Adam
___
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 Bulk Query Tool

[Gaurav Kansal]

Hi Marco,
Thanks.
Dnsperf tool is not working in my machine. I don't understand why??

Is there any other tool available? 

Thanks and Regards,
Gaurav Kansal
9910118448





-Original Message-
From: Marco Bicca [mailto:marco_bi...@symantec.com] 
Sent: Thursday, 03 November, 2011 12:03 AM
To: Gaurav Kansal; bind-users@lists.isc.org
Subject: RE: DNS Bulk Query Tool

Hi Gaurav,

I would use dnsperf and the 1 million website list from Alexa:

DNSPerf:
Freebsd: http://www.freshports.org/dns/dnsperf

Depending on your OS there are available ports too.

Alexa's list:
http://s3.amazonaws.com/alexa-static/top-1m.csv.zip


Did that in the past and it worked pretty well.

Thanks,
___
Marco Bicca

-Original Message-
From: bind-users-bounces+marco_bicca=symantec@lists.isc.org
[mailto:bind-users-bounces+marco_bicca=symantec@lists.isc.org] On Behalf
Of Gaurav Kansal
Sent: Wednesday, November 02, 2011 10:49 AM
To: bind-users@lists.isc.org
Subject: DNS Bulk Query Tool

Dear All,

 

I set up a new DNS Server using Bind 9.7

For meantime I open this server for the whole world. I wanna check how many
queries it can handle.

Is this any freeware available for checking this. Is there any tool
available by which I can come to know after how much load my DNS will be
down (Or it will stop responding) ???

 

Thanks and Regards,

Gaurav Kansal

8860785630

9910118448

 


___
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: Reason for Limited number of Root DNS Servers

[Gaurav Kansal]

Thanks a lot Mark.
But  I don't understand the calculation part.
Is there any source available from which I can get detail information
regarding the same??



Thanks and Regards,
Gaurav Kansal
9910118448



-Original Message-
From: Mark Andrews [mailto:ma...@isc.org] 
Sent: Friday, 11 November, 2011 12:14 PM
To: Gaurav Kansal
Cc: bind-us...@isc.org
Subject: Re: Reason for Limited number of Root DNS Servers


In message <004c01cca034$259d4870$70d7d950$@nic.in>, Gaurav Kansal writes:
> 
> Dear All,
> 
>  
> 
> Somewhere I read that number of ROOT DNS servers is limited to 13 
> because of protocol limitation of DNS and UDP.
> 
> Exact writing was  "A combination of limits in the DNS and certain 
> protocols, namely the practical size of unfragmented User Datagram 
> Protocol
> (UDP) packets, resulted in a limited number of root server addresses 
> that can be accommodated in DNS name query responses. This limit has 
> determined the number of name server installations at (currently) 13 
> clusters, serving the needs of the entire public Internet worldwide."
> 
> As root DNS are running in anycast so number is not an issue at all. 
> But I don't understand where exactly is this limitation exists???
> 
> Please some elaborate on this.
> 
> Thanks and Regards,
> 
> Gaurav Kansal
> 
> 9910118448

Actually despite the words above it has *nothing* to do
with unfragmented UDP and everything to with being able to
reassemble fragmented UDP.

All IPv4 hosts MUST accept fragmented packets up to 576
octets (RFC 791).  DNS's 512 octet UDP limit was choosen to
ensure that the UDP datagram can always be reassembled and
for there to be room for some IP options in addition to the
IP and UDP headers.

Originally there wasn't commonality in the root server's
names.  Then it was said if we make the maximum use of
compression how root servers can we fit into a DNS/UDP
message?

The first NS record takes 31 octets (1 + 2 + 2 + 4 + 2 + 20).

Additional a NS records for . takes 15 octets (1 octets for
the name, 2 octets for the class, 2 octets for the type, 4
octets for the ttl, 2 octet for length and 4 of actual data).

A "A" record with a compressed ownername takes 16 octets
(2 octets for the name, 2 octets for the class, 2 octets for the
type, 4 octets for the ttl, 2 octet for length and 4 of actual
data).

Then there is the 12 octet header and the 5 octet question.

Doing the math on priming queries you get the following:

13 names uses 436 octets
14 names uses 467 octets
15 names uses 498 octets

If you have a referral to the root with a maximum sized qname
it takes 482 octets (12 + 255 + 4 + 31 + 15 * 12).

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